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

Start with the result that completes the work

Let us follow a fictional example. A sales team receives a request to change the delivery address in record C-104. The customer has an address for tax purposes and a delivery address. The expected result is to change only the second one, preserving the other fields. The purchase order already being picked is outside this change and needs separate handling.

This description matters before any technical discussion. “Update the address” can mean changing the record, correcting an open order, or registering a request for review. If people and systems use different meanings, a technically successful execution can produce the wrong result.

The first agreement is therefore operational: which object changes, which fields may change, and what evidence allows the task to be closed? In this example, closing requires looking up the record in the responsible system and finding the requested address in the correct field. Confirming the order being picked would be another task, with another owner.

Connect request, authority, execution, and confirmation

Reconstructing the path helps separate questions that usually appear mixed together in a conversation history. The request explains the intent. Authority defines what that participant may do. Execution records the attempt. Confirmation checks that attempt against the state that matters to the process.

These records need a recognizable connection. A task identifier, the record reference, and the sequence of attempts help the team reconstruct the path without having to guess which messages belong to the same operation. The design of this connection depends on the systems involved.

Permission needs to apply at the point of action

In the example, the rule may allow the agent to prepare a change but require a person's approval before saving it. That person needs to see the selected record, the current field, and the proposed value. Approving a vague intention does not provide the same context as approving a specific change.

After approval, the integration needs to execute what was authorized. If the record or the proposed address changes, the project must define when the approval ceases to be valid and needs to be given again. It is also necessary to plan how to suspend the operation and who may resume the work.

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.

Treat “I do not know whether it completed” as a real state

Imagine that the integration sent the update, but the response did not arrive. There are at least two possibilities: the target did not receive the call, or it received it and changed the record before the connection dropped. Asking the agent to try again without investigating does not distinguish these situations.

For a simple field replacement, repeating the same value may seem harmless. But the same logic applied to sending a message, making a charge, or creating an order can produce duplicate effects. The recovery procedure must consider the type of action and the protections the system provides.

In HTTP, idempotency means that repeating an identical request has the same intended effect on the server as executing it once. This does not guarantee identical responses or prove the business result. 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. In the integration, confirm this property before adopting retries as a recovery method.

Communication with the person should reflect this state. “The update has been requested; we are still checking the record” describes uncertain execution better than “done”. If confirmation depends on later processing, also agree on when to check again and when a person takes over.

Keep evidence that someone can interpret

A useful record answers a concrete investigation. In this scenario, what matters is the request reference, the selected record, the authorized fields, the person responsible for approval when applicable, the call result, and confirmation at the target. Adding the entire content of every conversation does not replace this organization.

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.

The absence of a record does not prove that the action failed. A success record likewise does not prove that the business objective was achieved. The team needs to understand the scope of each piece of evidence: receiving the call, saving the field, and actual delivery are different events.

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. 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. Define who will make the change and repeat the same path to check its effect.

Starting with your own agents or third-party agents is compatible with this work. The initial question is where they act and which points can be observed or controlled. The answer guides the integration scope; it should not be assumed from the presence of a product in the design.

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?

Before expanding autonomy, make one action verifiable from end to end. A map that admits “we do not know yet” helps the team choose the next control more precisely.