Human roles

Overview

FFF is designed to minimise the number of humans required to run a software product. In the minimal configuration, a single human can fill all three roles. In a larger organisation, they may be held by different people or small teams.

The three roles are deliberately defined by their decision-making authority, not by their technical skills.

Orchestrator

The Orchestrator sets direction and controls the flow of work. They are the person who decides what gets built, in what order, and when.

Responsibilities:

• Owns the backlog and prioritises it
• Drops new requirements into the Inlet
• Decides which staged tickets to trigger and when
• Monitors the pipeline for tickets that have stalled or been interrupted

What the Orchestrator does not do:

The Orchestrator does not manage agents directly. They do not review code. They do not attend daily standups (there are none). Their primary interface with the system is the backlog and the stream of Validation Packages that land for their review.

The key shift is that the Orchestrator manages the process, not the people. When something goes wrong, the question is not "why didn't the developer do X?" but "why didn't the spec cover X?" The fix is a change to an agent instruction, not a performance conversation.

Subject Matter Expert

The Subject Matter Expert (SME) is the court of last resort for domain questions that agents cannot answer from the spec alone.

Responsibilities:

• Responds to interruption requests during the Forge phase
• Validates that the Validation Package reflects real-world requirements
• Provides domain context when the Analytic agent is refining an ambiguous ticket

What makes a good SME: A good SME gives precise, minimal answers. "Use the Stripe default of 24 hours" is a good answer. "It depends - I'll need to think about it" is a blocking answer. The SME role requires availability and decisiveness more than deep technical expertise.

In practice, the Orchestrator and SME are often the same person. The distinction matters in larger teams where domain expertise is distributed.

Gatekeeper

The Gatekeeper is the only person with authority to confirm a delivery - to push to production. This is a deliberate, single point of accountability.

Responsibilities:

• Reviews every Validation Package before confirming delivery
• Issues the confirm command that triggers the deployment pipeline
• Has the authority to reject or defer a delivery without requiring justification to anyone else

Why this matters: In many teams, the "who pressed deploy" question is unanswerable. There is a shared CI/CD pipeline, auto-merges, a dozen people with push access. When something breaks in production, accountability is diffuse and the post-mortem is political.

In FFF, there is exactly one person who can confirm a delivery at any time. That person read the Validation Package. That person made the decision. If something goes wrong, the path to understanding why is clear.

The Gatekeeper role is not about blame - it is about clarity. A Gatekeeper who is consistently confident in their decisions is the signal that the system is working well.