The first version of every agent project is the same: connect the model to the systems, watch it work, feel the vertigo. It can read the orders. It can also, technically, refund all of them.
Nothing about that vertigo is irrational. The model is not malicious, but it is confidently wrong on some percentage of inputs, and confidence plus write access is how a Tuesday afternoon becomes an incident report. The fix is not a better prompt. Prompts are requests, not permissions.
Anything you would not let a new hire do unsupervised on day one, the agent does not do unsupervised on day one either. Nobody argues with that framing, and it settles most design debates in about a minute.
One: split reads from writes, and mean it
The most valuable ten minutes in an agent project is the meeting where someone writes every tool on a whiteboard and draws a line down the middle. Reads on the left, writes on the right.
Reads are cheap. Let the agent look at anything it needs — orders, stock, docs, customer history — because a wrong read produces a wrong sentence, and wrong sentences are recoverable. Writes are where the risk lives, and the right-hand column is almost always shorter than anyone expected. Most agents need three or four write tools, not thirty.
Two: put the limits in code, not in the prompt
A prompt saying "never refund more than fifty dollars" is a suggestion the model will usually follow. A function that checks the amount before calling the payment provider is a rule.
The distinction matters because the two fail differently. A prompt fails silently on the unusual input you never tested. A code check fails loudly, in a log, with a value you can read.
Three: approval as a queue, not an interruption
Teams resist human-in-the-loop because they picture a dialog box interrupting someone all day. That is the wrong shape.
The shape that works is a queue. The agent does everything it is allowed to do, batches what it is not, and someone clears the batch once or twice a day. Fourteen invoices chased automatically, two held for a decision, reviewed in ninety seconds each morning. The human is a checkpoint, not a bottleneck — and the queue itself becomes the best possible list of what to automate next.
Four: a trace, or it did not happen
When an agent does something wrong, the first question is always "why did it do that?" — and the answer has to be available without reproducing the run.
That means recording each step: what the agent was asked, what it decided, which tool it called, with what arguments, what came back. A chat transcript is not this. A transcript shows what was said; a trace shows what was done, and only the second one lets you fix anything.
It is also, incidentally, what makes an agent explainable to people who did not build it — which is the conversation that decides whether it stays switched on.
An agent with narrow tools and a real audit trail is boring in exactly the way production systems should be boring.
If you'd rather not build this yourself, that's what our products are for — storefronts, SaaS boilerplates, marketplaces, and support agents, already written and ready for your stack.
Golam Mostafa writes every product in the Reevix catalog, and answers its support. Get every deep-dive and every product with All-Access.