Unclear identity
An AgentCard tells you how to reach an agent. It does not tell you which operator, business, or accountable party stands behind it.
FOR ARCHITECTS
Discovery alone is not enough. Agents need governance.
ADI separates communication, trust, and transaction behavior so that external agents can be discovered, governed, and allowed to transact without collapsing everything into one token story.
A2ATrustAP2
THE PROBLEM
A2A enables communication. It does not create trust on its own.
As soon as agents cross company, team, or wallet boundaries, you need operational answers for identity, delegation, revocation, and controlled payment behavior.
No delegation model
As soon as an agent acts for a person or company, you need machine-readable rights, scope, validity, and revocation.
No governance
Without blocklists, revocation, certificate status, and auditability, external agent interaction remains operationally weak.
Payments need more
Agent payments require roles, mandates, proofs, and transaction control points, not just a generic token.
TRUST QUESTIONS
What the trust layer must answer before an external agent may act.
These are the questions that remain unresolved if architecture stops at AgentCard plus OAuth.
Is this agent real or just an arbitrary endpoint?
Is it bound to an operator, user, or organization?
Which rights were delegated and for how long?
Have credentials, certificates, or policies been revoked?
Can I inspect, block, and audit its actions?
ADI STACK
Four layers for trustworthy agent systems.
ADI does not replace A2A. It layers identity, trust, policy, and transaction control above discovery.
01
A2A discovery and access
Agent cards, JSON-RPC methods, interfaces, and security declarations make the agent callable.
AgentCard and well-known discovery
Supported interfaces and security requirements
OIDC, OAuth, JWT, or other transport auth
02
Identity and operator binding
An agent must be linked to an operator, tenant, role context, or organization before it can be treated as a real actor.
User or organization linkage
Role and ownership context
Lifecycle status and activation control
03
Trust and governance controls
This is the layer that answers whether the agent may act, for whom it may act, and which proofs are still valid.
Policies, claims, and delegation scope
Verifiable proofs, certificate status, revocation
Blocklists, audit trails, and inspection surfaces
04
AP2 transaction behavior
Payment-capable agents need mandate handling, payment-specific roles, and transaction-grade control points.
Merchant, shopper, credentials-provider, or processor roles
Cart, intent, and payment mandates
Controlled payment flows and payment proofs
WHEN YOU NEED WHAT
Not every agent needs the same depth.
The correct architecture appears when A2A, trust, and AP2 are modeled as separate layers and only activated where the risk actually requires them.
A2A only
For internal or simple service agents that mainly need discovery, messaging, and basic authentication.
Internal assistants and workflow bots
Low-liability service interactions
No wallet, mandate, or payment behavior
A2A + trust
For external or governed agents where identity, delegation, and revocation matter.
Cross-company agent interactions
Delegation on behalf of people or organizations
Compliance, audit, or accountability requirements
A2A + trust + AP2
For commerce, wallet, and payment agents that exchange mandates, limits, or payment proofs.
Buying and selling agents
Virtual card, wallet, or mandate flows
Transaction-grade orchestration and payment controls
WHAT ARCHITECTS GET
Where ADI helps instead of just adding another abstraction.
The point is not to invent one more agent layer. The point is to operationalize identity, governance, and transaction control where agent systems get real.
Separate concerns cleanly
Keep communication, trust, and payment behavior as independent layers instead of overloading one token or one registry to do everything.
Govern external agents
Treat third-party or partner agents as governed actors with ownership, status, and policy context rather than opaque endpoints.
Control real transaction flows
Move from generic API invocation to governed payment and mandate flows with auditable control points.
Expose human and machine surfaces
Keep public explanation, machine-readable metadata, and operational integration surfaces aligned instead of split across unrelated systems.
LONG-FORM EXPLANATION
The detailed reasoning lives in the public knowledge layer.
The former Flutter public site carried deeper architecture explanations. They now belong in the blog, where architects can actually read them as articles.
OPEN AGENT TRUST Agent interoperability
How external agents verify an ADI merchant agent
A buyer agent does not have to live inside ADI to trust an ADI merchant agent. It needs public discovery, a resolvable agent identity, signed credentials, and a clear payment mandate path. This article shows how those pieces fit together.
A2A discovery makes the merchant agent reachable.
ADI trust discovery makes the merchant agent accountable.
MERCHANT TRUST Agent commerce
How the merchant trust catalog works
A merchant agent can sell from the merchant shop, but ADI needs an independent trust reference for what that agent is allowed to sell. The merchant catalog in ADI is that reference: a canonical product whitelist used to validate agent commerce before money moves.
The shop catalog runs the business.
The ADI catalog proves what the merchant approved.
AP2 VALIDATION Agent commerce
How ADI validates what a merchant agent sells
A merchant agent can describe an offer, but ADI should not pay from description alone. ADI validates the AP2 mandates, the merchant organization, the product SKU, the trusted catalog entry, the buyer wallet, and the virtual-card policy before the transaction becomes authorized.
Conversation creates intent.
AP2 creates structured mandates.
INTEGRATIONS Agent commerce
Why shop integrations are trust inputs, not the trust layer
Shopify, WooCommerce, CSV, custom APIs, and marketplace connectors help ADI import merchant product state. They are not the trust layer by themselves. The trust layer begins when ADI normalizes that product state, binds it to a merchant organization, and uses it in mandate and payment checks.
Integration is ingestion.
Catalog governance is trust.
INTEGRATION MODES Agent integration
Three ways to connect an external agent to the ADI trust layer
An external agent does not need to run inside ADI to be governed by ADI. The practical question is how the relying system authenticates that agent and when it asks ADI for trust, delegation, and certificate state.
Standard mode: API key or agent token plus online trust lookup
Enterprise mode: OIDC plus trust lookup
TRUST FOUNDATIONS Agent trust
Why agents need a trust layer
An API token only tells you whether a request is authenticated. A trust layer tells you which agent is acting, on whose behalf, which proofs are valid, and whether that agent can be stopped.
When OAuth stops being enough
Which questions a trust layer must answer
ARCHITECTURE System architecture
Separating A2A, trust, and AP2
The key architectural principle is separating the layers. A2A is communication. Trust is governance. AP2 is payment behavior.
What A2A actually standardizes
When trust is additionally required
PRODUCT ADI stack
How ADI works as an agent trust stack
ADI is not a single interface. It is an operational layer that connects discovery, identity, trust, and payment flows for agentic systems.
The platform’s four layers
Where A2A, MCP, and AP2 meet
A2A EXPLAINED A2A fundamentals
What A2A is and what it is not
A2A gives agents a shared way to describe themselves, exchange messages, and execute tasks. It does not automatically solve identity binding, delegated authority, auditability, or payment control.
A2A standardizes discovery, messages, tasks, and declared security capabilities.
A2A does not by itself answer who the agent represents or what it is permitted to do.
AP2 FOUNDATIONS AP2 payments
What AP2 solves for agent commerce
AP2 gives agent commerce a structured model for intent, cart, payment authorization, and receipts. Without that model, every agent-payment integration invents its own fragile semantics.
AP2 introduces a common vocabulary for agent payment flows.
Mandates separate scope, intent, and final payment authorization.
TRUST FOUNDATIONS Agent trust
What agent trust actually means
Agent trust is not a brand claim. It is the operational ability to prove who an agent is, on whose behalf it acts, what it is allowed to do, and how that authority can be revoked or audited.
Trust begins where authentication alone stops.
A real trust layer must support revocation, inspection, and evidence.
PRODUCT EXPLAINER ADI stack
What ADI does in an agent stack
ADI is the trust and control layer that sits between agent interoperability and real business action. It helps organizations let agents act without treating those agents like ungoverned black boxes.
ADI is where governance enters the agent stack.
The platform connects external agents, enterprise controls, and transaction policies.
SIGNATURES AND SEALS Trust services
Human signatures vs organization eSeals
A human signature proves the will or approval of a natural person. An organization eSeal proves that a trust object was issued or sealed by a legal entity. In enterprise agent systems, those are different jobs and they should not be collapsed into one.
Human signatures answer: who personally approved this?
Organization eSeals answer: which legal entity issued or stands behind this artifact?
A2A solves communication. ADI solves trust. AP2 solves transaction behavior.
Keep those layers distinct and the system stays understandable, governable, and much easier to extend without architectural drift.