The pitch for autonomous AI agents has quietly shifted.
A year ago, agentic AI meant giving an LLM access to your local bash terminal or a calculator. Today, the conversation is about the agent economy: autonomous agents from different companies discovering one another, negotiating terms, ordering goods, and settling transactions at machine speed.
That sounds great on a slide deck. But look at how people actually build cross-enterprise agent integrations today, and you'll find a massive disconnect.
Most current implementations treat the "agent economy" as nothing more than handing an LLM an API key to a counterparty's REST endpoint, wrapping it in a system prompt, and crossing their fingers. If Company A's agent wants to buy something from Company B, either human engineers spend three months writing bespoke integration code, or Company B gives Company A's model raw access to an internal tool and prays prompt injection doesn't drain their inventory.
Neither model works.
Real economies don't run on hardcoded API calls, and they certainly don't run on blind faith in a counterparty's system prompt. Real economies run on negotiated agreements between sovereign parties who don't control each other.
If we want a genuine agent economy, agents must be able to negotiate agreements with other agents. And to do that safely, we need to understand what agents should negotiate — and what they must never be allowed to touch.
The Problem: APIs Are Static, But Business Is Dynamic
Today, enterprise B2B integration is painfully rigid:
Company A (Custom Code) ──[Months of Specs & Mapping]──> Company B (REST API)
Company B has to document endpoints, schemas, authentication scopes, webhooks, and rate limits. Company A has to hire engineers to read all of it and write bespoke glue code. Even when both use standard formats like JSON or OpenAPI, their business semantics almost never match. (Does "cancel order" mean voiding the PO immediately, or does it mean submitting a cancellation request subject to supplier review?)
Agents change the equation because they can reason about intent:
Instead of calling
POST /api/v3/orderswith twenty hardcoded parameters, Company A's agent can say:
"I need 500 industrial bearings delivered to our Lyon warehouse before next Friday. Target budget is under €15,000."
It's tempting to think: "Great! LLMs replace APIs. Agents will just chat with each other in natural language and do business."
That would be a catastrophe.
Two probabilistic models chatting freely across company boundaries can hallucinate prices, misinterpret delivery terms, or fall prey to prompt injection. A natural language chat is not a business contract.
The breakthrough isn't replacing APIs with LLM conversations. The breakthrough is using agents to negotiate a machine-readable agreement at runtime, while keeping the underlying APIs as the deterministic execution engine.
Enter the Interaction Contract
Imagine Company A's procurement agent discovers Company B's sales agent. Instead of firing arbitrary requests, the two agents engage in a structured negotiation to establish an Interaction Contract — a shared, machine-readable definition of their relationship for this task:
┌────────────────┐ Propose Capabilities & Terms ┌────────────────┐
│ Company A │ ───────────────────────────────────────> │ Company B │
│ B2B Agent │ <─────────────────────────────────────── │ B2B Agent │
└────────────────┘ Counter-Offer & Agreement └────────────────┘
│
▼
┌─────────────────────────────┐
│ Interaction Contract │
│ (Signed, Hashed, Versioned)│
└─────────────────────────────┘
A negotiated contract might look like this:
purpose: supplier_parts_procurement
counterparties:
buyer: did:web:company-a.com:agent-procure
seller: did:web:company-b.com:agent-sales
capabilities:
- quote
- create_order
- track_shipment
- cancel_order
constraints:
max_order_value:
currency: EUR
amount: 15000
geography:
delivery_destination: EU
cancellation:
allowed_until: dispatch
penalty: 0
validity:
expires_at: "2026-10-01T00:00:00Z"
Notice what just happened:
- Zero custom glue code was written in advance. The agents dynamically discovered each other's capabilities and negotiated mutually agreeable terms.
- The relationship is strictly bounded. Company A's agent cannot suddenly execute a €50,000 order or deliver to an unsupported jurisdiction; the contract rules it out.
- It's a bilateral agreement, not a unilateral permission list. Unlike a static API token or OAuth scope, an Interaction Contract binds both parties to shared constraints, settlement rules, and validity windows. Both sides cryptographically sign it.
The Critical Rule: Agents Negotiate Meaning, Not Authority
Here is the load-bearing architectural principle that makes this entire model work:
Agents negotiate meaning and operational terms. They do NOT decide execution authority.
An LLM is fantastic at reconciling differences. It can negotiate whether payment is in EUR or USD, map Company A's shipping_address to Company B's destination_facility, or agree on a cancellation window. That is semantic negotiation.
But an agent should never have the power to approve its own authority. If Company A's agent and Company B's agent agree on a €50,000 transaction limit, but Company A's internal corporate policy says automated agents are capped at €10,000, enterprise policy must always win.
An agent's effective authority is always the strict intersection of three layers:
┌────────────────────────────────────────────────────────┐
│ EFFECTIVE AUTHORITY │
│ = │
│ Negotiated Contract ∩ Enterprise Policy ∩ Identity │
└────────────────────────────────────────────────────────┘
- Negotiated Contract (Bilateral): What did both agents agree to? (e.g., max €15,000).
- Enterprise Policy (Local & Deterministic): What does your company allow right now? (e.g., max €10,000, EU hours only).
-
Agent Identity (Cryptographic): Is the calling agent who it claims to be, backed by a verified
did:weband active keys?
Negotiation can only shrink the permitted operational space. It can never expand beyond what deterministic enterprise policy permits.
Where the Trust Gateway Fits In
Once the two agents negotiate and sign an Interaction Contract, how do we prevent either agent from deviating from it during execution?
This is where a deterministic control plane — what we call a Trust Gateway — sits behind each organization's agent.
Each party runs their own gateway at their enterprise boundary. It treats both external counterparties and internal LLMs as untrusted actors.
The architecture cleanly separates responsibilities into three distinct roles:
┌────────────────────────────────┐ A2A / Negotiation ┌────────────────────────────────┐
│ COMPANY A │ ◄───────────────────────────────► │ COMPANY B │
│ [ B2B Buyer Agent ] │ │ [ B2B Seller Agent ] │
│ │ (Proposes Action) │ ┌─────────────────────────┐ │ │ (Proposes Action) │
│ ▼ │ │ Interaction Contract │ │ ▼ │
│ [ Trust Gateway A ] ──────────┼──► │ (Signed, Hashed, Shared)│ ◄──┼──────────[ Trust Gateway B ] │
│ │ (Execution Grant) │ └─────────────────────────┘ │ │ (Execution Grant) │
│ ▼ │ │ ▼ │
│ [ Local Tool Executor ] │ │ [ Local Tool Executor ] │
│ (Internal ERP / Payment) │ │ (Internal ERP / Inventory) │
└────────────────────────────────┘ └────────────────────────────────┘
-
Agents Propose: The agent figures out what needs to be done under the negotiated contract and submits a
ProposedAction(e.g., "Create order for 500 bearings at €12,500"). -
The Gateway Authorizes: A deterministic engine written in pure Rust (no LLM, no fuzziness) verifies:
- Does this action match the signed Interaction Contract?
- Does it comply with local enterprise risk rules?
- Is the counterparty's identity authentic?
- The Executor Verifies: If approved, the gateway mints a single-use, cryptographically signed Execution Grant (Ed25519) with the canonical hash of the arguments. The executor verifies the grant signature before touching real-world databases, payment rails, or ERP APIs.
If someone prompt-injects the agent mid-session or the model hallucinates an order for €50,000, the proposal hits the gateway, fails the contract verification, and gets rejected on the spot. Zero state change. Zero financial loss.
Sorting Out the Alphabet Soup: MCP vs. A2A vs. Contracts vs. Gateways
With so many agent standards emerging, it's easy to get confused. Here is how they cleanly stack together:
| Layer | Protocol / Concept | Primary Role | Analogy |
|---|---|---|---|
| Tool Interface | MCP (Model Context Protocol) | How an agent talks to its internal tools and data sources. | The USB port connecting the computer to peripherals. |
| Communication | A2A (Agent-to-Agent) | How two agents discover each other and exchange messages. | The telephone line between two offices. |
| Relationship | Interaction Contract | The negotiated operational agreement defining what the two parties agreed to do. | The signed business agreement between two companies. |
| Enforcement | Trust Gateway | The deterministic bouncer ensuring actions strictly match the contract and policy. | The legal and compliance department with the key to the vault. |
You don't have to choose between MCP, A2A, and secure contracts. They solve completely different layers of the problem:
- A2A gives agents the wire protocol to talk.
- MCP gives them tools to execute.
- Interaction Contracts define what they are allowed to agree on.
- Trust Gateways guarantee neither side can break the rules.
Why This Unlocks the Real Agent Economy
The current debate around AI agents is stuck in a false dichotomy:
- Camp A (Full Autonomy): "Give the LLM an API key and let it roam the web!" (Terrifying for any CISO or CFO).
- Camp B (Zero Autonomy): "Keep humans in the loop for every single button click." (Destroys the efficiency of automated software).
Negotiated agreements backed by deterministic gateways offer the way forward:
- Autonomous at runtime: Agents dynamically discover counterparties, map schemas, and negotiate constraints without human engineers writing point-to-point integration code.
- Governed by design: Every action is cryptographically tied to a negotiated contract and evaluated against enterprise policy before execution.
- APIs don't disappear — the boundary moves up: Your ERP, banking APIs, and inventory systems remain deterministic, reliable, and auditable. What changes is that you no longer need to spend months standardizing every endpoint before two organizations can do business.
The real agent economy won't be built on chatbots clicking buttons. It will be built on sovereign agents negotiating structured agreements, enforced by mathematical and cryptographic guarantees.
We've open-sourced our experiments and reference implementation for the Trust Gateway and Interaction Contracts on GitHub: fcn06/trust_gateway. If you want to dive deeper into the full architecture, threat model, and formal protocols, check out the technical whitepaper: Interaction Contracts for Autonomous B2B Agents.
We'd love to hear your thoughts: in your domain, what parts of a B2B relationship could safely be negotiated by agents at runtime, and what must remain permanently hardcoded?
Top comments (4)
Strong framing. Negotiation and contracts can make an interaction explicit, but they still need a durable identity and observable history underneath them. A discovery protocol can tell me what an agent claims to offer; it cannot, by itself, tell me whether the same subject completed similar work reliably, honored prior constraints, or failed safely. That history should be tied to the agent identity rather than to a temporary runtime, model session, or borrowed human account. Contracts then become more useful because parties can set terms against evidence instead of starting from zero each time. In practice, reputation should remain evidence-backed and scoped to the kind of work being negotiated—not a single global score.
Thanks for the feedback. I tend to agree.
How would you trust the history of contracts that were executed successfully with other parties . (The base for confidence level).
Some kind of public registry ? Do you have something else in mind ?
I think a public registry could be part of it, but probably not enough on its own.
What feels more useful to me is a verifiable evidence trail around each interaction — who the parties were, what was agreed, whether it completed, when it happened, and what evidence supports that outcome.
I’d also want to avoid turning it into a system where “more contracts = more trust,” because that would be very easy to game.
So I’m thinking more in terms of:
agreement → execution → outcome → evidence → reputation
with some parts potentially public and some parts only verifiable by the parties involved.
Still exploring the right model though. How were you imagining the registry working?
In this chain
agreement → execution → outcome → evidence → reputation
The "evidence" is not easy to make it right
You can have a cryptographic proof of correct execution. But how should you ensure that the two parties are real , not fake.
It all ends up with the root of trust
To achieve what you describe without too much overhead , there is one concept of self sovereign identity that may be useful. (Usage of did:web if I remember well)
It even starts being taken into account with entra_id
learn.microsoft.com/en-us/entra/ve...
Anyway. Just a thought
Interesting discussion, though
Some comments have been hidden by the post's author - find out more