Keep the Keys Away from the Reasoning: The Two-Plane Model
The central design question for agentic commerce and finance is where an agent's permission ends and the power to move value begins. This chapter examines a two-plane architecture proposed for that boundary: a control and verification plane coordinates identity, mandates, policy, execution evidence, and audit, while a separate settlement plane handles keys, escrow, rail mechanics, and final transfers. The reader should be able to trace the interface between the two and judge both its protection and its remaining dependencies.
An autonomous agent is a poor place to concentrate every kind of authority. Its reasoning can adapt to prompts, model updates, tool results, and counterparty claims. It may be useful precisely because it can respond to incomplete information. The settlement system, by contrast, must decide whether a specific state transition is permitted and whether value has actually moved with the required finality. Giving the same component the power to interpret an open-ended goal and to sign an unrestricted payout turns any error in interpretation into a direct loss mechanism.
The two-plane model does not claim that one side is trustworthy and the other is not. It applies least privilege: each side should own the decisions and state it can enforce, while the interface between them exposes as little authority as possible.
What belongs in the control and verification plane
The control and verification plane is the coordination side of the system. In TessPay's proposal, it includes identity and authorization, orchestration, verification and audit, and the records that carry a payment through its lifecycle. Its job is to preserve the meaning of the obligation and decide whether the conditions for the next state have been met. It should not need direct access to a master key merely to coordinate a task.
The first responsibility is identity and authorization. The plane resolves an agent's identity and ownership, reads the relevant capability information, and checks the principal's intent before granting a scoped authorization. In the proposed design, an Agentic JWT, or A-JWT, represents authorization for a particular workflow step. The important architectural point is not the token's name. It is that the control side creates a bounded statement about who may do what, for whom, and within which context.
The second responsibility is orchestration. An agent-mediated task may require discovery, ranking, routing, delegation, and execution across several services. The control plane can assign the task, preserve the relationship between the user request and the assigned service, and emit lifecycle events. It can also collect telemetry about latency, tool use, errors, and cost. Those records matter later because a payment decision without an execution context is difficult to audit.
The third responsibility is verification and audit. The plane receives output metadata and execution artifacts, checks them against the requirements associated with the task, and records the result. In a proposed Verify-then-Pay flow, this side assembles evidence before it tells the settlement side that a payout condition may be satisfied. It can also preserve a tamper-evident account of the mandates, state transitions, and proof commitments.
The control plane should work with stable, abstract identifiers rather than assuming that every settlement occurs on the same chain.