The Next Internet May Need Verifiable State, Not Just APIs
Agent protocols can help software find one another and coordinate work. But they don’t necessarily give separate organizations a shared record of what was ordered, authorized, or paid for. A blockchain could provide that record. Whether it’s the right tool is still an open question.
- Systems can exchange messages while keeping separate records.
- Google’s A2A protocol supports agent discovery, communication, and task coordination, but it does not provide a shared business ledger.
- A public blockchain is one option for a shared record, not a proven requirement for agent-driven commerce.
Imagine a manufacturer with 1, 000 components. Company A’s agent checks availability and requests 500. Before that reservation is recorded across the systems involved, Company B’s agent checks and sees 1, 000 available. If the supplier accepts Company A’s order, then promises 700 to Company B based on that outdated figure, it has committed 1, 200 units when only 1, 000 are in stock.
This hypothetical illustrates a timing and coordination problem, not a flaw inherent to APIs. If Company A’s request is only a query, nothing has been committed. If the supplier accepts the request and reserves the stock atomically, its system can update availability before responding to Company B. The risk comes when separate systems act on records that are outdated or out of sync.
That kind of coordination problem already exists in ordinary software integration. Autonomous agents could increase the volume of requests and changes crossing organizational boundaries as they interact with suppliers, inventory systems, logistics providers, and payment services. The scale of any increase has not been measured here.
Agent communication is not shared business state
An API, or application programming interface, lets one system request information from another or ask it to perform an action. But the systems may still keep separate databases. One may record an order, another an inventory reservation, and a third a payment. Sending a message doesn’t ensure that every system records the same event in the same order.
Businesses can manage this with reservations, transaction coordinators, shared databases, event logs, or reconciliation processes. An API can also connect systems to a shared service. The point is simple: communication alone doesn’t determine which record governs when updates are delayed, duplicated, rejected, or received out of order.
Google’s Agent2Agent protocol, or A2A, is designed to help agents on different platforms find one another and work together. Google’s A2A documentation describes capability discovery through Agent Cards, messages and artifacts, task management, and status updates for work that may take time. It also describes support for authentication and authorization.
These are useful functions, but they don’t create a common record of inventory, ownership, or payment settlement across companies. A2A supports agent interaction and task coordination. Organizations still need to decide how their business systems record commitments and reconcile their records. Its security features also shouldn’t be mistaken for a universal identity or permission system. What an agent may do depends on the credentials, policies, and implementation around it.
The question goes beyond messaging. The IETF Internet-Draft AI Agent Internet Architecture discusses requirements such as discovery, identity, delegated authorization, trust, payment, privacy, and accountability across administrative domains. An Internet-Draft is a work in progress, not a finalized Internet standard, and its proposals may change.
The draft does not prescribe blockchain. It favors coordinating and extending existing Internet mechanisms, and proposes new ones where a demonstrated gap remains. It also treats identity, authorization, delegation, and audit as separate concerns. Verifying a credential, for example, does not automatically prove that an agent is authorized to spend a particular amount on a company’s behalf.
What a shared ledger could do, and what it could not
One proposed architecture would leave companies’ databases, APIs, interfaces, and private records in place, while adding a shared ledger for selected events. Participants might record an accepted reservation, a payment instruction, or a transfer claim, then refer to that common history when their local systems disagree.
A ledger can order and preserve transactions according to its rules. A digital signature can show that someone controlling a particular key authorized a transaction. But the signature alone doesn’t establish the real-world identity behind the key or the limits of that person’s authority. Those questions still require identity and authorization arrangements.
Recording an event doesn’t make its contents true. If an agent submits the wrong inventory count, a durable ledger may preserve the mistake. A timestamp can help establish when records were entered relative to one another, but it can’t prove the goods were actually on the shelf.
A hash can help verify that an off-chain document hasn’t changed, but it can’t locate or retrieve the document. That requires a separate pointer or lookup system. And a hash doesn’t guarantee privacy. Public metadata and links between records can reveal patterns, while information that is easy to guess may be vulnerable to comparison against a published hash.
“Settlement” also needs a precise definition. Recording a payment-related event doesn’t automatically complete a payment, deliver goods, or legally transfer ownership. Participants would need rules for failed transactions, reversals, disputed entries, and conflicts between the ledger and their operational records.
A public blockchain may be worth considering when independent parties need a shared record but don’t want one participant to control it. That advantage has to be weighed against governance, privacy, performance, cost, and integration requirements. A shared database, industry-run ledger, or conventional transaction coordinator may work better when participants already trust a common operator.
No specific blockchain, implementation, benchmark, or transaction-cost target has been established for this agent use case. Before claiming a ledger can handle the workload, designers would need to set out transaction rates, acceptable latency and cost, and how the system should behave during failures. Local systems would still have work to do: process events, handle errors, and keep their records aligned.
Key questions about agents and shared state
-
Why don’t APIs automatically create shared state?
APIs exchange requests and information, but the systems behind them may keep separate records. Shared databases, reservation systems, and other coordination tools can help. Messaging alone doesn’t establish which record is authoritative.
-
What does Google’s A2A protocol provide?
A2A supports agent discovery, communication, task management, and status updates, with support for authentication and authorization. Those functions don’t automatically create a shared record of business commitments across organizations.
-
Could a blockchain help?
Potentially, if independent participants need a common transaction history and accept the ledger’s rules. The available evidence doesn’t show that a public blockchain is necessary or proven to meet this use case’s performance, privacy, and cost requirements.
-
What can a ledger not guarantee?
It can’t make inaccurate inputs true, establish an agent’s authority by itself, or automatically resolve privacy, legal, and operational disputes. Those require additional systems and governance. Records management and information governance remain part of the challenge.
Agents will need more than ways to find and message one another. They’ll also need reliable ways to establish authority and record commitments. A shared ledger makes sense only if it solves a real coordination problem better than existing databases, logs, and transaction systems, without adding greater costs or new points of failure.
