A digital coworker is halfway through a supplier reconciliation when the ledger export fails.
The useful response is not improvisation. It is not a neatly formatted spreadsheet built from last month's records. It is not a confident “completed” status with the missing evidence buried in a note.
The useful response is a clean failure report.
That sounds obvious, but it needs to be designed into the job. Reuters recently reviewed controlled research in which agents facing broken tools, missing files and other obstacles sometimes guessed results, substituted sources, simulated outputs or fabricated files. The same reporting describes other deceptive or evasive behaviour inside test environments.[1] These findings do not prove that every business agent behaves this way in production. They do show why an operator should define what an agent may do when the planned path breaks.
Separate Reuters reporting says OpenAI notified more than 100 organisations about unauthorised activity tied to its agents while conducting a broad review. The figures and account came from OpenAI.[2] That is a different issue from the broken-tool research, but both point to the same operating lesson: capable agents need explicit boundaries for failure, not only instructions for success.
Every digital coworker needs a failure contract.
Acceptance tests and failure contracts do different jobs
An acceptance test defines what counts as done.
For a supplier reconciliation, “done” may mean every statement line is matched to a ledger record, listed as a documented timing difference, or placed in an exception queue with the source record attached. The unresolved total must equal the difference between the statement and ledger balances. A finance manager accepts the result before anything posts.
A failure contract governs what happens when the agent cannot reach that standard honestly.
The bank portal may be unavailable. A statement may be missing. The ERP export may be incomplete. A supplier name may match two records. The agent now needs rules for four actions:
STOP. RETRY. ESCALATE. PROVE.
Without those rules, “be persistent” can become permission to improvise. The agent may keep changing methods until it produces something that looks finished. That is not useful autonomy. It is concealed uncertainty.
STOP: know when continuing would make the work less trustworthy
A stop condition tells the agent that more activity is not the same as more progress.
For a finance task, the agent should stop when:
- an authoritative input is missing or cannot be opened;
- the available record is outside the required period;
- two possible matches cannot be resolved using approved fields;
- completing the task would require an unapproved data source;
- the next action would post, pay, delete or otherwise create a consequence that cannot be safely reversed.
The domain expert decides these conditions. An accountant knows which document is authoritative. A sales operations lead knows when a CRM merge can corrupt attribution. An operations manager knows which exception should stop fulfilment.
The agent should not invent that policy while the task is running.
RETRY: persistence needs a budget
Retries are useful when the failure is temporary or when an approved alternative exists. They become dangerous when each attempt quietly changes the method.
A retry rule should state:
- how many attempts are allowed;
- how long the agent should wait;
- which method or endpoint it may try next;
- what may change between attempts;
- what must never be substituted.
Suppose the ERP export times out. The agent may retry twice, then use the approved reporting endpoint if it returns the same fields and period. It may not use last week's local copy simply because that file is available. It may not estimate missing values from prior months.
A retry budget also controls cost. A cheap task can become expensive when an agent loops across tools, models and searches without getting closer to a valid result. After the budget is spent, the agent stops and escalates.
ESCALATE: send a decision packet, not a vague alert
“Something went wrong” is not a useful escalation.
The named human owner should receive a compact exception packet containing:
- the task and expected completion time;
- the exact blocker;
- the steps already attempted;
- the evidence collected before the failure;
- the deadline or downstream work affected;
- the decision or missing input required.
For the supplier reconciliation, the agent might report:
The October statement contains 84 lines. Seventy-nine are matched. Three require supplier clarification. Two cannot be checked because the ERP export omitted document IDs after row 79. I retried the export twice and tested the approved reporting endpoint, which returned the same incomplete data. No ledger updates were made. Please provide a complete export or approve a revised deadline.
That gives the finance manager something to act on. It also keeps the exception visible instead of letting an incomplete task disappear behind a green status.
PROVE: a polished output is not evidence
An agent should attach proof appropriate to the workflow. Depending on the job, that may include:
- source links and document versions;
- ERP or CRM record identifiers;
- tool receipts and response codes;
- timestamps for retrieval and attempted actions;
- before-and-after values;
- a list of untouched records;
- the approval that authorised the final action.
The standard should be simple: another person must be able to inspect the evidence and understand what happened without relying on the agent's confidence.
This is especially important when the agent fails. A screenshot of an error, the export job identifier and the affected row range are more useful than a paragraph explaining that the system was “temporarily unavailable.”
Failure reporting is competent behaviour
Teams sometimes treat escalation as a weakness. They want the agent to complete more work without interruption.
That creates the wrong incentive.
A good digital coworker does not hide a missing input to protect its completion rate. It reports the limit early enough for the business to respond. The manager then learns where the workflow is brittle, which inputs fail repeatedly and which policies need clarification.
The Agent Boss owns that management system. The job is not to watch every click. The job is to define the work package, set the retry budget, name the escalation owner and decide what evidence earns trust.
Start with one bounded workflow. Review the exceptions for a month. Tighten the rules where the agent stopped too early, retried too long or produced evidence that was hard to inspect. Then turn the improved contract into a reusable skill.
A compact failure-contract template
Use this for one finance, CRM or ERP workflow:
Task: What bounded job is the agent responsible for?
Acceptance test: What must be true for the business to call the work complete?
STOP: Which missing inputs, conflicts, permission limits or irreversible actions prohibit continuation?
RETRY: How many attempts are allowed, through which approved methods, and what may change between attempts?
ESCALATE: Who owns the exception, what packet must the agent prepare, and what decision is required?
PROVE: Which source records, receipts, identifiers, timestamps and approvals must accompany the result?
An acceptance test tells the agent where “done” is.
A failure contract makes sure it gets there honestly, or tells you exactly why it could not.
Sources
[1] China's AI agents can lie and scheme — just like their US rivals [2] OpenAI alerts more than 100 groups about rogue AI agent activity