The trap is usually not "agents are too autonomous" in the abstract. It's that they can keep looking busy after the state stopped changing. A few runtime guardrails have mattered a lot for us: stop after the same blocker or same tool/result pattern repeats a few times make every retry prove what changed before it spends again keep a hard budget for browser steps, not just the whole task end with a receipt that says completed, blocked, or budget_exhausted so humans can trust the stop That turns the system from "hope the agent knows when to quit" into something you can actually operate. We've been building MartinLoop around that exact control layer, but the core idea is independent of the product: no silent retries, no invisible spending, no stop condition that disappears when the terminal does.

This is the kind of boring architecture I trust more.\n\nThe one extra layer I would add is loop dedupe. If the agent hits the same blocker, same file boundary, or same failed verification pattern again, it should not be allowed to politely keep trying forever.\n\nThe runtime should force one of three outcomes at that point: refresh state, ask for review, or stop with a receipt.\n\nThat is the part people miss when they focus only on roles and prompts. A lot of waste comes after the first bad step, not during it. We built MartinLoop around that exact control layer because the expensive failures kept looking more like repeated uncertainty than dramatic breakage.

I think this is the right direction. A repo is only 'agent ready' if it can answer boring questions up front: what commands are allowed what paths are off limits what verifier counts as done what should force a stop instead of another retry Most of the pain isn't that the agent is clueless. It's that the repo never told it what a safe, valid run actually looks like. Treating that as a machine-readable contract feels way more useful than hoping the prompt carries all of it.

I like how boring this is. That is usually a good sign. A lot of agent pain is not that the model is weak, it is that the runtime gives it too much room to wander with too little proof before the next step. Role separation plus a real verification gate solves more than people expect because it makes fake progress visible earlier. The one thing I would add is a readable stop receipt after every run so you can tell whether the agent stopped because it finished, got blocked, or just ran out of confidence while looking busy.

This is the right instinct. The missing layer is usually a tighter repo contract: what commands are allowed, what paths are off-limits, what verifier must pass, and what counts as enough change before another retry is admitted. A lot of ugly loops are just the same failure wearing slightly different wording.

This is the right kind of boring. Most agent failures I see are not model problems first. They're workflow problems: no clear scope, no memory of what already failed, no health gate before writing, and no real stop condition once the run goes sideways. The one extra layer I'd add is loop control at the runtime level: max consecutive unchanged failures max spend / max wall-clock mandatory verifier before another retry a receipt that says why the run stopped That's the part we've been building around with MartinLoop. Not “make the agent smarter,” just make the run accountable. The Lead → Explorer → Builder → Reviewer split here feels like a good base for that.

I like this framing a lot because most teams discover repo readiness way too late, usually after the agent is already wandering. The useful shift is treating readiness as something machine-readable before the run starts: what parts of the repo are safe, what needs approval, what counts as success, and what should stop the loop. If that contract is missing, the agent isn't really autonomous. It's just improvising in a place where the blast radius is unclear.

What keeps biting teams isn't that the agent is weak. It's that the loop keeps going after the useful evidence is gone. Once you're on retry 6 with no new proof, you're not exploring anymore, you're just buying uncertainty. The control that matters most is boring: before another retry, show what changed. If nothing changed, stop.

The trap is assuming better agents fix bad operating boundaries. In practice the expensive failures usually come from missing stop conditions, weak verification, and no record of what the agent actually did.

Maybe for data access, yeah. But agentic AI still gets weird fast without a shared stop reason, evidence change, and next-attempt rule. The data plane helps, it doesnt replace control.