Stop Constraining Agents With Prompts, Constrain Them With Infrastructure

Most teams evaluating unattended agents right now are doing the same thing, and it's the wrong thing. They write a giant system prompt that says the agent must never touch production config, must never run destructive commands, must always ask before deleting files, must stay inside these three directories, and then they wire that agent up with a locked-down set of tools, an allowlist of shell commands, an approval gate on anything that smells dangerous, and they call it safe. It isn't safe. It's brittle, and it's slow, and it collapses the moment the model decides the fastest path to green tests is a command you didn't anticipate. You are trying to encode a security boundary in natural language and then enforce it with a probabilistic token predictor that will, given enough runs, do the thing you told it not to do. We've watched this pattern fail on client projects where the whole workflow ground to a halt because every third action needed a human to click approve, which defeats the entire point of running the agent unattended. The behavior you actually want isn't a well-behaved model. It's a blast radius small enough that misbehavior doesn't matter. Stripe figured this out and built their Minions system around it, and the lesson generalizes far past Stripe.

The Minions architecture runs each agent inside a disposable devbox, effectively a single EC2 instance that gets spun up, handed a task, given full shell access, and then thrown away. Full shell access. No allowlist, no command interception, no clever prompt telling it which rm invocations are forbidden. The agent can do whatever it wants inside that box because the box is worthless. It has a checkout of the repo, the tooling to build and test, and nothing else that matters. When it's done, the only artifact that leaves the box is a git diff that goes through the normal PR pipeline, and the box itself evaporates. That single decision, isolation as the permission system, is why they can run 1,300-plus PRs a week authored entirely by agents against a payment codebase handling trillions in volume, without a security team having a nervous breakdown. The permission question stops being what is the agent allowed to do and becomes what can escape the sandbox. Those are wildly different questions, and the second one has a clean, deterministic, infrastructure-shaped answer. You don't audit behavior, you audit egress. A git diff going into a code review pipeline that already has human reviewers, CI, and merge protections is a boundary you already trust, because you already trust it for your human engineers. The agent just becomes another author whose output flows through the exact same gate.

The interesting part of Minions isn't that the LLM writes code. It's the shape of the loop around the LLM. You get a deterministic step, then a fuzzy LLM step, then another deterministic step, alternating. The deterministic steps are things like run the linter, run the type checker, run the test suite, apply the codemod, check that the diff only touches allowed paths. The LLM steps are the parts where you genuinely need judgment, like given these failing tests, what change fixes them. The trick is that the deterministic gates do the actual constraining. If the type checker fails, the loop doesn't advance, and no amount of the model being confident about its wrong answer gets past a compiler. You're using the LLM for the fuzzy middle and refusing to trust it for anything a machine can verify. This is the opposite of how most agent frameworks are built, where the model is in charge and calls tools as it sees fit, and the tools are just capabilities it can reach for. Here the pipeline is in charge, the model is a subroutine, and the pipeline decides when the work is acceptable. We build our own document-processing and automation pipelines the same way at steezr, deterministic validation bracketing every model call, because a model that emits structured output you don't validate is a bug waiting for production traffic. The LLM is powerful exactly where determinism is impossible, and useless where determinism is cheap, so you spend your determinism budget aggressively and only fall back to the model when you have no other option.

There's a detail in the Minions design that quietly matters more than the sandboxing, and it's the hard budget on CI rounds. An agent gets roughly two rounds of CI feedback to get its PR passing, and if it can't get green in that window, the task is abandoned rather than retried into infinity. This is the single most underrated decision in the whole thing. Anyone who has run an agent loop knows the failure mode where the model gets stuck, makes the code worse trying to fix a symptom, then worse again trying to fix the thing it just broke, burning tokens and CI minutes on a death spiral that a human would have bailed on ten minutes in. A hard round budget turns an unbounded cost into a bounded one. It also changes the economics of the whole system, because you can reason about the maximum spend per task and therefore about the maximum spend across 1,300 tasks a week, which is the difference between a line item finance signs off on and an open-ended API bill that scares everyone. If a task can't be solved in two rounds, that's signal, not failure. Either the task was poorly scoped, or it needs a human, and both of those are fine outcomes. The mistake teams make is treating agent retries as free because the model is doing the typing. Compute isn't free, CI capacity isn't free, and a bad PR that a human has to untangle costs more than the task was worth. Bound the loop. Fail fast. Route the hard cases to people.

The last piece is boring and that's why it works. Stripe shares the same rule files across Minions, Cursor, and Claude Code, so the conventions an agent follows when it runs unattended are the same ones a developer's editor enforces when they're writing code by hand with an assistant. There's no separate unattended config that drifts out of sync with the interactive one. The knowledge about how this codebase wants to be written lives in one place, and every consumer, human-driven or fully automatic, reads from it. This matters because the alternative is what everyone actually has, which is tribal knowledge scattered across a wiki nobody reads, a CONTRIBUTING.md that's two years stale, and three different sets of AI instructions that each encode a slightly different idea of how things should work. When the rules are unified, improving them improves every surface at once. You fix a convention because Cursor kept getting it wrong for a human, and now the unattended Minions get it right too, for free. This is just good configuration hygiene applied to a new kind of consumer. If you're evaluating a move from attended to unattended agents, start here, because your rule files are the interface between your intentions and the model's behavior, and if they're a mess for humans they'll be a mess for agents running at 1,300 PRs a week.

If you're a tech lead sitting on the fence about unattended agents, the practical takeaway is to stop investing in prompt-level guardrails and start investing in the boundary. Get your agents running in disposable environments where the only thing that survives is a reviewable diff, and suddenly the question of whether the model is trustworthy becomes almost irrelevant, because a diff going through the same CI and review gate as your human engineers is a risk profile you already understand. You don't need Stripe's scale to copy the architecture. A GitHub Actions runner or a throwaway container with a repo checkout and no production credentials gets you ninety percent of the value, and the marginal work is wiring your existing deterministic checks, the linter, the tests, the type checker, the migration validator, into a loop that brackets the model calls and enforces a hard retry budget. We've built exactly this for clients moving from a human clicking approve on every agent action to a system that files PRs while everyone's asleep, and the thing that made it work was never a better prompt. It was accepting that the model will occasionally do something dumb and designing the infrastructure so that when it does, nothing bad can escape. Constrain the environment, not the tokens. That's the whole lesson, and it's the reason a payment company can let agents loose on its codebase and sleep fine.