Protocol flows
Workflow tracking
Minting checks one action at a time. Workflow tracking is what gives each of those checks its context: as the agent works through a plan, the runtime keeps count of where it is, so the step and sequence it presents at mint are the real ones, not something the agent could assert after the fact.
The runtime keeps the state
As an agent executes, the runtime observes each tool call and maintains the current workflow state: which step is running, which steps have completed, and the delegation context so far. It does this by instrumenting the agent’s tools at startup, so the tracking rides along with execution rather than depending on the agent to report its own progress.
State becomes part of the mint
When a tool call turns into a resource call, the current workflow state and delegation context become part of the mint request. The Authority validates the step against the registered plan (prerequisites complete, gate passed, scope in bounds) before it issues a token. So the plan is enforced against the run’s actual position, tracked independently of anything the agent claims.
Note
step_sequence_hash, so a resource server can detect a skipped step on its own. The plan is carried on the wire, not only checked at the Authority.▶How the tracking is injected, and why it’s language-agnostic
At startup the runtime identifies each agent’s tools and wraps them, creating tracking wrappers around the tool functions so that invoking a tool updates workflow state as a side effect. The technique is generic: it’s wrapper functions in Python, the same idea via interceptors or aspects elsewhere, so nothing about the tracking is tied to one framework.
Tracking can be turned off, at the cost of losing the workflow-level guarantees. Leaving it optional keeps adoption incremental. There’s a real tradeoff: it adds a little in-memory bookkeeping per call, with no external round-trip, so the runtime overhead is small. draft-goswami-agentic-jwt §6