An AI agent can finish a task and still leave the business with unfinished work.
It may produce a reconciliation, update a file, prepare a migration or draft a customer follow-up. The output can look complete. The model may even report success.
None of that means the business should accept it.
The missing piece is an acceptance test: a clear definition of the evidence, tolerances and decision needed before an agent’s output can move to the next stage of the workflow.
This becomes more important as models take on longer jobs. Google positions Gemini 4 Argon as a model for complex, long-horizon work across software engineering, finance, legal work and cybersecurity. Google also reports using it in internal workflows. Those are Google’s claims, not independently verified business outcomes.[1] The launch also triggered an active Hacker News discussion about capability, harness choices and how people evaluate agent work.[2]
The useful question for an SME is not whether one new model has crossed a benchmark.
It is this:
What must be true before the business accepts an agent’s work?
A prompt is not an acceptance test
A prompt tells the agent what to attempt.
Reconcile the supplier statement against our accounts payable ledger and identify unmatched items.
An acceptance test tells the business what a valid result must contain.
Every statement line must be matched to a ledger entry, listed as a documented timing difference, or placed in an exception queue with the source record attached. The total unresolved value must equal the difference between the statement and ledger balances. Nothing posts without the finance manager’s approval.
The first instruction starts the work. The second defines “done.”
This distinction matters because an agent can follow the task while still producing an output that is unusable. It may omit evidence, hide uncertainty in a summary, accept a near match that violates policy, or stop before the business event is complete.
The model should not decide its own standard of acceptance. The domain expert should.
An accountant knows what makes a reconciliation defensible. An operations manager knows which exception must stop fulfilment. A customer-service lead knows which promise requires approval. Their judgment becomes the specification against which the digital coworker is tested.
Five parts of a practical acceptance test
You do not need a large governance programme to start. Pick one recurring task and define five things.
1. Required evidence
List what the agent must show, not just what it must conclude.
For a supplier reconciliation, that might include:
- the supplier statement and period;
- the ledger extract used;
- the matched record identifiers;
- the amount and date for each match;
- all unmatched items;
- the reason assigned to every exception.
“Reconciled” is a claim. The evidence lets a person or another control verify it.
2. Tolerances
Most business processes contain legitimate variation. Define what is allowed.
A payment may differ by a small bank fee. A delivery date may fall one business day outside the planned date. A CRM record may be accepted without a phone number but not without a company identifier.
Write the tolerance as a rule the operator can inspect:
- exact match required;
- variance allowed up to a stated amount;
- date difference allowed within a stated window;
- confidence below a stated level goes to review;
- missing mandatory fields always fail.
Without tolerances, the agent either stops too often or quietly makes judgment calls nobody approved.
3. Rejection reasons
A failed output should not disappear into “needs review.” Give the agent a small set of explicit rejection reasons.
For example:
- source document missing;
- duplicate record suspected;
- value outside tolerance;
- conflicting identifiers;
- period closed;
- approval authority unclear.
This improves the next human action. It also creates operating data. If one rejection reason appears repeatedly, the underlying process, data or skill may need repair.
4. Stop conditions
Define when the agent must stop instead of improvising.
A stop condition might be triggered when the agent encounters a closed accounting period, a customer complaint with legal implications, a request to change bank details, or a write that cannot be reversed safely.
The stop condition is not failure. It is correct execution.
A reliable digital coworker knows when the assigned job has reached the edge of its authority.
5. The acceptance event
Name the event that changes the status of the work.
Who accepts it? What evidence do they inspect? What system records the decision? What happens after acceptance?
For the reconciliation example, the acceptance event could be:
The finance manager reviews the exception summary and control total, accepts the reconciliation in the finance queue, and authorises the approved adjustment batch for posting.
Now the work has a visible finish line. The agent does not mark itself successful. The workflow records an accepted business outcome.
A concrete SME example
Consider a hypothetical SME that receives a monthly supplier statement containing 180 line items.
The agent’s job is not “handle the statement.” That is too vague.
Its job is to prepare a reconciliation that meets the acceptance test:
- Read the statement and ledger export.
- Match records using invoice number, amount, date and supplier identifier.
- Apply only the documented tolerances.
- Put every unresolved line into one of the approved rejection categories.
- Produce a control total proving that matched items plus exceptions equal the statement balance.
- Stop if bank details changed, the period is closed, or the documents conflict.
- Send the evidence packet to the finance manager.
The finance manager then accepts or rejects the packet. Only accepted adjustments proceed to posting.
This design gives the agent useful work without pretending that activity is the same as completion. It also gives the manager a much better role than manually repeating every matching step. The human owns the acceptance decision; the agent does the evidence-heavy preparation.
Start with one workflow this week
Choose a task that is repetitive, bounded and easy to inspect. Then write one page with:
- the task and business outcome;
- required source evidence;
- allowed tolerances;
- rejection reasons;
- stop conditions;
- the person or role that accepts the work;
- the system event that records acceptance.
Run the agent on real examples, including awkward ones. Track why outputs are rejected. When the same correction appears repeatedly, turn it into a rule, test or reusable skill.
Better models will keep expanding what an agent can attempt. That is useful, but capability does not define completion.
The business does.
Sources
[1] https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon — Gemini 4 Argon: our next era of frontier intelligence [2] https://news.ycombinator.com/item?id=49913571 — Gemini 4 Argon | Hacker News