# The hard part of an AI agent isn’t the model. It’s the leash. > Every agent demo I’ve built worked because the agent could do anything. Every one that reached production worked because I’d spent most of my time deciding what it wasn’t allowed to do. By Arthiq — undefined · AI at work Source: https://arthiq.co/blog/the-leash-not-the-model --- I’ve built a fair number of AI agents now — things that read email, move data around, call tools, take actions on someone’s behalf. The pattern that surprised me most isn’t about how clever the models are. It’s where the work actually goes. The demo takes an afternoon. Making it safe to leave running takes weeks. And almost none of that time is spent making the agent more capable — it’s spent deciding, precisely, what the agent is not allowed to touch. ## The demo lies to you An agent demo is a magic trick, and the trick works because nothing is at stake. You give it a task, it reasons through the steps, it calls the right tools, and everyone in the room nods. The reason it looks so good is that in a demo the agent can do anything — full access, no guardrails, a friendly example that happens to go right. Production is the opposite. The task is real, the data is real, and “technically correct” is not the same as “what I wanted.” The first time an agent of mine did something exactly as instructed and completely wrong — sent to the right address, with the wrong content, at the worst possible moment — I understood the gap. The model hadn’t failed. My boundaries had. > The model rarely fails the way you fear. Your boundaries fail the way you didn’t think to check. ## Capability was never the bottleneck The instinct, when an agent underperforms, is to reach for more power — a better model, more tools, wider access, longer memory. Sometimes that helps. More often it raises the ceiling on how badly a single mistake can land. Here’s the reframe that changed how I build: a more capable agent is not a more useful agent. It’s a more consequential one. The useful part — the part a business can actually depend on — is the narrow, well-understood slice of things it can do, over and over, without surprising you. Everything outside that slice isn’t capability. It’s exposure. ## Scope the action, not the agent The mistake I made early was thinking about trust at the level of the agent. Do I trust it or not? That’s the wrong unit. You don’t trust an agent; you authorise an action. **Grant per-action, not per-agent.** The right question isn’t “can this agent access the payments system?” It’s “can this agent make this payment, to this payee, up to this amount, once?” The tighter the grant, the smaller the blast radius when reasoning goes sideways — and it will, occasionally, go sideways. **Make the boundary a wall, not a suggestion.** If the only thing stopping an agent from a costly action is a line in its prompt asking it nicely, you don’t have a control. Prompts are guidance; the model can talk itself out of them. A real boundary lives in the tool layer — the payment simply cannot exceed the mandate, because the code won’t let it, no matter what the agent decides. **Assume the agent will be wrong at the worst moment.** Design as if the one time it misreads the situation is the time it’s doing something irreversible. Because that’s the only failure that actually costs you. ## The test I now apply to everything: can you undo it? The single most useful line I draw is between reversible and irreversible actions. Reversible actions — drafting, tagging, summarising, staging a change for review — I let agents do freely. If they get it wrong, I fix it, and nobody is harmed. This is where autonomy earns its keep, and where I happily give an agent a long leash. Irreversible actions — sending money, deleting records, emailing a customer, publishing something to the world — get a human in the loop, or a hard mandate that bounds them, or both. Not because the agent is stupid, but because “sorry, it was the AI” is not a sentence I ever want to say to someone who was affected by it. Most agent designs get this backwards. They spend the effort trying to make the model good enough to be trusted with irreversible actions, when the cheaper, safer move is to make more of the actions reversible. ## Trust is a budget, not a switch The last shift was mental. I used to think of trust as binary — the agent is either allowed to run autonomously or it isn’t. Now I think of it as a budget that’s spent down and earned back. A new agent starts on a short leash: narrow scope, lots of confirmations, small limits. As it proves itself on the boring, repeatable cases, I widen the scope deliberately — one boundary at a time, watching what happens. If it does something I didn’t expect, the leash comes back in. It’s the same way you’d onboard a capable new hire: real responsibility, but earned, and revocable. That framing does something the binary one can’t. It lets you use agents for genuinely valuable work without pretending they’re infallible — because the design never depended on them being infallible in the first place. ## The real takeaway If you’re building with agents, the temptation is to spend your effort making them smarter. Spend it on the leash instead: scope actions rather than agents, put the real limits in code rather than prompts, keep the irreversible stuff on a human’s desk, and treat autonomy as something earned. None of that is glamorous, and none of it demos well. It’s just the part that decides whether the thing is safe to actually use. Capability is what makes an agent look impressive. Constraint is what makes it worth deploying. If your team is working out how to put AI agents to work without handing them the keys to everything, that’s exactly the kind of thing we help teams get right. [Talk to us](/enquire) if it’s useful, or [see how we run it in-house](/for-teams).