Delegate the Inputs, Own the Outputs

When you are deciding how much an AI agent can do without you watching, I would start with the work you are handing over, not with how much you trust the model.

Can you check the result quickly, against something more reliable than how convincing it sounds? And if the agent gets it wrong, can you catch the mistake and undo the consequences at a cost you are willing to pay?

Those questions give you a useful starting boundary. Let agents help with gathering information, checking sources and producing drafts, but keep a named person responsible for the checks and a person in front of client-facing actions until the workflow has been properly tested and approved for them.

By freedom on the input side, I mean freedom to prepare work within those limits. I don't mean permission to send it, commit the firm or pass unchecked information into someone else's decision.

That last part matters because the first work firms delegate often looks harmless. Through a franchise network's delivery data, I have watched hundreds of service firms adopt AI, and fetching and summarizing information across Gmail, Drive and Slack is a common place to start.

It is useful work to hand over. Instead of a person opening several systems to gather the same information, an agent can bring it together and prepare something they can use.

The failures I've seen also come from that work, an analysis with a wrong number, an unchecked report, a support response that goes out without the review it needed. The task was possible to check, but the check didn't happen.

I would not describe those teams as careless. The output looked complete, the queue was long, and forwarding it was the easiest next action, while nobody had made the check a dependable part of the job.

That is the difference between saying a task is checkable and knowing it will be checked in your firm. The first is a property of the work, the second needs a person, time and a place in the workflow.

AI also gives you a different kind of mistake to look for. A human who is uncertain often gives you signs of it, while an AI answer can arrive with a confident explanation, neat formatting and a source that does not say what the answer claims.

The finished appearance encourages the send even when the content is wrong. So part of the training is learning to ignore that appearance long enough to trace the number or reference back to its origin.

I think of checking AI output as a skill people need to learn. Knowing the service helps, but people also need to recognize where generated work is likely to mislead them and what evidence is enough to accept it.

There is a useful caution about relying on your own impression of the work. In METR's July 2025 randomized trial, 16 experienced open-source developers worked on 246 real tasks, with AI tools allowed or not allowed.

When AI was allowed, they took 19 percent longer. Afterward they still believed it had made them about 20 percent faster.

That result doesn't measure your service firm's review cost, and it doesn't prove checking alone caused the slowdown. It does show that experienced people can misjudge whether a tool helped them, so I would measure completed work rather than rely only on how fast using the agent feels.

The two-question framework comes from Jina Yoon's PostHog article on agent autonomy, which asks whether the work is easy to check and whether mistakes are cheap to undo. I am applying that way of thinking to the work of a service firm, not presenting it as a scientific standard.

You can see why it is more useful than a general question about trust. A model can be good at finding a document and still be the wrong thing to leave alone with permission to send a price to a client.

And a better model can change what is feasible without removing the need for controls. The task, the data, the permissions and the person who will act on the result all matter, so model quality is part of the decision rather than the whole decision.

The simple version gives you four cases. If the work is hard to check and a mistake would be costly to undo, keep the agent in a supporting role, it can gather material or suggest options while a person owns the consequential work.

Pricing and scoping can fall there. The agent can add up costs, but deciding what a client really needs and what your firm can promise may involve judgment that a quick check will not settle.

If the work is hard to check but still cheap to redo, the agent can draft and a person can review each result. A first pass at a client email can sit in that group while it remains an unsent draft, because you can replace it without anyone outside the firm having acted on it.

If the work is easy to check but the action would be expensive to undo, let the agent prepare it and put a gate before the action. An invoice may have totals you can verify automatically, but sending the wrong invoice creates a client problem even if the accounting entry can later be reversed.

If both the work and its consequences are genuinely easy to check and undo, it is a candidate to run without someone watching every step. An internal extraction task can fit, provided the checks are operating and a named owner deals with failures.

Those examples are conditional, not permanent labels on tasks. An internal summary used for convenience has different stakes from the same summary quoted in a signed proposal, and you should ask the questions again when the use changes.

Chasing a client for missing documents is a tempting example of work to leave with an agent. It sounds routine, but a reminder still leaves the firm, and a wrong recipient, repeated request or badly timed message can have consequences you cannot remove by deleting your copy.

In Uku's 2026 accounting field report, 68 percent of respondents said they would hand document-chasing to an autonomous agent. That is willingness to delegate in that report, not evidence that every reminder workflow is safe to run without approval.

Under the starting rule in this piece, the agent can prepare the reminder and a person approves the send. A firm can later approve a tested routine-send workflow explicitly, but calling it document-chasing doesn't grant that permission by itself.

The same report found no respondent saying they already fully trusted AI, and roughly six in ten made trust depend on human approval before anything was sent or filed. Those findings concern surveyed accounting firms in eight countries, not every accounting firm.

Compare that with Upwork's Q1 2026 survey, where 62 percent of its SMB-leader sample said they were very or extremely confident handing high-stakes work to agents. The sample's revenues ranged primarily from below $1 million to $49.9 million, so it extends beyond the firms I usually write for.

These surveys ask different questions of different groups. I wouldn't line them up as proof that one group is reckless and the other is afraid, or use either as a test of whether your own agent should send something.

Go back to the job and its consequences. A confident owner can have an unsafe workflow, and an owner who doesn't fully trust AI can still build a useful, well-controlled one.

There is a stronger objection to the input/output rule than any survey, and I agree with it. An input can cause damage without ever being sent to a client, because someone inside the business may use it to make a decision they cannot easily reverse.

Suppose an agent summarizes client notes and an account lead uses that summary to set the scope of a proposal. Once that happens, it is no longer just a convenient recap, it is evidence supporting a promise.

The check needs to follow that use. Match the relevant summary back to the source before relying on it for the scope, and name who is responsible for that match, otherwise the human approval at the end is signing something whose foundation nobody checked.

That is why I keep the owner of the check next to the delegation rule. Moving work inside the building doesn't make it safe, and putting a human after the agent doesn't help if the human has no time or information to verify it.

You can improve both sides of the decision. To make checking easier, ask the agent to return the source with each important claim, separate facts from its suggestions and flag the parts it could not confirm.

You can use another agent to challenge the first result, but don't assume agreement between two models proves it is right. When the claim depends on a client's records or an external source, the check needs to reach that evidence.

For repeated low-risk work, you can build automatic checks and sample the output rather than have a person read every line forever. The sample has to be appropriate to the risk, and failures need a route back to someone who can stop or change the workflow.

To make undo easier, keep drafts as the default, limit what the agent can access and change, test restoration from backups, and separate preparation from the action that commits the firm. Those are choices you can make without waiting for another model release.

Anthropic's February 2026 research on agent autonomy classified only 0.8 percent of observed tool calls as appearing irreversible. It also found that about 80 percent came from agents appearing to have at least one safeguard, while warning that its classifier tended to overestimate human involvement.

That is evidence from the usage the researchers studied and the classifications they made. It is not a claim that 99.2 percent of actions in your firm are safe, or that restoring a file restores a client's confidence after a bad message.

The Replit database-deletion incident reported in July 2025 gives a concrete reason to care about permissions. A coding agent deleted a production database during an explicit freeze, according to the reporting on Jason Lemkin's account.

My operational conclusion is that an instruction not to act should not be your only protection against an action with that much consequence. Restrict the permission, isolate the work and test the recovery before allowing the agent near production.

You also need to know what earns a workflow more freedom. I would write down which checks must pass, how you will detect a failure, who can stop it and which actions still need a person, then test that with the actual work rather than a single impressive demonstration.

The amount of evidence you need depends on what a wrong result costs. I cannot give you one universal number of clean runs that makes every workflow ready to send, and neither can the task's name.

So start with your repeated work and sort it by the thinking required and the cost of getting it wrong. For the tasks worth delegating, answer the check and undo questions against their real downstream use.

Choose one where you can put the controls and the owner in place now. Let the agent prepare the work, inspect what the whole process produces, and keep the client send where the current approval rule says it belongs until you deliberately change that rule.