Anyone considering handing a piece of their business over to an AI agent has the same quiet worry: what if it gets something wrong?
The wrong invoice matched. The wrong action assigned from a client call. The wrong email sent in a founder's name. It is a fair question, and most AI vendors do not answer it directly. This piece does.
Two ways AI systems fail, and why it matters which one you are dealing with
Every system makes mistakes eventually, whether it is software or a person. The useful question is not whether an error will happen. It is what happens next.
Silent failure
The system gets something wrong and nobody notices until real damage is done. A payment allocated to the wrong account, a follow-up that never gets assigned, a reply that should never have gone out. This is common in systems built without a deliberate strategy for catching errors.
Surfaced failure
The system gets something wrong, flags it clearly, and routes it to a person before it causes harm. This is the outcome every well-built AI system should be designed around, and it is the standard every Keystone build is held to.
The difference between the two is not luck. It is architecture, decided before a single line of the system is built.
How Keystone builds this in: three live systems
Principles are easy to write down. Here is what error handling looks like in systems that are running today.
AR Guardian: invoice reconciliation
AR Guardian matches payments received in Xero against open invoices in Salesforce automatically. The clean cases, and most cases are clean, close themselves.
Anything that does not match cleanly is flagged with context: which invoice, which payment, what the system thinks is wrong. The senior accountant reviews; they do not investigate from scratch. The system does not guess and move on. It flags the exception for human review instead.
Legal Call-Actions: call transcription
Legal Call-Actions takes the transcript of a client call and generates a structured action list: what needs to happen, who should do it, by when. The fee-earner reviews it, edits anything that needs adjusting, and assigns.
Every single action carries a transcript reference. If a client later asks "did we agree X on that call", the relevant part of the call surfaces instantly. The system is not asking to be trusted blindly. It is built so its work can be checked in seconds, not reconstructed from memory.
Waste operations hub: nine agents, one live business
The waste operations hub runs nine specialist agents across a live 30-vehicle operation, covering billing, AR, customer service, reconciliation and reporting. When payments are reconciled against invoices, exceptions surface for review rather than being silently applied.
The accountant in finance, the fee-earner in a legal practice, the team running the operation: across all three, a person always makes the final call on anything the system is not fully confident about.
The principle: review where it matters, automation where it doesn't
Not every step needs a human checking it. That would defeat the purpose of automation entirely.
The judgement is in knowing which steps carry real consequences and building a checkpoint there, while letting the low-risk, high-confidence work run untouched. A payment that matches perfectly against an invoice does not need a human to bless it. A payment that does not match cleanly does.
That distinction, made deliberately for every system Keystone builds, is what "human in the loop" actually means in practice, rather than as a compliance buzzword.
What to ask any AI provider before you commit
Whoever you choose to build with, these four questions will tell you quickly whether errors have been thought about or left to chance.
Does the system tell you when it is uncertain, or does it guess silently?
A system that always produces an answer is not the same as a system that is always right. You want one that knows the difference and says so.
Can you trace any specific output back to the data it came from?
If an action, a match or a draft cannot be traced to its source, checking it means redoing the work. Traceability is what makes review fast enough to actually happen.
What happens to the exceptions?
Do they disappear, get logged somewhere nobody looks, or get routed to a person who can act on them? Only one of those answers is acceptable.
Who is accountable if something goes wrong: the vendor, or you?
Get a clear answer before the build starts, not after the first mistake.
If you want to see how these questions would be answered for a specific process in your business, that is what the Discovery Call is for. It is free. You can also see how each of these systems works in detail across our case studies.