Skip to content

Chapter 3: Workflow Thinking

Learning Objectives

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

  1. Explain why FCC workflows are modeled as directed graphs rather than linear pipelines.
  2. Describe the four standard workflow graph sizes and when to use each.
  3. Identify forward edges, feedback edges, and parallel branches in a workflow graph.
  4. Explain how action types map personas to specific capabilities at each graph node.
  5. Trace a simple Find-Create-Critique cycle through the base workflow graph.

The figure below shows the five-node base sequence workflow graph, with one Find node, two Create nodes, two Critique nodes, and a single feedback edge from review back to design.

flowchart LR
    N1[N1: Requirements<br/>Gathering]:::find --> N2[N2: Architecture<br/>Design]:::create
    N2 --> N3[N3: Implementation]:::create
    N3 --> N4[N4: Quality<br/>Review]:::critique
    N4 --> N5[N5: Final<br/>Approval]:::critique
    N4 -.->|feedback| N2

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

The feedback edge targets the Architecture Design node rather than Requirements Gathering because most quality issues at review time are design-level, not requirement-level. Choosing where feedback edges land is one of the main design decisions when authoring a workflow graph.

From Pipelines to Graphs

The simplest way to orchestrate agents is a pipeline: Agent A runs, passes output to Agent B, who passes output to Agent C. Pipelines are easy to understand, but they have a fundamental limitation -- there is no way for Agent C's review to influence Agent A's research. Information flows in one direction only.

FCC replaces the pipeline with a directed graph. Each node in the graph represents a persona activation point -- a moment when a specific persona runs and produces output. Each edge represents a handoff -- the output of one node becomes the input of another.

The critical addition is feedback edges: edges that point backward in the graph, from a Critique node back to a Find or Create node. These feedback edges are what make FCC iterative. When a review identifies a gap, the workflow does not halt -- it routes the gap back to the appropriate Find or Create node for resolution.

This design mirrors how effective human teams work. A code reviewer does not just say "this is wrong" and stop. The review triggers a revision cycle: the developer fixes the issue, the reviewer checks again, and the loop continues until the code meets the quality bar. FCC automates this pattern.

The Four Standard Graphs

The FCC framework ships with four pre-built workflow graphs, each suited to a different scale of work:

Base Sequence (5 nodes)

The smallest graph. Five nodes arranged in a Find-Create-Critique-Find-Create sequence, with a feedback edge from the Critique node back to the second Find node. This graph is designed for quick prototyping and simple tasks where you want a single iteration of the FCC cycle with one feedback opportunity.

Find-1 --> Create-1 --> Critique-1 --> Find-2 --> Create-2
                            |                       ^
                            +--- feedback ----------+

Use this graph when you need a proof-of-concept or are testing a single persona's behavior in isolation.

Extended Sequence (20 nodes)

The standard graph for most projects. Twenty nodes span multiple FCC cycles with parallel branches for specialized tasks. For example, a data analysis branch might run in parallel with a documentation branch, with both converging at a shared Critique node.

This graph supports 3--4 full FCC cycles with cross-cutting governance checkpoints. It is the default for fcc init projects and covers most team-based scenarios.

Complete Graph (24 nodes)

The full governance graph. Twenty-four nodes include dedicated governance nodes for compliance checking, ethics review, and constitutional validation. Every Create node has both a technical Critique node and a governance Critique node, ensuring that artifacts are evaluated from both quality and compliance perspectives.

Use this graph when your project has regulatory, ethical, or policy requirements that demand formal governance review.

Extended-84 Graph (55 nodes)

The enterprise-scale graph. Fifty-five nodes activate personas from across the entire 84-persona catalog, with dedicated champion nodes coordinating each team. This graph supports parallel workstreams for data engineering, ML lifecycle, DevOps, and application development, all converging at a shared critique and governance layer.

Use this graph when you are orchestrating a large team of specialized personas across multiple domains.

Solution-Level EAIFC Graphs

Two additional graphs operate at the solution level, spanning multiple FCC cycles across multiple projects. These Ecosystem-Aware Inter-Framework Collaboration (EAIFC) graphs are designed for cross-project orchestration with AOME, CONSTEL, and Sky-Parlour. They are covered in Book 3, Chapter 6.

Nodes and Edges

Node Types

Each node in a workflow graph has three key attributes:

  • Persona ID: Which persona runs at this node. The persona's R.I.S.C.E.A.R. specification determines the node's behavior.
  • Phase: Whether this is a Find, Create, or Critique node. The phase determines which action types are available.
  • Action Type: What the persona does at this node. There are six action types.

Action Types

Every persona defines up to six action types, each representing a different kind of work:

Action Type Description Example
scaffold Create initial structure Generate a project skeleton
refactor Improve existing artifacts Restructure a module for clarity
debug Identify and fix issues Trace a failing test to root cause
test Verify correctness Write and run test cases
compare Evaluate alternatives Compare two architecture options
document Produce documentation Write API reference docs

There are 204 action definitions across the 84-persona catalog. The WorkflowActionRegistry indexes them by persona ID and action type, making it efficient to query which personas can perform a given action.

Edge Types

Edges in the workflow graph carry metadata about the handoff:

  • Forward edges pass artifacts downstream. The output of a Find node becomes the input of a Create node.
  • Feedback edges route critique results back upstream. A failing quality gate triggers a re-run of the appropriate Find or Create node.
  • Parallel edges enable concurrent execution. Two Create nodes with no dependency between them can run simultaneously.
  • Conditional edges activate only when specific conditions are met. A governance node might only trigger if the artifact contains personal data.

Walking Through the Base Graph

Let us trace a concrete example through the 5-node base graph. The scenario is: "Analyze the competitive landscape for a new SaaS product."

  1. Find-1 (Research Analyst): Gathers market data, identifies competitors, and produces a structured findings document.
  2. Create-1 (Strategy Lead): Takes the findings and produces a competitive positioning document with strategic recommendations.
  3. Critique-1 (Quality Assurance Lead): Reviews the positioning document against the project's quality gates. Finds that the competitive analysis lacks pricing data. Issues a structured review with a "needs revision" flag.
  4. Find-2 (Research Analyst, triggered by feedback): The feedback edge routes the critique back to a second Find node. The Research Analyst gathers the missing pricing data and produces an updated findings document.
  5. Create-2 (Strategy Lead): Incorporates the pricing data into a revised positioning document. This document passes the quality gate.

This five-step sequence demonstrates the core FCC pattern: research, creation, structured review, feedback-driven iteration, and final delivery. The workflow graph made the feedback loop explicit and automatic -- no human had to intervene to say "go back and get the pricing data."

Graph Traversal

The workflow engine traverses the graph using a topological sort with feedback edge handling. The algorithm:

  1. Identify all nodes with no unsatisfied incoming edges (the "ready set").
  2. Execute ready nodes in parallel where possible.
  3. Collect outputs and mark outgoing edges as satisfied.
  4. If a Critique node produces a feedback result, mark the feedback edge's target node as "ready" again.
  5. Repeat until all nodes have executed or a maximum iteration count is reached.

The maximum iteration count (configurable, default 3) prevents infinite feedback loops. If an artifact cannot pass its quality gate after three iterations, the workflow escalates to a human reviewer via the collaboration engine (Chapter 5).

Key Takeaways

  • FCC workflows are directed graphs, not linear pipelines. Feedback edges enable iterative refinement.
  • Four standard graph sizes cover scenarios from quick prototyping (5 nodes) to enterprise-scale (55 nodes).
  • Six action types (scaffold, refactor, debug, test, compare, document) define what personas do at each node.
  • Graph traversal uses topological sort with feedback handling and configurable iteration limits.
  • The base graph demonstrates the full FCC pattern in five steps: find, create, critique, re-find, re-create.

Cross-References

← Chapter 2: The Persona Mental Model | Next: Chapter 4 -- Quality and Governance →