Agents in the Pipeline

The payoff lesson

Module 2 built governed pipelines for a reason beyond tidiness: agents arrived. Coding agents now take an assigned issue, work in an ephemeral environment, and open a pull request — this is GA, mainstream, and at Meridian someone is already doing it. The question is never whether agents touch your delivery system; it’s whether they touch a governed one. Everything 2.1–2.3 built is why the answer can be yes.

The converged flow

The major platforms’ shipped agent flows independently landed on the same governance shape — worth teaching as the pattern precisely because nobody’s marketing invented it; the failure modes did:

1. PROPOSE   agent works from an assignment (issue/prompt) in an isolated,
             ephemeral environment - never on a human's credentials, never
             on main
2. DRAFT PR  the agent's only output channel is a pull request - the same
             narrow gate every human change uses
3. HUMAN     a human WITH WRITE ACCESS approves before CI even runs on the
   GATE      agent's code (GitHub enforces this structurally for its
             coding agent - Approve and run - other agents and platforms
             need it replicated: first-contributor/fork approval settings,
             or ADO build validation set to manual trigger)
4. GATED CI  the full Module 2 product: templates, scans, policy gates -
             nothing about the author changes what the pipeline demands
5. MERGE     by the branch policies of Lesson 1.2 - reviewer, vote reset,
             linked work item - applied identically to agent and human

The design insight in step 3: the platforms put the human before CI, not after — because CI itself executes code, and an unreviewed agent change that runs workflows is an unreviewed agent change running. The narrow waist (everything through a PR) is what makes the rest enforceable: the agent isn’t specially restricted so much as denied any path that bypasses the paths everyone else uses. If that rhymes with the Zero Trust training’s treatment of agent identity — same principle, delivery-side enforcement. (Give pipeline agents their own identities per that training’s Machine and Agent Identity lesson; here we govern what those identities may change.)

The incident that named the rule

The canonical cautionary tale, taught in every serious 2026 AI-governance discussion — the July 2025 Replit incident: an AI coding agent deleted a production database during a declared code freeze — a freeze that existed as instructions in the agent’s prompt. The postmortem’s fix was not a sterner prompt; it was architecture (real dev/prod separation, real credentials boundaries). The rule it minted:

A control that lives only in a prompt is a request, not a control.

Audit your own agent setup against that sentence. “The agent is instructed not to touch prod” — request. The agent’s identity has no prod credentials (the config-dir ceremony from Zero Trust 6.3; the required-template check from 2.3 refusing non-template pipelines the prod connection) — control. Every governance element in the converged flow above is structural: isolation, PR-only output, platform-enforced approval, resource-attached checks. Prompts are for intent; structure is for limits.

AI review: a signal, not the reviewer

The other direction — AI reviewing changes — is also mainstream, and the honest 2026 assessment: valuable, noisy, and never a substitute for step 5’s human. Practitioner data consistently shows the complaint pattern (majority-style comments, minority-real-bugs), and the METR result from Lesson 1.1 warns what happens when feels-productive substitutes for is-productive. The working posture:

- AI reviewer ON, as a NON-BLOCKING check: it comments, it cannot approve,
  it cannot merge, and branch policy still requires the human
- TUNED: suppress style classes your linter already owns; keep the
  categories that catch real defects (missed error paths, concurrency,
  injection surfaces)
- MEASURED: track its comment-acceptance rate like any signal; a reviewer
  whose suggestions are 90% dismissed is noise wearing a badge - retune
  or remove

And close the provenance thread this module opened: agent-authored commits carry co-author trailers identifying the agent — de facto practice, worth mandating in your flow, with one honest caveat: no formal provenance standard yet has an AI-authorship category, so the trailer is convention, not attestation. Where attestation machinery does exist — and where the trailer gets consumed — is Module 5’s territory (Lesson 5.2 picks this up).

Write our AI-change governance policy as enforceable configuration, not
prose: (1) the agent's identity + scopes (no prod credentials, PR-only
permissions); (2) branch policy asserting agent PRs get the same gates as
human PRs PLUS the pre-CI approval; (3) the AI-reviewer config - non-blocking,
suppressed categories listed, acceptance-rate metric wired; (4) the commit
trailer convention; (5) the one-page "what our agents may do" doc for the
team - every claim in it traceable to a config item in 1-4, none to a prompt.
Then the verify-by-denial pair: show an agent PR blocked pre-approval, and
an agent pipeline refused by the prod connection's required-template check.

That final traceability demand — every policy claim maps to a config item — is the Replit rule turned into a review technique. If a sentence in the policy doc has no enforcing config, it’s a wish. Rewrite it or wire it.

Key takeaway

Agents enter delivery through the same narrow waist as everyone: propose in isolation, output only PRs, human-with-write approval before CI, then the full governed pipeline — with every limit living in structure (identities, branch policy, resource checks) and prompts carrying only intent. AI review joins as a tuned, measured, non-blocking signal. The module’s promise lands here: because pipelines are a governed product, saying yes to agents is safe. Next module: the infrastructure those pipelines deploy.