Skip to content

Chapter 1: What Is FCC?

Learning Objectives

By the end of this chapter you will be able to:

  1. Describe the three phases of the FCC cycle and the role each plays.
  2. Explain why unstructured multi-agent systems tend to fail and how FCC addresses those failure modes.
  3. Trace the lineage of FCC from its reference project to the current standalone package.
  4. Identify the six major subsystems of the framework and how they relate to the cycle.

The diagram below illustrates the three phases of the FCC cycle and the feedback edge that distinguishes it from a one-shot pipeline.

flowchart LR
    F[Find<br/>Discover & Research]:::find --> C[Create<br/>Build Artifacts]:::create
    C --> CR[Critique<br/>Review & Evaluate]:::critique
    CR -->|gaps found| F
    CR -->|approved| D((Deliverable)):::done

    classDef find fill:#4CAF50,color:#fff
    classDef create fill:#2196F3,color:#fff
    classDef critique fill:#FF9800,color:#fff
    classDef done fill:#9C27B0,color:#fff

Only the "approved" edge exits the cycle, which means every artifact must survive review before becoming a deliverable, and any critique gap reopens a fresh Find pass rather than patching in place.

The Problem FCC Solves

Imagine you hand a complex planning task to five AI agents with no coordination protocol. Agent A researches the market but does not tell Agent B what it found. Agent B writes a strategy that contradicts Agent C's compliance analysis. Agent D reviews Agent B's work but uses criteria Agent C never agreed to. Agent E synthesizes everything into a report that pleases no one because the inputs were never aligned.

This is not a hypothetical failure mode -- it is the default outcome of unstructured multi-agent orchestration. The agents are individually capable, but they lack a shared workflow, shared quality criteria, and shared context.

FCC solves this with three simple rules:

  1. Someone must Find before anyone Creates. Research, context gathering, and requirements discovery happen first. The outputs are explicit: a set of findings that downstream agents can reference.
  2. Someone must Critique everything that was Created. No artifact leaves the system without review. Critics apply quality gates, governance rules, and alignment checks.
  3. Critique feeds back into Find. When a review identifies gaps, the cycle restarts. This feedback loop is what turns a linear pipeline into an iterative refinement engine.

These rules are instantiated as a directed workflow graph, where nodes represent persona activations and edges represent handoffs. The graph can be as small as five nodes for a quick prototype or as large as fifty-five nodes for enterprise-scale orchestration.

The Three Phases

Find

The Find phase is about discovery. Personas operating in this phase act as researchers, analysts, and context gatherers. Their job is to produce structured findings -- market data, technical constraints, user requirements, regulatory context -- that downstream personas can consume.

In the framework's persona catalog, Find-phase personas include the Research Analyst, Data Curator, and Requirements Engineer. Each is defined by a R.I.S.C.E.A.R. specification (Chapter 2) that constrains what it looks for, how it communicates findings, and what quality standards its outputs must meet.

Create

The Create phase is about production. Personas here take the findings from the Find phase and produce concrete artifacts: code, documentation, designs, strategies, data pipelines, or any other deliverable the scenario requires.

Create-phase personas include the Software Architect, Technical Writer, Data Engineer, and ML Engineer. They are the builders. Their R.I.S.C.E.A.R. specifications define not just what they create but also the style, constraints, and expected output format.

Critique

The Critique phase is about evaluation. Personas here review the artifacts from the Create phase against explicit quality gates and governance rules. They produce structured reviews -- pass/fail assessments, improvement suggestions, compliance flags -- that either approve the artifact or trigger another Find-Create-Critique cycle.

Critique-phase personas include the Code Reviewer, Ethics Auditor, Quality Assurance Lead, and Governance Officer. Their specifications define the criteria they apply, the severity levels they assign, and the escalation paths they follow.

A Brief History

The FCC pattern originated in a reference project that explored persona-driven AI orchestration for enterprise planning and analytics. That project proved that structured multi-agent workflows could produce higher-quality outputs than unstructured approaches, but it suffered from tight coupling: the FCC logic was entangled with application-specific code, making it impossible to reuse in other contexts.

The l2_fcc_agent_team_ext package extracts the reusable core into a standalone Python library with clear boundaries. The extraction followed a phased approach:

  • Phases 1--4: Core persona models, R.I.S.C.E.A.R. specification, workflow graphs, action engine.
  • Phases 5--7: Simulation engine, scenario system, event bus, and observability.
  • Phases 8--10: Collaboration engine, plugin system, dashboard CLI, governance, docs-as-code generation.
  • Phase 11: Object model abstraction layer, Jupyter notebooks, Streamlit applications, guidebook.
  • Phase 12: Protocol integration (A2A, MCP, AGENTS.md), web frontend scaffolding.
  • Phase 13 (current): Knowledge federation, semantic search, documentation intelligence, and this book series.

The current version is v1.0.1, with 12,100+ tests at 99%+ coverage.

The Six Subsystems

FCC is not just the three-phase cycle. The cycle is supported by six subsystems, each of which gets its own treatment in later chapters:

Subsystem Responsibility Chapter
Personas Define who participates and how they behave Chapter 2
Workflows Define the order of execution and feedback loops Chapter 3
Governance Define quality gates, constitutions, and compliance Chapter 4
Collaboration Manage human-AI interaction, scoring, and approval Chapter 5
Simulation Execute workflows with mock or AI-powered engines Chapter 7
Plugins Extend every subsystem via entry points Book 2, Chapter 5

Two additional subsystems -- the event bus and observability layer -- cut across all six and are covered in Book 2, Chapter 6.

How FCC Differs from Other Approaches

FCC is not the only multi-agent framework. It is worth understanding where it sits in the landscape:

  • LangGraph / CrewAI / AutoGen: These frameworks provide generic agent orchestration primitives. FCC is more opinionated: it prescribes the Find-Create-Critique cycle, enforces quality gates, and ships with a curated persona catalog. You can use FCC with these frameworks as the underlying execution layer.
  • Prompt chaining: Simple prompt chains are linear. FCC's workflow graphs support feedback edges, parallel branches, and conditional routing. The directed graph model is strictly more expressive than a chain.
  • Single-agent approaches: A single agent with a long system prompt can do many things, but it cannot enforce separation of concerns between research, creation, and review. FCC's persona boundaries make the division of labor explicit and auditable.

The key differentiator is structured quality feedback. In FCC, critique is not optional and not informal. It is a first-class phase with its own personas, its own quality gates, and its own audit trail.

Key Takeaways

  • FCC is a three-phase cycle: Find, Create, Critique, with feedback from Critique back to Find.
  • The cycle is instantiated as a directed workflow graph with persona nodes and handoff edges.
  • Six subsystems support the cycle: personas, workflows, governance, collaboration, simulation, and plugins.
  • FCC was extracted from a reference project into a standalone package, now at v1.0.1 with 12,100+ tests.
  • The key differentiator is structured, mandatory critique with explicit quality gates.

Cross-References

← Book 1 Index | Next: Chapter 2 -- The Persona Mental Model →