What "autonomous" actually means in production
Click through what an agent can take back and what it can’t: the two lists have almost nothing in common, and that gap is the entire job of designing one.
'Autonomous' gets applied to two different things and the word doesn't distinguish between them. One is a loop: an agent perceives, plans, acts, checks the result, and adjusts without a human approving each step. The other is a boundary: what that loop is allowed to touch. The loop is a property of the system; the boundary is a decision someone made. Confusing them turns 'the agent is autonomous' into 'nobody's watching,' which isn't the same claim at all. The loop itself is easy to describe — plan, execute in a disposable sandbox, read the error, revise, reach out through something like MCP to touch files or APIs. None of that should feel controversial; a sandbox is built to be wrong in. The interactive list in this piece walks through real actions an agent might take mid-task: half the loop just does, because being wrong costs nothing and the attempt gets discarded. The other half — merging to main, deploying, spending money, messaging a customer, deleting production data — need a person, because being wrong costs something that doesn't reset. A multi-agent setup makes the boundary easier to see, not harder, since it forces you to draw it per desk instead of once for 'the agent.' What makes a setup production-grade isn't a bigger or less supervised loop. It's a boundary drawn on purpose, before the fact, and better infrastructure doesn't move that line.