Chapter 1: Introduction to the FCC Framework

What Is FCC?

FCC stands for Find, Create, Critique -- a three-phase cycle that organises how AI-agent personas collaborate to solve problems. Each phase has a distinct purpose:

• Find. Discover requirements, gather context, identify constraints. Personas in the Find phase operate as researchers and analysts.
• Create. Generate artifacts -- code, documentation, designs, strategies. Create-phase personas are the builders.
• Critique. Review, evaluate, and refine the artifacts produced in the Create phase. Critique-phase personas enforce quality, governance, and alignment.

The cycle is not strictly linear. Feedback edges in workflow graphs allow Critique outputs to flow back into Find and Create nodes, forming an iterative refinement loop. This mirrors how effective human teams operate: research informs creation, review informs further research, and the loop continues until the deliverable meets its quality gates.

The FCC framework packages this pattern into a reusable Python library (src/fcc/) that can be installed, extended, and embedded in larger systems.

The timeline below traces how the FCC framework matured across fifteen phases, from the foundational persona and workflow primitives through the v1.0.0 documentation push.

timeline
    title FCC Framework Evolution
    section Foundation
        Phases 1-4 : Personas, R.I.S.C.E.A.R., Workflows, Actions
        Phases 5-7 : Simulation Engine, Scenarios, Event Bus
    section Platform
        Phases 8-10 : Collaboration, Plugins, Governance, CLI
        Phase 11 : Object Model, Notebooks, Streamlit, Guidebook
    section Integration
        Phase 12 : Protocols (A2A, MCP, AGENTS.md)
        Phase 13 : Knowledge Federation, Semantic Search, RAG
    section Enterprise
        Phase 14 : CLEAR+ Evaluation, EU AI Act Compliance
        Phase 15 : v1.0.0 Release, Documentation Excellence

Each tier extends the previous one without rewriting it, which is why adopters can pick a tier that matches their maturity and upgrade incrementally rather than committing to the whole stack.

History and Motivation

The FCC cycle emerged from a reference project that explored persona-driven AI orchestration for enterprise planning. That project proved the concept but coupled the FCC logic to application-specific code. The l2_fcc_agent_team_ext package extracts the reusable core into a standalone, installable library with clear boundaries, stable APIs, and a plugin system for extensibility.

Key motivations:

1. Reusability. Decouple the workflow engine, persona registry, and governance system from any single application.
2. Testability. A clean package boundary enables 2,400+ tests at 99%+ coverage.
3. Extensibility. A 10-type plugin system allows third-party packages to contribute personas, engines, templates, scorers, validators, AI providers, governance rules, scenarios, workflows, and event subscribers -- all discovered via standard Python entry points.
4. Observability. Built-in tracing (OpenTelemetry-compatible) and metrics collection make FCC workflows inspectable in production.

Architecture Overview

The FCC framework is composed of six major subsystems. Each maps to a top-level package under src/fcc/.

Personas

The persona subsystem defines who participates in the FCC cycle. The framework ships with 102 core personas, 45 vertical personas, and 23 plugin-contributed personas across 20 core categories and 6 vertical packs.

Each persona is specified by the 10-component R.I.S.C.E.A.R. specification (see Chapter 3), which captures the persona's role, inputs, style, constraints, expected outputs, archetype, responsibilities, skills, collaborators, and an adoption checklist. Personas are loaded from YAML files, indexed in a PersonaRegistry, and queryable by ID, category, FCC phase, or champion status.

Additionally, every persona can carry a 56-dimension profile across 9 categories (see Chapter 4), a Discernment Matrix (6 traits x 7 rating dimensions), and Design Target Factors (6 factors x 7 rating dimensions).

Workflows

The workflow subsystem defines when and in what order personas act. Workflow graphs are directed graphs where nodes represent persona activation points and edges represent handoffs (forward flow) or feedback (backward flow).

The framework ships four graph sizes:

Graph	Nodes	Use Case
Base sequence	5	Quick prototyping
Extended sequence	20	Standard projects
Complete	24	Full governance
Extended-84	55	Enterprise-scale

Two additional solution-level EAIFC graphs support cross-project orchestration.

Each persona also has up to 6 action types -- scaffold, refactor, debug, test, compare, document -- describing what the persona can do at any given node. There are 204 action definitions across the persona catalog. See Chapter 5 for the full workflow system.

Plugins

The plugin subsystem defines how the framework is extended. Ten plugin types map to entry-point groups (fcc.plugins.*), each with a dedicated abstract base class. Plugins are discovered at runtime via importlib.metadata.entry_points(), validated against their ABCs, and registered in a PluginRegistry. Cross-plugin orchestration handles dependency resolution and interaction matrices. See Chapter 6.

Event Bus

A thread-safe, in-process pub/sub event bus enables decoupled communication between subsystems. Eighty-one event types cover workflow, node, persona, simulation, governance, deliverable, action, collaboration, plugin, protocol, budget, and messaging lifecycle events. Subscribers can register globally or with filters on event type, source, or correlation ID. Events are serializable and replayable. See Chapter 7.

Observability

Structured tracing (FccTracer, SpanData, @traced decorator) and metrics collection (FccMetrics, MetricPoint) provide visibility into framework operations. Exporters write to the console or JSON files. When OpenTelemetry is installed, the tracer can bridge to the OTel ecosystem. Seven pre-defined metrics cover simulation steps, persona activations, gate results, deliverables, AI calls, and action executions.

Collaboration

The human-in-the-loop collaboration subsystem manages sessions where human reviewers interact with the FCC cycle. A CollaborationEngine drives the session lifecycle, ScoringEngine evaluates deliverable quality, ProgressTracker monitors completion, and SessionRecorder persists sessions for replay and audit. Eleven frozen dataclasses model sessions, turns, gates, scores, and ratings.

Ecosystem Context

The FCC package is positioned at Layer 2 (L2) in the technology architecture. It is the canonical authority for the FCC framework and the R.I.S.C.E.A.R. specification. Other ecosystem projects (such as PAOM) are consumers of these definitions, not co-owners.

The package is designed to be installed as a dependency by downstream projects. It exposes:

• A Python API (from fcc.personas import PersonaRegistry, etc.)
• A CLI (fcc init, fcc validate, fcc generate-docs, fcc dashboard, etc.)
• Package data (YAML personas, JSON schemas, workflow graphs, scenario files, governance rules, doc templates)

Key Design Principles

1. Dataclasses over Pydantic. All models are plain @dataclass(frozen=True) instances. No runtime validation magic; explicit from_dict / to_dict class methods handle serialization.
2. No sys.path hacks. The package uses proper src/ layout and pip install -e .. Resource files are resolved via importlib.resources through fcc._resources.
3. Click for CLI. The CLI is built on click, not argparse. Commands are composable and testable.
4. Registries as first-class citizens. PersonaRegistry, WorkflowActionRegistry, DimensionRegistry, CrossReferenceMatrix, PluginRegistry, and ConstitutionRegistry are all queryable, mergeable, and serializable.
5. Thread-safe event bus. The EventBus uses locks to support concurrent subscriber delivery without requiring external infrastructure.
6. Optional heavy dependencies. OpenTelemetry, Anthropic, and OpenAI are optional. The framework runs in deterministic mock mode with zero AI dependencies.

Key Takeaways

• FCC is a three-phase cycle (Find, Create, Critique) that organises persona collaboration.
• The framework comprises six subsystems: personas, workflows, plugins, event bus, observability, and collaboration.
• 102 core + 45 vertical + 23 plugin personas span 20 core categories and 6 vertical packs.
• Workflow graphs range from 5-node prototypes to 55-node enterprise configurations.
• The package is the canonical authority for FCC and R.I.S.C.E.A.R. at Layer 2.
• Design favours dataclasses, registries, explicit serialization, and optional heavy dependencies.

---

Next: Chapter 2 -- Object Model Patterns

Try this in Notebook 01