We build AI agents into businesses for a living, so the question we get asked is where they work. The more useful answer is where they do not, because that is the shorter list and it is the one that saves you money.
An agent is good at reading messy inputs, making a judgement under uncertainty, and doing it at a scale a person cannot. That combination is genuinely valuable. It is also the wrong tool in four specific situations, and we say no to all four.
When the rule is already a rule
If the logic is deterministic, write the logic. Purchase orders under a threshold get auto-approved. Invoices matching a PO to the cent get posted. That is an if-statement, and an if-statement is free, instant, testable, and identical every time you run it.
Putting a language model in front of a rule you can already write adds cost, latency and a small chance of being wrong. We see this often, because an agent demos better than a condition. It does not run better.
When there is no way to check the answer
This is the one that matters most. Before we deploy an agent, we ask how we will know it is wrong.
Sometimes the check is easy. Extract a total from an invoice, then compare it to the sum of the line items. If they disagree, the extraction failed, and you have caught it without a human looking. Sometimes the check is a person who was reviewing the work anyway, so the agent drafts and they approve.
But if the output is a judgement nobody downstream verifies, and being quietly wrong for six months has a real cost, we will not ship it. An unverifiable agent does not reduce risk, it moves risk somewhere you cannot see it. That is worse than the manual process, because the manual process at least had somebody's name against it.
When the input data isn't fit for it
An agent inherits the quality of what it reads. Point one at a customer table with duplicate records, three spellings of the same supplier and a status field people use however they like, and it will produce confident output built on a foundation that is not true.
This is why our AI work usually starts before the AI. Get the data connected and agreed first, then automate on top of it. Reversing that order is the most common reason a pilot looks brilliant in a demo and dies in month three.
When the failure is unrecoverable
We separate actions that can be undone from actions that cannot. Drafting a message, flagging an anomaly, preparing a reconciliation, all recoverable. Paying money, deleting records, sending something to a customer, submitting a compliance return, not recoverable.
Agents get the recoverable side. On the other side they prepare the work and a person commits it. The productivity gain is nearly all in the preparation anyway, so you give up very little and you keep the property that a bad day is a bad draft rather than a bad payment.
So what do we do instead?
Usually one of three things. We write the rule, because it was a rule. We build the connection layer first and revisit automation once the data is trustworthy. Or we keep the agent and move the human, so the agent does the reading and drafting and a person approves the commit.
Every agent we put into production under Apex is built for one job, bound to your rules, and checkable. That last part is the constraint people skip, and it is the one that decides whether the thing is still running in a year.
If you want to know which of your processes clear that bar, an AI Readiness Assessment is the honest version of that answer, including the parts where we say not yet.
