CI Integration

Agent-produced changes have to survive the same pipeline as human ones. The integration model is deliberately conservative: agents are producers of candidate changes and consumers of pipeline results, never operators of the pipeline itself.

The authority boundary#

Consuming results#

Pipeline output is normalised into the same structured failure format produced by local test runs, so the planner does not need separate handling for local and remote signal. Build failures, test failures, static analysis findings and security scan results all arrive as typed events attributed to specific symbols where the underlying tool provides enough information to do so.

1. 1

   Observe

   The agent subscribes to pipeline events for branches it authored. It does not poll, and it does not watch branches it has no work on.

2. 2

   Attribute

   Failures are mapped back to change-plan steps. A failure the plan cannot account for is escalated rather than speculatively patched.

3. 3

   Decide

   Flaky and pre-existing failures are distinguished from genuine regressions using historical data before any remediation is attempted.

4. 4

   Remediate or escalate

   A bounded number of remediation attempts is permitted. Exceeding it hands the branch to a human with a full account of what was tried and why each attempt failed.

Reporting#

Every agent-authored change request carries a provenance block: the originating objective, the change plan, the blast radius report, the verification set with its coverage gaps, and the full remediation history. A reviewer should never have to reconstruct what the agent was trying to do — and if the provenance is not legible, the change is not ready for review.