← All posts

The complete Farna Control pipeline lifecycle

Farna Control Team

referencearchitecture

Every agent output follows the same lifecycle.

1. Trigger

A pipeline starts on a trigger: GitHub events (pull request opened, push to branch), Slack mentions, schedules, or manual invocation. It captures repository, branch, ticket, and user.

2. Snapshot creation

Farna Control freezes the pipeline definition into a PipelineSnapshot: every agent version, schema pin, connector binding, model backend pin, prompt version hash, and environment profile. The run executes against it, not the current configuration.

3. Agent dispatch

Farna Control dispatches the work to an agent in an isolated sandbox with connector-controlled network access. The agent receives the trigger context and prompt, then produces output: a diff, a PR description, a test file, a documentation update.

4. Schema validation

The agent's output is validated against the output_schema for that node. If it does not match (wrong structure, missing fields, wrong types), the run pauses and the failure is recorded.

5. Gate evaluation

The validated output passes through every gate on the edge between this node and the next. Each runs independently, producing a pass or fail result with evidence: regex gates check secrets, JSON Schema gates validate structure, custom function gates check business logic, scored eval gates assess quality.

6. HITL review

If any gate fails as block, or the node requires human review, the run pauses and notifies a reviewer. They see the gate evidence with the output and can approve, reject, or request changes.

7. Correction loop

If a gate fails and automatic correction is configured, a new run is spawned with the gate's evidence as context. The agent produces a corrected output; the original stays as evidence. The loop continues until all gates pass or the maximum correction attempts are reached.

8. Output delivery

Once all gates pass and required human review is complete, the output goes to its destination: a pull request on GitHub, a deployment to staging, or another configured action.

9. Audit recording

Every step produces an append-only audit event: who triggered the run, what snapshot it used, what the agent produced, what each gate decided, who reviewed it, and the final output. Events are append-only and SHA-256 chained for verifiability.

What the lifecycle records

No agent output reaches production without passing every applicable gate. Auto-merge is a setting you control: you decide what an agent may do autonomously, and an agent never approves its own block-level changes; a separate reviewer or human clears them.

The principle behind this: immutability of runs - a run executes against a frozen snapshot, so the run you inspect is the run that happened.