The gap between an agent that demos well and one that runs unattended is mostly permissions, failure behaviour and evaluation — not model quality.
Agents demo extremely well. An agent that reads a request, decides what to do and takes action across systems is genuinely impressive in a controlled setting.
Running one unattended, against real data, with real consequences, is a different engineering problem. The gap is rarely the model.
Permissions are the architecture
An agent that can act needs credentials, and the scope of those credentials is the actual security boundary of the system.
Instruction-level restrictions are not a control — telling a model not to touch certain records is guidance, not enforcement. The agent must operate under an identity that genuinely cannot reach what it should not, ideally the requesting user's own permissions rather than a broad service account.
This is a design decision made early or an expensive retrofit made later.
Decide what happens when it is wrong
It will sometimes be wrong. The question is what that costs and whether it is recoverable.
Reversible, low-stakes actions can run unattended. Irreversible or externally-visible ones — payments, customer communications, deletions — warrant a human checkpoint, at least until you have evidence about error rates.
The useful framing is not accuracy in the abstract but blast radius: what is the worst outcome of a single wrong action, and can you undo it?
Evaluation has to be continuous
A one-off evaluation before launch tells you about that day. Behaviour drifts as data shifts, prompts change and providers update models.
You need a held-out set of cases with known-good outcomes that runs automatically, and a way to catch regressions before users do. Without this you are relying on complaints as your monitoring, which means you learn about failures from the people affected by them.
Cost is a runtime concern
Agent loops can be unbounded. A retry pattern that misbehaves can produce a startling bill overnight.
Per-task ceilings, monitoring and alerting on spend anomalies are operational requirements, not optimisations.
Audit trails, before you need them
When someone asks why the system did something — and eventually someone will, possibly a regulator or a customer — you need the inputs, the retrieved context, the decision and the actions taken, all reconstructable.
Retrofitting this after an incident is painful and incomplete. Building it in from the start costs little.
Where to start
One workflow, tightly scoped, with a measurable outcome and reversible actions. Get it genuinely running, learn what breaks, then widen the scope.
Platform-first approaches — building general agent infrastructure before a single agent works in production — tend to produce impressive architecture and no operating system. Start with the narrow thing that works.
