Checkpoint: What Exactly Has the Agent Been Allowed to Do?

This checkpoint connects the lifecycle, identity, intent, and authority of an agent-mediated payment into one practical judgment. The question is not simply whether an agent was “authorized.” It is whether the proposed payment has a known principal and counterparty, a durable mandate with a bounded scope, and a separate way to establish that the service was completed. Those are related conditions, but they are not interchangeable.

The distinction is useful because a spending system can look secure when each component is examined alone. A registry can identify an endpoint. A policy engine can approve an amount. A wallet can reject transfers above a cap. A ledger can confirm settlement. Yet the system can still pay the wrong provider, permit a harmful sequence, or release money for an undelivered service. The integrated test is whether the same obligation retains its meaning as it moves from a goal to a concrete action.

One obligation, three different judgments

Start with a principal's goal. The request may be open-ended enough that an agent must find a service, compare alternatives, or coordinate several steps. The first judgment is referential: what real service or counterparty does the request concern? The second is authoritative: which principal, agent, mandate, and policy make a particular action permissible? The third is fulfillment-based: what evidence will show that the promised service occurred well enough for the financial obligation to be completed?

These judgments occur at different points, but they must refer to one another. A counterparty identity without a mandate does not say whether the principal approved the transaction. A mandate without a stable counterparty can authorize payment to the wrong service. Authority without an outcome condition can produce a settled transfer without a completed task.

flowchart LR G["Goal"] --> I["Counterparty identity"] I --> M["Intent and terms"] M --> A["Scoped authority"] A --> X["Execution permission"] X --> U["Outcome still unproven"] I -. wrong referent .-> W["Wrong service"] A -. valid but harmful sequence .-> H["Purpose exceeded"] U -. missing delivery .-> N["Payment dispute"]

The flow is not a promise that every system follows these exact boxes. It is a way to expose the handoffs. The goal must become a referent; the referent and terms must become a mandate; the mandate must become scoped authority; permission must lead to a controlled execution; and execution must still produce evidence before anyone treats the task as complete.

The three failure branches require different remedies.

Wrong counterparty: the referent failed

Suppose an agent is looking for a service with a particular capability. It selects an endpoint whose description, pricing, and request format appear correct, but the endpoint is counterfeit or institutionally inadmissible. The payment can still pass an amount check and settle to the recipient supplied by that endpoint. The problem is not primarily a wallet limit. It is that discovery bound the payment to the wrong economic object.