What Happens When Your AI Agent Is Wrong?

Decide what the agent may do alone

The first decision is not technical. It is a list of what the agent is allowed to do on its own, and what has to wait for a person.

We start from a simple default: anything that touches money, customers, or contracts waits for an approval. For example:

• Paying a bill, or posting an invoice into your accounting system.
• Sending a customer a reply about a refund, a credit, or a complaint.
• Changing contract terms, prices, or renewal dates.

Below that line, the agent can usually act alone. Sorting email or filling in a spreadsheet row is low-risk and easy to undo.

The key distinction is draft versus act. An agent can draft the refund reply, prepare the payment, or mark up the contract change. A person then reads it and presses approve. You still save time, because the slow part (gathering the facts and writing the first version) is done. But the step with real consequences stays with someone accountable.

Low confidence goes to a person

Approvals cover the actions you know are risky. The second safeguard covers the cases the agent itself isn't sure about.

A well-built agent should be able to say "I am not confident here" and stop. But "flagged" on its own is not much help. If a reviewer opens a flagged item and has to start from scratch, the agent has saved nobody any time.

What the reviewer needs is an escalation packet: a short bundle with everything required to make a decision quickly. It should include:

• The input. The original email, invoice, or form, exactly as it arrived.
• What the agent proposed. The draft reply, the entry it wanted to make, the field values it extracted.
• Why it is unsure. In plain words. "The total does not match the purchase order" is useful. "Confidence 0.62" is not.
• The suggested next step. Approve as is, correct a field, or reject and send back.

Every action logged

People often call AI a "black box" because they can't see why it did something. For an operator, the fix is a plain action log: a running record of what the agent saw and did, kept in a place you can search.

A useful log entry answers five questions:

1. What came in? The input the agent worked from.
2. What did the agent do or propose? The action, or the draft it prepared.
3. Who approved it? A named person, or "no approval needed" for low-risk steps.
4. When? Timestamps for each step.
5. What changed? The record, message, or file that was created or edited, including any correction the reviewer made.

With that log, a question like "why did this customer get that email?" has an answer you can look up instead of a guess.

I want to be clear about the limit, though. A log helps you find and fix a mistake. It does not fix the customer's problem by itself. If a wrong reply went out, someone still has to call that customer and make it right. The log just makes sure you know exactly what happened and can stop it repeating.

An illustrative example: an invoice that doesn't add up

This is an illustrative example to show the recovery path. It is not a client result.

Say you run an agent that handles supplier invoices. It reads each invoice from a shared inbox, matches it to a purchase order (the record of what you agreed to buy), and prepares an entry in your accounting system.

One morning an invoice arrives from a regular supplier. Two things are off. The total is higher than the purchase order, and the bank details on the invoice are different from the ones you have on file.

Here is what should happen:

1. The agent stops. Both a mismatch in amount and a change in bank details are on the list of rules that trigger a stop. It does not post the invoice and does not prepare a payment.
2. It sends a packet to the reviewer queue. The packet shows the invoice, the matching purchase order, the two problems side by side, and a suggested next step: "Confirm bank change with supplier by phone before approving."
3. The reviewer checks. Your ops lead calls the supplier on a number already on file, not the one on the invoice. The bank change turns out to be real, and the higher total includes a shipping charge that was agreed by email but never added to the purchase order.
4. The reviewer corrects and approves. They update the purchase order, confirm the new bank details, and approve the entry.
5. The log records it all. The original invoice, the agent's stop and its reasons, the reviewer's name, the correction, and the approval time.

If the bank change had been fraudulent, the same stop would have held the payment until a person checked. If the reviewer had made a mistake instead, the log would show where.

Test the failure cases before going live

Most demos show only the happy path. That tells you little about a bad day.

Before an agent goes live, I'd want to see it handle these on purpose:

• Wrong or incomplete input. A blurry scan, a missing field, a form filled in the wrong way.
• Duplicate input. The same invoice sent twice, or the same customer emailing from two addresses.
• A request outside scope. Something the agent was never meant to handle. It should hand it over, not improvise.
• A tool or connection failing. Your accounting system is down, or a login has expired. The agent should stop cleanly and tell someone, not half-finish a task.
• An approval nobody acts on. If an item sits in the queue for a day, who gets reminded, and what happens to the customer waiting?

We put these cases into the weekly demos on your real data, not as an afterthought. Seeing how the agent fails is often more reassuring than seeing it succeed.

Approvals are common now, so ask the right question

It is worth saying plainly that approvals are no longer rare. Zapier's AI by Zapier documents a per-tool "Require approval before running" setting and a run history of tool inputs and outputs, announced on October 6, 2026. Lindy says on its pricing page: "Anything with outside impact waits for approval."

That is good for buyers. But having an approval switch is not the same as having a plan. The questions that matter are:

• Which of your rules trigger a stop? Amount mismatches, new bank details, refund requests above a level you choose, contract changes?
• Does the stop happen inside the systems you actually use?
• Who reviews, and how fast do they need to respond?
• When something goes wrong, how do you recover, and who tells the customer?

If a packaged tool's approval model covers your job, use it. That is often the simplest answer. Where it doesn't, the work is in mapping your own rules and review steps, not just turning a setting on.

How we build it at V12 Labs

At V12 Labs, we build one scoped workflow at a time, around the tools you already use. Approvals on money, customers, and contracts are standard. Every action is logged. Low-confidence cases go to a person with a clear packet. We show working demos every week on your real data, including the failure cases above. And you own the code.

None of that means the agent will never be wrong. It means that when it is, the damage is smaller, someone notices quickly, and you know exactly how to fix it.

If you'd like to think this through for your own team, we offer a free 30-minute call to plan your first workflow and its review step. We can map where the agent should stop and what your reviewer should see when it does.

Sharath Challa, cofounder, V12 Labs