Your next customer may be an agent. Can it tell whether you finished?

A customer asks an agent to cancel a subscription before renewal. The agent submits the request and receives a polite response: “We’ve received your cancellation request.”

Should it stop?

In this hypothetical example, the business has opened a support ticket. The subscription is still active. If the agent reports completion, the customer may discover the mistake only when the next charge arrives. If it keeps submitting requests, the business gets duplicate tickets.

The problem is familiar to anyone who has dealt with an unresolved support case. Delegating the interaction to an agent makes the ambiguity an input to software: should it wait, retry, escalate, or tell the customer the job is done?

A fluent reply is not enough information to make that choice.

AI agent customer service needs a defined outcome

Before designing an agent-facing interface, define the operation from the business’s perspective.

For a subscription, “cancel” might mean stopping the next renewal while retaining access until the paid period ends. It might mean immediate termination. A refund is a separate question. The agent needs to know which operation the business accepted and its effective date.

An address update has a different boundary. Updating the customer profile may leave an order already in fulfillment unchanged. A return request can be accepted while the refund remains conditional on receiving and inspecting the item.

Those distinctions already exist in business systems. Expose them accurately rather than asking an agent to infer them from a support message.

A useful response identifies the requested operation, the relevant object, its current status, and the next step. Completion should refer to a defined business state, not simply the end of a conversation.

Give the agent enough state to choose its next action

Here is one possible status model for a delegated request:

This is an application design recommendation, not a PEAC schema or a claim that every business uses these states. Some workflows need fewer states. Others need explicit expiry, cancellation, or review states.

The interface should also give the agent a stable request reference and a documented way to check status. Tell it when to check again and when further input is necessary. Repeated submission should not be the only way to ask what happened.

An agent can then distinguish waiting from failure. The business can reduce ambiguity without turning every interaction into another conversation.

A completion record should come from the responsible system

For the subscription example, the billing system is the relevant source for whether renewal was disabled. A support system can report that it opened a ticket. The customer’s agent can report that it received a reply. Those are useful observations, but they do not have the billing system’s perspective.

A completion record could preserve the subscription reference, the operation performed, the effective date, and the state the issuer reported. It should include only the customer information needed for the recipient’s review.

If a collector issues a signed record based on a billing export, identify the collector’s role. Its signature protects the statement it makes about that export. It does not turn an unsigned billing event into a billing-provider signature.

PEAC Protocol provides a format for portable signed interaction records. It can be used around these observations, subject to the workflow’s mapping and evidence rules. It does not create the request-status service, disable the subscription, or establish whether the business is entitled to charge the customer.

Those responsibilities remain with the application and its operating policies.

Preserve a history when the outcome changes

Suppose the business reports that renewal is disabled. Later, an administrator reactivates it.

The earlier record may still be a valid signed statement about what its issuer reported at that time. It should not be treated as a guarantee of the current state. The later change needs its own record and a clear relationship to the subscription and earlier operation.

Keep status observations distinct from promises about the future. A signed effective date does not ensure every downstream system will honor it. A customer may still need a later billing event or state check to assess a disputed charge.

Likewise, if an agent acknowledges a completion response, record what it acknowledged. Receiving the business’s statement is different from independently checking the business state. An acknowledgment should not silently mean satisfaction, giving up a claim, or acceptance of unrelated terms.

Precise records give both parties something useful to compare when the expected outcome and later state diverge.

Authentication still comes before execution

An incoming request needs appropriate authentication and authorization. A cancellation may require account access or a supported delegation mechanism. A machine-readable request is not inherently authorized, and a signed post-action record does not grant authority retroactively.

The business also needs controls for duplicate submissions, abusive request volume, conflicting instructions, and withdrawal of authority. Record design helps review those events. The service itself must enforce the rules.

For the agent, user approval is another scoped event. Permission to cancel one subscription should not become permission to close every account with the same merchant. Preserve the target and scope when the workflow requires them for review.

Start with one request whose outcome is already well defined

Subscription cancellation is a useful design exercise because the business can specify a concrete result: the responsible billing system reports renewal disabled for a particular subscription from a particular date.

Implement request tracking and status retrieval first. Then decide which observations need signed records because another party must review them later. Test whether a separate recipient can connect the request to the reported result and identify what remains unverified.

The metrics should reflect the workflow: how often the caller can distinguish acknowledgment from completion, how many duplicate submissions occur, and how much reconstruction a later escalation requires. Establish a baseline before claiming improvement.

This is a product hypothesis worth testing with businesses handling delegated requests. It is not evidence that every customer interaction needs a new protocol, or that every business needs another support platform.

Originary’s role is the record and verification handoff where those records are useful.

The business still serves the customer. The agent still acts within the customer’s authority. Both should be able to retain a precise account of the result they were given.

Further reading

• PEAC Protocol source and interaction record model
• Originary’s illustrative evidence case