Close the Feedback Loop or the Human Becomes a Messenger

Before you can route work to agents, gate it, or hand it back to a human, the agent has to be able to run on its own: do the change, read what broke, and fix it. Brex needed to migrate gRPC client factories across 400+ services, and the agents could already do the work. Simpler services took 100 to 200 lines of changes, one-shot, about 30 minutes each (Brex). The bottleneck was never the model. It was that the agent finished its changes, hit a wall of automated feedback it couldn't read, and stopped. CI knew what failed. Review bots had flagged the style and security issues. The test runner had the exact stack trace. All of it was built for human engineers, and none of it reached the agent.

The standard workaround turns engineers into messengers

Brex's pre-platform loop is worth reading in full because it is the loop most teams are running right now: spin up an environment, kick off the agent, wait for CI, check for review-bot comments, copy those comments back to the agent, ask it to fix things, wait again, repeat until green. Every morning their engineers kicked off a handful of migrations; every afternoon they came back and manually relayed whatever the automated systems had said. The human in the loop wasn't there to make decisions; the human was there to relay messages. Brex's verdict: "That's an expensive solution to a plumbing problem."

The failure has a second, worse form. An agent that keeps going without the feedback produces output that looks correct but isn't. Cut off from validation tooling, as Brex puts it, an agent is guessing.

Closing the loop is plumbing, and the plumbing is enough

Brex's fix was three Python scripts running continuously in the background: one forwarding Slack task requests to remote developer environments, one feeding PR bot comments back to agents, one handling CI failures. The first migration that ran start to finish with no human touching it answered the question: closing the feedback loop was sufficient. Send a message in the morning, find a green PR by end of day.

That MVP hardened into a platform with a repeatable shape: a trigger (work intake from Slack, Linear, GitHub, or a cron job), a dedicated environment per task carrying the same toolchain the engineers have, and closed loops with every automated system that would normally surface a problem to a human. The agent works, hits failures, reads the feedback, iterates, and puts up a PR. The human's next interaction is review. Brex names the lesson directly: "Feedback loop closure is the core problem." The integration work matters more than the model capability question.

The loop is only as good as the signals inside it. Brex pairs the closure lesson with its twin: "Environment quality determines output quality." An environment without the real CI, the real review bots, and the real test runner closes a loop around nothing. What the agent iterates against has to be the same machinery that would block a human's merge, which is also what makes the green PR mean something at the review gate.

Faster, cheaper feedback beats more feedback

Stripe runs the same architecture at volume: over a thousand pull requests merged each week are entirely minion-produced (Stripe's homegrown unattended agents), human-reviewed but with no human-written code (Stripe). Their refinement is loop economics. The principle is "shift feedback left": any check that would fail CI should fire earlier and cheaper. A local executable runs heuristic-selected lints on every git push in under five seconds; a background daemon precomputes lint results so fixes usually land in well under a second. The agent loop runs that lint node deterministically before pushing, so the branch "has a fair shot at passing CI the first time around" and the minion never wastes tokens iterating against an auto-formatter.

CI, the expensive layer, is rationed. Stripe's tests, over three million of them, run selectively on push; failures with autofixes are fixed automatically, and only unfixable failures go back to the agent. Stripe caps the whole thing at two CI rounds per task, because CI runs cost tokens, compute, and time, and "there are diminishing marginal returns for an LLM to run many rounds of a full CI loop" (Stripe). After the second run, the branch goes to a human. A closed loop is not an infinite loop; it has a budget and an exit.

What the corpus does and does not establish

The before-and-after evidence is qualitative but consistent. Brex ran dozens of migrations and reports that none required an engineer to spend an afternoon relaying CI output; their phrase for the change is "the time unlock was magic." Neither Brex nor Stripe publishes the numbers you would want for a business case: iterations per task, token cost per loop, or merge rate before versus after closure.

Two boundaries to keep in view. Closing the loop makes agents iterate; it does not make their output correct, which is why both companies end every loop at a human and why verifiable outcomes define what "green" must mean. And every channel you pipe into an agent is also an input channel an attacker can write to; a review-bot comment is untrusted content (see the lethal trifecta).

Your CI, your review bots, and your test runners already know everything the agent needs. Connect them, set a budget on the loop, and the humans go back to the one job the loop can't close: deciding whether to ship.