An answer is not an outcome: what has to be true before AI can finish work for you

The moment the answer is right and nothing has happened

Ask an assistant how to chase an unpaid invoice and it will give you a decent answer. Ask it to draft the message and it will draft a good one. Ask it to send the message, log that it was sent, notice when the customer does not reply, send the next one, stop when payment lands, and tell you only if something goes wrong, and you have described a job. The answer was the easy part.

We think this is the most common misunderstanding about AI in business right now. People see the quality of the answers and assume finished work is close behind. Sometimes it is. Usually the gap is not the model. It is everything around it.

What is genuinely true today

We want to be fair to the tools, because they have moved. OpenAI's agents documentation describes agents that plan, call tools, hand off between specialists and keep enough state to complete multi-step work, and it documents guardrails and approval flows that pause before risky steps [S29]. Anthropic's computer-use documentation describes a model that can take screenshots and operate a mouse and keyboard, with the advice to run it in an isolated environment and have a person confirm decisions that carry real consequences [S30]. Those are vendor claims from official pages, checked on 9 September 2026, and they describe capability that exists.

So an assistant can act. What the same documentation says, in every case, is that it should act inside limits with a person confirming what matters. That is not a disclaimer. It is a description of how finished work actually gets finished.

The four things an answer does not have

A record to act on

To chase the invoice, the system needs to know which invoice, for which customer, at which amount, sent on which date, with which terms. If that lives in three places or in someone's head, the assistant either guesses or asks. Guessing is how you get the wrong customer chased. Asking is fine, but then the person is still doing the work.

Authority to act

Sending a reminder is one thing. Offering a payment plan, waiving a fee or threatening to pause work is another. Somebody in the business decides which of those an assistant may do on its own, which need a yes, and which it may never do. If nobody has written that down, one of two things happens: the assistant does too little and people stop trusting it, or it does too much and people stop trusting it. The approval boundaries worksheet exists because this decision is almost never made before the tool is bought.

A check that the outcome happened

"Sent" is not "paid". A message going out is evidence that a message went out. Finished work is the money in the account, the appointment confirmed, the part delivered. Somebody has to decide what counts as evidence for each piece of work and make sure the system looks for it. Without that, the assistant reports success on the easy part and the business finds out about the hard part from the customer.

Follow-up when it did not

Most work does not complete on the first try. The customer does not reply, the supplier is closed, the tenant is not home. A system that finishes work needs an exception route: a place the item goes when the normal path fails, and a person who looks there. This is the loop, and it is the difference between a workflow that runs steps and a system that gets things done. The systems and loops guide explains that distinction without any product in it.

Why this is good news

It means the useful work is available to you now and does not depend on which model wins next year. Records, authority, evidence and exception routes are things you can put in place this month. They make work finish more reliably with or without AI, and they are exactly what any capable system needs before it can carry more. Anthropic's own guidance on building agents says to add complexity only when it demonstrably improves outcomes [S11]. We would put it more bluntly: fix the handoff before you buy anything that promises to automate it.

A checklist before you hand work to any system

1. Can you point to the record the work acts on, in one place, with the fields the work needs?
2. Is it written down what the system may do alone, what needs approval, and who can revoke it?
3. Have you defined what counts as evidence that the outcome happened, not just that a step ran?
4. Is there a named place unfinished items go, and a person who looks there on a fixed day?
5. Have you run three real items through it with a person watching before you let it run unattended?

If any answer is no, the work is not ready to hand over, and that is true whether the system is an assistant, an automation or a new hire. The handoff assessment walks one piece of work through those questions and gives you a one-page action sheet.