The One-Gate Rule: How to Build a Self-Correcting Agent Pipeline That Only Interrupts You Once

Why do most autonomous agent pipelines fail the day you trust them?

Autonomous agent pipelines fail at two extremes. Fully unattended, an agent that misreads acceptance criteria will happily deploy broken code to production. Gated at every step, you click "approve" six times per task and the automation saves you nothing. The failure is architectural: teams pick one extreme instead of separating self-correction from human authority.

I hit this building an agent orchestrator that runs a Salesforce work item through seven stages: Triage, Analyst, Planner, Executor, Reviewer, change-doc, and Deploy. My first version gated every stage. It worked, and I hated it. The second version ran fully autonomous and pushed a change with zero test coverage to a sandbox before I caught it. Neither is the answer. The answer is picking exactly one place where a human decision is non-negotiable, and making the machine handle everything else, including its own mistakes.

Can you brainstorm the spec with the agent before the pipeline runs?

Yes, and it is the highest-leverage step. Before any stage executes, run a brainstorming pass where you and the agent draft the SPEC and PRD together: acceptance criteria, edge cases, out-of-scope items, and the objects and fields in play. A pipeline is only as good as the spec it starts from. Ten minutes here prevents the Analyst from inventing requirements later.

The mechanics are plain. You hand the agent the raw work item (a ticket, a Slack thread, a one-line request) and it interrogates it: what does "done" mean, which org objects change, what should the Apex tests assert, what is explicitly not being built. You correct it in the chat until the spec is tight, then that document becomes the frozen input to Triage and Analyst. The difference is measurable: work items that entered my pipeline with a co-written PRD hit the two-round reviewer cap far less often, because the Executor is coding against a real target instead of a guess. Skip this and you push the ambiguity downstream, where an agent will confidently fill the gap with the wrong thing.

What is the "one-gate" rule?

The one-gate rule means the pipeline auto-advances through every step and self-corrects its own failures, but stops for a human at exactly one irreversible action: the production deploy. Everything reversible (planning, coding, reviewing, redoing work in a sandbox) runs without you. Everything irreversible waits for one explicit click.

The distinction is reversibility, not importance. A bad plan is reversible: the Reviewer catches it and the Executor rewrites it. A failed sandbox test is reversible: you re-run it. A production deploy is not reversible on a Friday afternoon when a customer's org is live. So that is the gate. In my pipeline the intermediate steps advance on a deterministic engine, and only the prod deploy shows "ready, confirm" and refuses to cross itself. The engine never deploys to production on its own, by design, not by configuration you might forget to set.

How does the self-correcting reviewer loop actually work?

The Reviewer is a real blocker, not a rubber stamp. When it reviews the Executor's diff and finds a problem, the pipeline routes the work back to the Executor with the review notes as context and lets it fix itself. This repeats up to 2 rounds. After the second failed round, the pipeline pauses and hands you the blockers instead of looping forever.

The cap matters. Without it, a confused agent pair can burn tokens ping-ponging a bug neither understands. Two rounds is enough to catch the common cases (a missed null check, a test the Executor forgot to run) without letting a genuine misunderstanding spin. Here is the control flow in plain terms:

Executor writes code  ->  Reviewer diffs + re-runs tests
   Reviewer approves   ->  advance to change-doc
   Reviewer rejects    ->  back to Executor with notes (round 1)
       Executor fixes  ->  Reviewer re-checks
       Reviewer rejects again -> back to Executor (round 2)
           still rejected -> PAUSE, surface blockers to human

Concretely, the Reviewer runs real commands against a sandbox org: it diffs with git and re-runs the Apex tests the Executor was supposed to pass. It is verifying behavior, not guessing. That is what makes the loop trustworthy enough to leave unattended.

Which steps should auto-advance and which should gate?

Split steps by cost of being wrong. Cheap-to-undo, high-frequency steps (triage, analysis, planning) should auto-advance so the pipeline flows. Expensive-to-undo or ambiguous steps should either self-correct in a loop (code and review) or gate for a human (production deploy). Do not gate a step just because it feels important.

One caveat: if an agent lacks information it cannot invent (a work item with no acceptance criteria, a missing org alias), auto-advance is the wrong default. My pipeline handles this with an explicit "needs input" signal: the agent pauses that step, asks a specific question in the step's chat, and resumes when you answer. That is a third state, blocked, that sits between auto and gated. Model it, or your "autonomous" pipeline will silently guess.

How do you keep the production deploy safe across sandbox, QA, and production?

Give the agent three named org targets and make each promotion cross a clean boundary. A dev sandbox runs the build and self-correction loop. A QA or homologação org sits in the middle for integration checks and UAT sign-off. Production is reference-only until the human gate. Every intermediate step deploys and tests against the sandbox with sf project deploy start -o <sandbox>, never against production.

The three-org path maps to the modes above. The Executor and Reviewer loop against the dev sandbox. Once the change doc is generated, the pipeline promotes to the QA org, again with sf project deploy start -o <qa>, and that step can auto-advance or wait for a soft sign-off if stakeholders run acceptance tests there. The QA org is where you find the divergence a lone sandbox hides: real data volumes, live integrations, org-specific config. Only after QA is clean does the locked gate appear. When you confirm, a dedicated deploy agent runs sf project deploy start against the production alias, reads the change doc and plan to know what to ship, and does not edit code or touch either lower org at that point. If it is missing a required detail it emits a needs-input signal instead of guessing. If the push fails, it surfaces a retry banner rather than silently swallowing the error. The separation is the safety: agents can be wrong all day in the sandbox and get caught in QA, and exactly one agent, invoked by exactly one human click, is allowed near production, never with a force flag.

When is one human gate NOT enough?

One gate is enough when your lower orgs faithfully mirror production and your tests are meaningful. It is not enough when environments diverge (different data volumes, missing integrations, org-specific config) or when your test suite does not actually assert behavior. In those cases the Reviewer's green check is a false signal. A QA org closes most of that gap, which is exactly why the three-org path is the default in regulated Salesforce shops.

Know which world you live in. If your Apex tests are coverage theater that assert nothing, no pipeline architecture saves you, and adding agents just automates the production of confident garbage. The one-gate pattern multiplies a healthy engineering practice, it does not substitute for one. Same for Salesforce itself: this pattern works whether your agents drive the sf CLI, a plain Git repo, or any other deploy target. The gate is about reversibility, not about the tool.

The takeaway: separate self-correction from authority

The reason "click approve on everything" and "fully autonomous" both fail is that they conflate two different things: catching mistakes, and authorizing irreversible actions. Machines are good at the first when you give them a tight spec, tests, and a bounded retry loop. Humans should own the second, once, at the point of no return.

If you are building any multi-step agent workflow, start by co-writing the spec, then give each step three states: auto-advance, self-correcting loop, and human gate. Promote through sandbox and QA before production so the tests you trust run somewhere faithful. Put the gate only where an action cannot be undone. Cap your correction loops so they fail loud instead of spinning. Serialize runs so two pipelines do not fight over the same repo. Do that, and your agents interrupt you once per task instead of six times, and you never wake up to a surprise production deploy.