AI agents do not fail only because the model is weak. They fail because the business never defined what correct work looks like.
This is easy to miss. An agent can produce a polished report, close a queue, update a CRM record, or reconcile a spreadsheet. The activity looks productive. The result can still be wrong in ways that are expensive to detect later.
A recent practitioner case made the problem visible. A team used multiple AI agents on a large game-decompilation project. The system made visible progress, but generated wrong function signatures, incorrect types, faulty layouts, and invented logic. A reviewer agent did not solve the problem because it could be persuaded by the worker's own explanation. Progress changed when the team introduced machine-checkable, byte-level verification.
The operator lesson for an SME is not about decompiling software. It is simpler: before a digital coworker starts doing real work, the domain expert must define PASS and FAIL.
The expensive failure is productive-looking wrong work
Most teams evaluate AI work too late and too subjectively. Someone reads the output, decides it “looks reasonable,” and lets it move forward. This works for low-consequence drafting. It breaks when an agent touches invoices, discounts, customer records, compliance evidence, or operational decisions.
Consider an accounts-receivable agent. “Match the payment to the invoice” sounds clear until the agent meets partial payments, bank fees, duplicate references, credit notes, currency differences, or a customer that paid several invoices in one transfer. A fluent explanation does not prove that the allocation is correct.
The business needs an acceptance test. That test might require:
- the allocated amount to reconcile to the bank receipt within an approved tolerance;
- the invoice and customer identifiers to exist in the ERP;
- duplicate references to enter an exception queue;
- credit notes and cross-currency differences to require human review;
- every accepted match to retain the source records and decision trace.
Now the agent has a job it can attempt, the system has a way to grade the attempt, and the finance lead has evidence to review.
Domain experts are becoming acceptance-test architects
The highest-value AI architect in many SMEs will not be the person who writes the longest prompt. It will be the person who can turn professional judgment into observable conditions.
An operations manager knows which order changes are routine and which ones create downstream risk. An accountant knows when a reconciliation difference is acceptable and when it signals a deeper problem. A sales leader knows which CRM updates are administrative and which commercial decisions need approval.
That knowledge usually lives in habits, examples, and exceptions. To make it usable by digital coworkers, convert it into four things:
- Expected outcome: the business result the work must produce.
- Acceptance conditions: the checks that must pass.
- Automatic rejection conditions: the failures that send the work back or stop the run.
- Escalation conditions: the cases that require human judgment.
This is how domain expertise becomes operating IP. The expert is not removed from the workflow. The expert defines the standard the agent must meet.
A reviewer agent is not independent evidence
Adding a second agent to review the first can help, but it does not create independence by itself. If both agents read the same explanation, share the same assumptions, or optimise for the same plausible narrative, the review can become agreement theatre.
The reviewer needs a separate evidence source and a narrow mandate. For invoice matching, it should compare against bank records, ERP records, tolerance rules, and segregation-of-duties policy. For CRM updates, it should check required fields, source timestamps, consent status, ownership, and the permitted range of changes.
The reviewer should verify the result, not admire the reasoning.
This is also why human approval needs a concrete evidence packet. “Approve this update” is a weak gate. A useful approval request shows the proposed action, the affected record, the rule applied, the source evidence, the exception status, and the rollback option.
Build a five-part acceptance test before automating
SMEs do not need a large testing department to start. Use one recurring workflow and build a small acceptance pack.
1. Choose real cases
Select examples from normal work, not a clean demo. Include successful cases, missing data, contradictory inputs, unusual customers, and at least one case where the correct action is to stop.
2. Write five PASS conditions
These should be observable. “High quality” is not observable. “Every recommendation cites the current policy paragraph and identifies the affected account” is.
3. Write five rejection conditions
Name the failures that must not pass: missing source evidence, an amount outside tolerance, an unauthorised field change, stale data, or a required approval that is absent.
4. Separate deterministic checks from judgment
Use code, database constraints, reconciliation rules, schemas, and allowlists where the answer is objective. Reserve a stronger model or human reviewer for cases that genuinely require interpretation.
5. Record accepted outcomes, not completed tasks
Track first-pass acceptance rate, rework, reversals, escaped errors, approval latency, and the reason an attempt failed. Task volume tells you the agent was busy. Accepted outcomes tell you the workflow worked.
Precise feedback changes the model economics
When a system can grade work reliably, cheaper models can attempt more of the routine work. Stronger models and human experts can focus on ambiguous exceptions, policy changes, and high-consequence decisions.
This is a better routing strategy than using the most capable model for every step. It aligns cost with risk:
- deterministic checks for objective rules;
- lower-cost agents for bounded attempts with clear feedback;
- stronger models for complex synthesis;
- humans for accountability, exceptions, and final approval where consequences matter.
Better orchestration does not mean removing people. It means using human judgment where it has the highest value.
Cold-start test the skill
A separate practitioner experiment offers a useful method. A developer paid people to follow a README while thinking aloud. The testers exposed broken assumptions that the author could no longer see: unexplained terms, missing purpose, confusing order, and steps that only worked because the author knew what to do next.
Test an agent skill the same way. Give it to a fresh operator or a new agent, provide a real case, and do not rescue the run. Every hesitation, guess, missing input, or improvised workaround is a defect in the skill.
Then update the instructions, examples, checks, and stop conditions. Do it once. Skill it up. Do it again.
Start with one workflow this week
Pick one repeated finance, CRM, or operations task. Before choosing a model or automation platform, ask the domain owner to produce:
- five examples of correct work;
- five PASS conditions;
- five automatic rejection conditions;
- the evidence required for approval;
- the cases where the agent must stop.
That package is more valuable than another generic prompt library. It gives your digital coworker a measurable job, gives your reviewer independent evidence, and gives management a defensible way to decide whether the workflow is ready to scale.
Orchestrate, don't operate. Define correctness first.
