An AI agent almost never fails on the first step. It fails two, three or four steps later, once nobody is watching the screen anymore and the agent itself keeps chaining the next move on the assumption that the previous one went fine. That's the question we ask ourselves every time a client wants an agent to stop just answering and start acting inside their ERP or CRM: not "what can it do", but "how many steps do we let it take before forcing it to stop and check".
The problem isn't step 1, it's step 3
When someone tests an AI agent for the first time, they almost always do it with a single-step task: "look up this customer", "tell me the stock on this product". There, the agent performs well almost every time, because a mistake shows up immediately and gets corrected at no cost.
The problem shows up when the agent stops answering and starts chaining actions on a real system: it validates a piece of data, and based on that data decides the next step, and based on that step's result decides the one after. If step 2 relies on a wrong reading from step 1, the error doesn't stay in step 2: it travels all the way to the end of the chain, and by the time someone notices (if they notice), there's already an order, an invoice or an opportunity created with data that was never correct.
The more steps an agent chains without anyone verifying the intermediate result, the further an error can travel before anyone sees it. It's not that the model "reasons worse" by the fifth step: it's that nobody checked the previous four.
The real case: five steps, five checkpoints
In the sales agent we built for an industrial distributor with more than 50,000 products, the AI quotes over WhatsApp inside Odoo, and the real chain has five steps:
- Validate that the customer writing in exists and is correctly identified.
- Apply the price tier that corresponds to that specific customer (not a generic rate).
- Check the actual stock of the requested product.
- Create the sales opportunity in the system.
- Generate the order.
We could have let the agent run all five steps in a row and only show the final result. We didn't. Each of those five steps has its own verification before letting the next one proceed: if the customer isn't validated, no price tier is applied; if the tier doesn't match the customer, stock isn't checked; if stock isn't enough, no order gets created. The agent doesn't move forward "because it looks fine so far": it moves forward because that specific step passed its own check.
| Step | What the agent decides | What verifies it before continuing |
|---|---|---|
| 1. Validate customer | Who is writing and which account it is | Exact match against the ERP record |
| 2. Apply price tier | Which price applies | The tier linked to that customer, not a default one |
| 3. Check stock | Whether there are enough units | Real stock in the ERP at that moment, not a cache |
| 4. Create opportunity | Whether the order moves forward | That the previous three steps passed their checks |
| 5. Generate order | The final order that gets sent | That the opportunity was created with correct data |
Why this isn't the same as "watching if the agent fails"
It's easy to confuse this idea with setting up an alert that warns you when something breaks. Those are different things. An alert catches a failure after it already happened. A checkpoint stops the failure from propagating to the next step, because it won't let the chain move forward until the current step is confirmed.
The difference matters because the cost of fixing an error grows with every step that carries it forward. Fixing a misidentified customer at step 1 costs one more question. Fixing an order already created with the wrong price at step 5 costs undoing the order, notifying the customer and, if goods already shipped, something worse.
The decision rule
After building several agents that write to real systems (ERPs, CRMs, accounting), the rule we apply is this:
An agent can chain as many steps as it needs, as long as every step that writes (not just reads) to a real system has its own explicit verification before letting the next one proceed. If a step only reads and displays information, a mistake gets fixed by asking again. If a step writes (creates, modifies or deletes something in a real system), that step needs its own "this checks out, moving on" before continuing, not an assumption that because the previous step went fine, this one will too.
Put the other way around, as a warning: if your agent chains several steps that write to your system and there's only one check at the very end, you don't have five verified steps, you have one verified step and four running blind.
Checklist before letting an agent chain steps that write
- Does every writing step have its own verification, or is only the final result checked?
- What happens if step 2 relies on data from step 1 that turned out to be wrong? Does the chain stop, or does it keep going with the error baked in?
- Is there a step where, if it fails, you'd rather the agent stop and ask a human instead of deciding on its own?
- After the agent finishes, can you see which check passed at each step, or only the final result?
- Does the cost of undoing an error grow depending on which step it happened at? If so, the later steps need more control, not less.
It's not a question of "how many steps", it's how many go unchecked
The question in the title doesn't have a fixed-number answer ("up to 3 is fine, past 4 it fails"), because it doesn't depend on how many steps there are, but on how many of those steps write to a real system without anything verifying them before moving on. An agent can safely take twenty steps if nineteen only read and query, and the one that writes has its own check. And it can derail on the second one if that second step already writes something and nobody checked it before the third.
It's the same discipline we apply in the AI data platform we built for a pharmacy group, where the AI never reasons over a number without it being validated down to the cent first, and in the sales agent inside the ERP for that distributor: first you map out what can fail and where, only then do you let the agent act. You can see how we build it, with more technical detail, in our custom AI services.
If you're weighing giving an AI agent write access to your ERP, your CRM or your accounting, and you're not sure how many of its steps actually have a checkpoint, that's the first question we answer in a conversation. Get in touch and we'll walk through it together.
