The part that decides whether an agent survives production
Business logic
for AI agents
Most agent projects fail in the same place, and it is not the model. They fail because the business rules ended up inside the prompt, where they cannot be tested, versioned or explained. Business logic for an agent means deciding what the agent may decide, and putting everything else somewhere it behaves the same way twice.
Want to know what this costs in your shop?
I will work out your three biggest time sinks, in hours and dollars. Free, in writing, within 72 hours.
No newsletter, no sequence. You keep the analysis either way.
Tim Muenzel
builds and runs the systems himself
The line that matters
Anything you can write down as a rule is not the agent’s job. Discount thresholds, approval limits, which customer gets which rate, what happens on a failure: these belong in code, where a test can prove they hold. What belongs to the agent is the part you cannot write down: understanding an email, categorising an unusual request, summarising a call. Put those the other way around and you get a system that is confidently wrong in a way nobody can reproduce.
Why rules in the prompt fail
Three reasons, all boring and all fatal. They cannot be tested, because the same input can produce different paths. They cannot be versioned meaningfully, because a paragraph of English does not diff into something a reviewer can approve. And they cannot be explained after the fact, so when someone asks why a customer got that price in March, the honest answer is that nobody knows. None of that is an argument against agents. It is an argument for keeping the rules out of them.
What a production setup looks like
Three things separate an agent that runs for a year from a demo. A hard boundary: it may propose, but anything with a monetary effect needs an approval or a ceiling in code. Logging of every decision with its inputs, because in two months you will need to explain one. And an evaluation pass, a second run that checks the output before it takes effect. Without those three an agent is a risk with good press. With them it is ordinary software that happens to use a model for one step.
What this looks like in practice
On one client platform seven agents run inside 25 background jobs: generating ad copy and images in the account’s proven style with a quality gate before anything publishes, transcribing and analysing calls, and a nightly chain that reads performance data and proposes what to kill and scale, fenced behind budget circuit-breakers and a dry run with no effect. The models are the least interesting part of that description, and that is the point.
Common questions, answered straight
Should the agent call the database directly?
Give it named tools with narrow permissions rather than raw access. A tool that can read one customer is auditable; one that can run any query is not, and the difference costs nothing to build at the start and a great deal to retrofit.
How do we stop it doing something expensive?
By making it structurally impossible rather than instructing it not to. Ceilings, approvals and a dry run in code. Prompts are guidance, not guarantees, and the difference matters the first time a model is confidently wrong.
Do we need our own model?
Almost never. The value sits in the environment around the model: which data it sees, what it may do, who checks the output. Training your own is rarely the cheapest answer to a business problem.
When is an agent the wrong tool entirely?
Whenever the task is fully specifiable. A fixed workflow is cheaper, faster and testable, and in most teardowns that is the honest recommendation for at least two of the three processes examined.
Related reading
Which of your processes actually needs judgement?
Free systems teardown separates exactly that: what is specifiable and therefore cheap to automate, and what genuinely needs language or judgement. In writing, within 72 hours.
Get your free systems teardown