Give an AI colleague responsibility for producing the work. Keep the acceptance standard outside its control. Before it starts, define the result and decide which parts you can check independently, leaving the judgments those checks cannot settle with a person. Otherwise, you’re stuck approving every small step or taking the agent’s word that it’s finished.
Anthropic’s October 22 research with Theorem makes this distinction unusually concrete. Claude produced mathematical proofs covering 239 test entry points across 123 open-source software libraries. A separate proof checker determined whether the proofs satisfied the stated requirements.
I would borrow that division of responsibility for business work, even where a mathematical proof is out of reach.
In brief
An agent can have considerable freedom in how it solves a problem while having no freedom to lower the acceptance standard. Start with one recurring assignment. Write down what must remain true, separate checkable facts from human judgments, and make the agent return unresolved failures rather than explain them away.
Give a colleague work with independently checkable results
There is an awkward assumption behind many AI reviews: if a human cannot personally inspect everything the agent produces, the agent cannot be trusted with substantial work.
That leaves the human as the bottleneck forever.
In this research, the successful proofs amounted to about 180 million lines. Nobody is going to read that over coffee. Instead, the proofs were checked by software built to determine whether the mathematical argument met its specification. The Rocq project’s description explains the underlying distinction: programs and proofs can be checked against formal requirements by a defined verification system.
The proof checker tests a specific claim against defined requirements, independently of the AI’s assessment of its own answer.
Most business assignments cannot be verified mathematically. Parts of a customer brief can still be checked against records, leaving a manager to review the judgments and exceptions.
A reference number either exists in the approved records or it does not. A quoted price either matches the current price list or needs investigation. Those checks leave the reviewer with a smaller, more meaningful job: deciding whether the proposed response makes sense for that customer.
If the manager still has to reconstruct every source check, you haven’t given them much time back.
A passed check is only as useful as the requirement
The limits of Anthropic’s result matter as much as its scale.
The technical appendix specifies proofs for particular compiled programs on RISC-V Linux, with inputs under 64 MiB and defined assumptions about execution. That is not a guarantee that every use of every library is free of bugs. A proof answers the question it was built to answer.
Business checks have the same limitation, without the mathematical certainty.
A proposal can contain every required heading and still promise something your delivery team cannot do. An account summary can cite genuine records while missing the most important unresolved commitment. A clean spreadsheet can faithfully apply the wrong policy.
Who owns that standard? Someone who has to answer for the proposal, the missed commitment, or the policy. Let the agent point out omissions and suggest better checks, but keep approval of those changes with the owner. A failed check should remain a failure until the work is repaired or the owner explicitly changes the requirement.
Try the pattern on an account brief
Consider a hypothetical team preparing renewal briefs. Today, a manager reads several customer records, assembles a summary, then checks the assistant’s draft against the same records. Much of the supposed time saving disappears into review.
I would give the agent a fuller assignment, with narrower authority.
Its job is to assemble the brief from an approved set of records, identify unresolved commitments, and recommend what the account owner should discuss. It can choose how to organize the material and investigate contradictions within those sources. It cannot change customer records or send the recommendation.
Before it starts, the account owner defines what an acceptable brief must contain. Every commitment needs a source. Dates and amounts need to match the underlying record. Missing evidence stays visible. The recommendation must distinguish documented facts from the agent’s interpretation.
Then separate the review. Check dates, amounts, and source references against the records using checks the agent cannot alter. Where no reliable automated check exists, keep that step explicitly human. The account owner reviews the recommendation and the unresolved exceptions, rather than treating the entire draft as equally uncertain.
When a check fails, return the failure to the agent. Let it repair the work or explain why the source material prevents completion. Do not let it remove the requirement.
Ask the vendor to show you a rejection
In the next demonstration, ask what happens when the agent returns something plausible but unacceptable. Ask who controls the acceptance rules, whether the agent can change them, and what evidence reaches the reviewer when a check fails.
Ask for an independent check against a protected source, and have the vendor explain exactly what any second assistant’s review checks.
I want AI colleagues to take on harder work. But before buying that promise, I would want to see the rejected brief and what the agent did next. Did it find the missing evidence, leave the question open for the account owner, or quietly drop it from the next draft?
Research and structure: Mai. Editorial direction and voice: John Lipe.