Your AI answered “done”. But was the task completed?

“Done” in the chat is not the same as completed in the operation

“Done” is a statement inside a dialogue. “Completed” is a verifiable result in the process or the target system, according to agreed criteria. The two can coincide, but one does not prove the other.

Why assistants and demos teach the wrong habit. In a personal assistant, the conversation is the product itself: if the text is good, the work is over. Agent demos often repeat this format and end on the success message. In an operation, the message is only the start of the check. A payment slip has to reach the right channel, a status has to come from the system that maintains it, and a record has to show the new value in the correct field.

A transcript is not an audit trail. The transcript records what was said. It shows the person's intent and the agent's account, but it does not show, on its own, whether the call reached the system, whether the permission applied to that action, or whether the final state matches what was expected. Transcript and evidence are useful together; the transcript alone does not prove completion. For this reason, a demo conversation should not be presented as production evidence.

A model gateway is not evidence of the action either. A model gateway can help manage access to and consumption of model calls. This does not, by itself, demonstrate that a record update was authorized or that the system applied the change. If the agent calls the record's API through another path, that is where the action controls need to be defined and integrated. Coverage must be verified in each deployment.

The request explains the intent, authority defines what that participant may do, execution records the attempt, and confirmation checks that attempt against the state that matters to the process. The transcript usually shows only the first link well.

The three pillars: owner, verification criteria, evidence

In the frequently asked questions on the Starya home page, the starting point fits in one sentence: choose a process, identify who is accountable for it, map the data and systems involved, and agree on what counts as a completed outcome. The three pillars below turn that sentence into something you can check.

Owner. The owner is a person, identified by name and role, who is accountable for the agent and the process in production. It is not “the AI” or “the team” in general. It is the person who accepts the scope, decides what changes when something fails, and receives what the agent cannot resolve. Without that name, an exception has no destination and an error has nobody to decide the next step.

Verification criteria. This is the prior definition of what counts as a completed result. Examples: payment slip sent to the registered channel; authorization request status returned by the lookup system; ticket updated with the correct reason. The criteria need to be written before execution, because afterwards the temptation is to accept anything that looks like success. They also remove ambiguity: “update the address” can mean changing the record, correcting an open order, or registering a request for review, and the criteria state which object changes and which fields may change. Without criteria, there is no way to audit.

Evidence. This is the record of the action, the lookup, or the state in the system or workflow, not what the model narrated. A fictional example: the request is to change the delivery address in record C-104. The agent replies “done”, but the person who will ship the order still sees the old address. Closing this task requires looking up the record in the responsible system and finding the new address in the delivery field. A useful record links the request reference, the chosen record, the result of the call, and the confirmation in the target system, and another person can interpret it without reading the whole conversation. There is also a choice about which data to record: a full address may be necessary in the system that carries out delivery, but not in every monitoring dashboard. Define with the team what information each role needs to consult and how to find the original record during an investigation.

An unknown result is a real state. If the integration sent the update and the response did not arrive, the team does not yet know whether the target received the call. In that case, record the task as pending, check the state in the target system, and do not repeat the action blindly. Repeating the same value in a field may seem harmless, but the same logic applied to sending a message, a charge, or creating an order can produce duplicate effects. In HTTP, repeating an idempotent request has the same intended effect on the server as executing it once, and RFC 9110 advises against automatically retrying a non-idempotent request without knowing that the operation can be repeated or that the first attempt was not applied. This does not guarantee identical responses or prove the business result. For the person being served, “the update was requested; we are still checking” describes this state more precisely than “done”.

Quick checklist: was this task completed?

Use the questions below before accepting a “done”. They are for checking one executed task, not for evaluating a vendor.

If the answer to any item is “I don't know”, the task is not yet completed. It is pending, and that also needs to be recorded.

When to hand over to a person (and why that is also completion)

A well-executed handoff is a legitimate result, not a failure of the agent. An agent that recognizes its limit and hands over the case with context correctly closes the part that belongs to it. Three situations call for a handover.

Out of scope. The request requires a decision reserved for the team, such as assessing an exception or deciding something clinical or contractual.

Insufficient data. Identification is missing, the record is incomplete, or the source did not respond.

Verification failure. The system rejected the action, the confirmation did not arrive, or the state found differs from what was expected.

In every case, the handover needs to carry the identity of the person being served, the original request, and what has already been tried, so nobody has to restart the conversation. Receiving the case and completing the request are different moments; the resolution also needs to be recorded. The guide How to hand a conversation over to the team organizes this context.

What this changes when choosing an agent for production

The evaluation question shifts from “does the agent answer well?” to “can I prove what it did?”. In an agent pilot or RFP, ask for three things before starting: the name of the process owner, the verification criteria for each type of task, and the way to look up evidence outside the transcript. Also ask what happens with an unknown result and where the handoff goes.

Improve one path before expanding coverage. Choose an action the team already knows and reconstruct a completed case and a case with uncertainty. Place the request, rule, attempt, and result side by side, and mark what was observed, what someone stated, and what still needs verification. The next improvement can be small and specific: displaying the field before approval, connecting records through the task reference, or creating a queue for pending confirmations.

These requests apply to any vendor and to agents built in-house. They do not replace the security and data assessment: access, information flows, and responsibilities are still designed for each deployment. The guide What a CISO asks before putting Applied AI into production explains how the audit trail links each attempt to the request and the confirmation.

How Starya approaches this in practice

Starya puts agents to work with clear ownership, verification criteria and evidence of what was done, in environments where mistakes have consequences, without this meaning that every “done” is verified automatically. What is checked, and in which system, is agreed for each process.

Start with a defined process. The team works in NebulaWorks, supported by NebulaOS and Starya engineering. Expand the scope as outcomes and integrations are verified.

Shared SaaS or Dedicated: two deployment options. Dedicated can use OCI, AWS or on-premises infrastructure, subject to technical assessment and the agreed scope. The purchasing channel is defined separately from the environment in which the operation runs.

Unimed Paraná and Unicall. Júlia operates in the Unimed Paraná IVR with Unicall. It identifies members, sends payment slips and checks healthcare authorization status, handing off to the team with context when needed. Checking authorization status does not mean deciding whether to approve a procedure. Requests outside the supported workflows go to the team, which receives the context and takes over.

dr.consulta. At dr.consulta, agents support customer engagement and appointment scheduling. Handling situations that require sensitivity and ongoing care stays with the team.

The published cases describe scope and handover. They do not detail the owner, verification criteria, evidence, or deployment option of each operation.

Related questions

What is the difference between a chatbot and an AI agent in business operations? A chatbot converses, while an agent in the operation looks up, issues, updates, or routes in systems, and therefore needs an owner, limits, and evidence. The question “What is the difference between a chatbot and an AI agent in operations?”, in the frequently asked questions on the home page, sums up this difference.

Who is the owner of an AI agent in production? It is a person, identified by name and role, who accepts the scope, receives the exceptions, and decides what changes when something fails. The guide “Who is the owner of an AI agent in production?” shows what this person decides, when they take over, and how to name them before the pilot.

Do companies actually know what their AI agents are doing? Reading the conversations is not the same as linking request, authorization, attempt, and confirmation. Start with one operation and list the links that are still missing, with the guide What to ask about AI already in use.

Questions to discuss with your team

• What state in the target system closes this task?
• Does the authorization identify the object and the change that will be executed?
• What do we do when the call may have worked but confirmation did not arrive?
• Who can reconstruct an attempt without relying on the agent's account?

Choose a process and define, before the pilot, who is accountable for it, which criteria indicate a completed result, and where the evidence will be checked.