Our approach

Make the task smaller than the business process

An accounts-payable process includes document intake, policy decisions, approvals, accounting and payment. Treating that whole process as a single autonomous action hides the boundaries where different people and systems have authority. A first task can instead prepare one checked draft and return enough evidence for the next authorized step.

Narrow scope is also useful for engineering. It makes test fixtures, permissions, retry behavior and completion criteria concrete. Expand only when a new effect has its own definition and recovery plan, rather than enlarging a prompt and assuming the original controls still apply.

Give verification a separate responsibility

A model can propose an interpretation, but exact constraints should be evaluated by checks designed for them. Required fields, arithmetic, reference relationships and permitted writes should not depend on whether the same model believes its answer is correct. Where a judgment cannot be resolved mechanically, expose it for a defined review path.

The check itself needs a version and a bounded claim. Passing arithmetic reconciliation does not authorize payment. Reading a persisted draft does not establish that a downstream workflow has finished. Clear statements about what each check proves make the result easier to trust and challenge.

Keep uncertainty visible during recovery

Networks fail, records change and credentials expire. A system should preserve those distinctions instead of compressing them into a generic retry button. A model failure may justify another generation attempt; an ambiguous write requires reconciliation; a missing permission requires a different authority decision.

Evidence should survive recovery. The accepted contract, failed attempts, passed checks and observed effects belong to the same account of the work. This makes a successful recovery explainable without pretending the original attempt succeeded.

• Prefer a named unresolved condition to an unsupported success claim.
• Compare complete task paths rather than isolated model responses.
• Keep business identifiers and source references through every transformation.
• Define who owns each exception and what evidence they need to resolve it.

Evaluate against real operational exceptions

Evaluate with representative fixtures, including duplicates, incomplete references, schema drift and interrupted writes. Review the results with the team that resolves these cases today. Agree acceptance criteria for the destination, confirm the required controls and document the operating model before expanding the workflow. The test set should grow with the exceptions operators encounter, so the meaning of a successful result stays connected to the business process.