When Is an AI Agent Actually Done?

An AI agent can produce a strong answer in seconds. It can write a customer email, outline a sales follow up, summarize a support case, or recommend the next move. That is the visible part of the work, and it is easy to mistake it for the result.  

But a useful answer is not the same thing as completed work. 

The difference matters most when an agent is asked to handle a recurring business responsibility. A draft email does not help a prospect until it is sent. A meeting brief does not help a team until the right people can use it. A support summary does not help a customer until the case moves forward. The real question is not whether the agent produced something convincing. It is whether something changed in the place where the work belongs. 

This is where many agent projects lose their way. They measure generated output because it is easy to count. Messages drafted. Records summarized. Recommendations made. Those are useful steps, but they can create an illusion of progress while someone still has to complete the work manually. 

The better standard is simple: what observable fact proves that the task is done? 

The answer is often the beginning, not the end 

Consider a simple lead follow up. An agent researches the account, identifies the relevant context, writes a thoughtful email, and suggests a time for a call. The draft looks good. Yet if it sits in an inbox, the prospect has not received anything and the sales process has not moved. 

The same pattern appears in every operating function. An agent may prepare a calendar invitation without creating the event. It may spot a billing exception without escalating it. It may organize a support issue without updating the ticket that the customer can see. In each case, the agent has done useful preparation, but the business outcome remains unfinished. 

That does not make drafting unimportant. Good preparation saves time, gives a person better context, and reduces the chance that routine work falls through the cracks. The problem begins when a team uses one vague word, done, for every stage of the process. 

Once that happens, it becomes hard to see where a workflow really stops. A dashboard may report a successful agent run while a manager is still looking at an unsent message or an unresolved request. The system looks busy, but the work has not crossed the line into the real world. 

Four states make the gap visible 

Teams need a small vocabulary that separates useful progress from a verified result. Four states are usually enough. 

Proposed 

The agent has identified an action worth taking. It may have gathered information, noticed a problem, or suggested a next step. Nothing has been prepared or carried out yet. 

For example, an agent might say that a customer has not replied for ten days and that a follow up would be useful. That is a helpful signal, not a completed task. 

Drafted 

The agent has prepared the material needed to act. It may have written an email, created a meeting brief, assembled a report, or proposed a CRM update. A person now has something concrete to inspect. 

Drafted work is often where agents provide immediate value. It removes repetitive preparation while leaving the business owner in control. Still, the outcome has not happened until the next step is accepted or carried out. 

Approved 

The responsible person has reviewed the proposed action and accepted it. This is the right finish line when the decision affects a customer relationship, money, reputation, or a commitment that should remain human owned. 

Approval should not be treated as a failure of autonomy. It is an explicit operating boundary. A well designed agent workflow makes that boundary easy to see. It shows what is ready, what decision is needed, and what will happen after the decision. 

Externally completed 

The intended action has occurred in the system that matters. The email was sent, the CRM was updated, the meeting was created, the support case reached the correct owner, or the handoff was received and acknowledged. 

This is the state that should count as completion. It can be verified without relying on the agent’s own explanation of what it thinks it did. 

Completed needs a precise meaning 

Externally completed is not one universal technical event. An email can be drafted, sent, delivered, or answered. An API request can be accepted, rejected, or accepted but later fail. A support handoff can be assigned, seen, or acknowledged by the person who must act. 

Teams should choose the fact that matters for the specific task and name it before building the workflow. For a low risk internal update, an accepted record change might be enough. For a customer promise, the right condition could be delivery, acknowledgement, or a response within a stated time. 

The completion condition must also define what happens when that fact cannot be verified. If an email bounces, an API call fails, or a person does not acknowledge the handoff by the deadline, the task is blocked, not complete. That distinction turns silence and failure into a visible queue instead of a confident but misleading status. 

Proof should live outside the model 

Language models are built to produce plausible language. That is useful, but it also means a fluent status update is weak evidence on its own. “I sent the follow up” is not proof. The proof belongs in the mail system, calendar, CRM, help desk, or other record that the business already trusts. 

Starting with the proof changes the way teams define agent work. Instead of telling an agent to handle lead follow up, define the condition first: a message is sent to the intended contact and the CRM records the activity. Instead of asking it to keep support moving, define the condition: the ticket is updated, the customer receives a response, or the right person receives an escalation. 

This makes the system easier to evaluate. The workflow either reached its stated condition or it did not. There is less room for a polished summary to hide a missing action. 

It also exposes weak task definitions early. If a team cannot say what external record will prove success, the task is probably too vague to hand to an agent. The problem is not the model. The problem is that nobody has defined the result. 

Approval is part of a trustworthy design 

The conversation around AI agents often treats human approval as temporary training wheels. That misses the point. Many decisions should remain with a person because they involve judgment that belongs to the business owner, not to a system following instructions. 

An agent can gather facts, prepare a recommendation, and make the next action easy. A person can then decide whether to send the message, make the promise, change the customer record, or commit budget. That is not half finished automation. It is a deliberate division of responsibility. 

The important part is clarity. The agent should never stop quietly at a draft and leave someone to discover it later. It should identify the decision, show the relevant context, and make the next action explicit. The reviewer should not have to reconstruct the workflow from a long conversation or wonder whether the agent already acted. 

When the boundary is visible, teams can safely give agents more freedom in low risk work while keeping closer control where the consequences are higher. Updating an internal task record may need no review. Sending a contract or responding to an angry customer should often wait for one. 

Start with one completion sentence 

Before an agent takes on any recurring responsibility, complete this sentence: 

This task is done only when __________ is true in __________. 

For a lead follow up, the answer might be: the message has been sent to the intended contact and the CRM shows the activity. 

For meeting preparation: the brief is available to the attendees before the meeting. 

For a support escalation: the right owner has received the issue and its urgency is visible in the help desk. 

For a weekly operating report: the decision maker can see current numbers and the unresolved exceptions. 

That second clause matters. The completion test should identify the system of record, the owner who resolves an exception, and the point when the workflow turns into an escalation. A workflow that cannot name what happens after a failed check is not autonomous. It is only optimistic. 

The sentence does two jobs. It gives the agent a target, and it gives the business a way to verify the result. If the task ends with an approval, the sentence can name that too. The goal is not maximum autonomy. The goal is useful work with a clear owner and a visible finish line. 

Measure changed reality 

The promise of business agents is not that they generate more text. It is that they help work move from intention to a completed result. 

That requires better measures than activity alone. Teams should look at how many tasks reached the correct external system, how long approvals took, where handoffs stalled, and which recurring tasks still became drafts that nobody finished. Those questions reveal whether an agent is reducing operational load or simply creating more material to review. 

The final test is practical. If the agent disappeared after producing its answer, would the business result still happen? If the answer is no, the task was prepared, not completed. 

Reliable agent systems make that difference visible. They show what has happened, what is waiting for a person, and what evidence proves that the work is done.