Roadmap

Destination and capability policies

A future destination policy would let an owner restrict a Mandate to approved targets. That would give a Treasury or Payments sub-agent a clear destination boundary in addition to amount limits. A delegated Mandate should be able to narrow an inherited policy, while the policy must remain clear for approvals that are already pending when the list changes. The current TRANSFER action has no such allowlist and accepts any non-zero recipient.

The same policy needs to cover actions that create reusable downstream authority, such as token allowances or operator approvals. An authorised action should not create a capability that bypasses later Grantline evaluation unless the Mandate explicitly permits that capability. The action-specific rules and enforcement path for this are not defined yet.

Shared cumulative ancestor budgets

A shared cumulative budget would limit total usage across an authority chain. It would prevent a parent and its sub-agents from each spending up to a separate allowance and exceeding the amount the owner intended for the whole group. The budget could become a shared boundary alongside the current per-plan amount limits, with usage and pending approval capacity accounted for across the lineage.

Guardians

Preflight currently checks the projected native balance and native-USD balance left in a Vault. Guardians are a planned way to bring relevant context from outside the current contract state into the same authorisation decision.

A Guardian could answer a narrow question chosen by the owner, such as whether an asset is eligible, whether a market condition is within policy, whether a counterparty is acceptable, or whether an organisation's policy permits the action. It would add context to a decision; it would not choose an agent's strategy or replace the Vault's custody boundary.

The first proposed direction is an RWA Guardian for tokenised real-world assets. The product direction may later include other specialised condition modules, but no Guardian check or external condition provider is part of the current contracts.

SDK and API

The current integration surface uses the contract interfaces, external wallet tooling, and the cast guides. A future SDK could make the same flow easier to use by helping integrators construct Action Plans, sign them, submit them, read decisions, manage Escalations, and inspect execution evidence.

A future API could provide server-side coordination and presentation around those contract calls. The authority decision would remain in the deployed contracts, and signing authority would remain with the configured agent rather than with a hosted service.

When those tools are introduced, their package, authentication, and response design will be documented alongside the working service. This roadmap describes the jobs they should make easier, not an interface that exists today.

Indexing and Decision Receipts

The current contracts emit committed events from the registry, escalation manager, Vault, and executor, and expose scoped onchain indexes for Vaults, Mandates, and Escalations. Integrators can inspect those records and transaction receipts directly using Events and the inspecting evidence guide.

An offchain indexer could organise that evidence across deployments by Mandate, authority lineage, nonce, and action digest. A Decision Receipt could then present the proposal, authority, decision path, controller approval, transaction, and execution outcome in one human-readable view.

The future receipt is better understood as an evidence bundle than as a renamed activity log. It may connect the Action Plan and actionDigest with Mandate lineage, the effective rules used, Preflight results, Guardian evidence, controller approval, transaction status, and downstream failure details. A Mandate revision or effective-policy commitment may help make that explanation reproducible, but neither has a defined canonical construction today.

The distinction between an authorisation decision and an execution outcome must remain visible. An ALLOW result can lead to a reverted transaction, an approved Escalation can remain unexecuted, and a read-only DENY does not create a committed event. Contract-side indexes are current; cross-record offchain indexing and Decision Receipts remain deferred until the supporting service and data model exist.