The complete Modulo pipeline lifecycle

Every agent output in Modulo goes through the same lifecycle. Understanding the full sequence is the best way to understand what the platform guarantees and where each governance mechanism applies.

1. Trigger

A pipeline starts when a trigger fires. Triggers can be GitHub events (pull request opened, push to branch), Linear ticket transitions, Slack mentions, scheduled intervals, or manual invocation. The trigger captures the context: which repository, which branch, which ticket, which user.

2. Snapshot creation

Before anything executes, Modulo freezes the entire pipeline definition into a PipelineSnapshot. Every agent version, schema pin, connector binding, model backend pin, prompt version hash, and environment profile is captured. The run executes against this snapshot, not against whatever the current configuration is.

3. Agent dispatch

Modulo dispatches the work to an agent runtime in an isolated sandbox. The agent receives the trigger context and its configured prompt. It runs in a sandboxed environment with network access controlled by the connector configuration. The agent 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 configured for that agent node. If the output does not match the expected schema (wrong structure, missing fields, wrong types), the run pauses and the validation failure is recorded.

5. Gate evaluation

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

6. HITL review

If any gate fails and the gate is configured as block, or if the node requires human review, the run pauses and a human reviewer is notified. The reviewer sees the gate evidence alongside the agent's output. They can approve, reject, or request changes.

7. Correction loop

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

8. Output delivery

Once all gates pass and any required human review is complete, the output is delivered to its destination. This could be a pull request on GitHub, a comment on a Linear ticket, a deployment to staging, or any other action configured in the pipeline.

9. Audit recording

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

What the lifecycle guarantees

Because every run goes through this complete lifecycle, you always know: what configuration produced the output, what checks it passed, who reviewed it, and what was delivered. There is no path for an agent output to reach production without passing through every applicable gate.

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