ADI BLOG
The ADI journal collects the deeper thinking behind the public site: how agents become identifiable, how trust is enforced, and where A2A, policy, and payment control meet in real systems.
ALL ARTICLES
The articles below are the migrated long-form pieces from the former Flutter public website, now placed into a proper blog structure.
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.
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.
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.
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.
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
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
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
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 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 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.
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.
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.
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?
