We have been experimenting for some time with an architecture for secure AI agents, enterprise systems, messaging, identity, and controlled execution. This is an early, ongoing experiment, not a finished product — treat everything below, including the parts we've prototyped, accordingly. While working on it, we arrived at a thesis worth putting in front of people who think about integration and agent security for a living:
APIs don't disappear. The enterprise boundary moves upward — from predefined technical interfaces toward negotiated, policy-constrained interaction contracts — with APIs and tools remaining the deterministic execution substrate underneath.
The goal isn't to replace APIs with LLMs. It's to reduce how much cross-enterprise integration logic must be agreed in advance, replacing some of it with governed runtime negotiation where that's safe. We currently call the software actor that carries out this negotiation on an enterprise's behalf a B2B agent.
The current model
Today, enterprise integration usually looks like this: Company A writes an integration against Company B's API, which talks to Company B's business systems. Simple in shape, expensive in practice — Company B has to define REST endpoints, schemas, authentication, scopes, versioning, error models, webhooks, and SDKs, and Company A has to understand all of it before a single request can succeed.
This works. But it also creates an enormous amount of integration work. Every company exposes slightly different models. Every pair of systems requires mapping. And even when two companies use the same protocol, they rarely use the same business semantics.
Agents change something important — but not the part people assume
Agents are different from traditional applications because they can reason about intent. Instead of saying:
POST /api/v3/orders
an agent can say:
I want to order 500 units of product X, delivered in the EU before Friday. The maximum total price is €20,000.
It's tempting to conclude that agents therefore replace APIs. We don't think that's quite right, and we don't think it's even the interesting claim. The API layer — createOrder, reserveInventory, approvePayment, cancelShipment — still needs to exist somewhere, deterministic and auditable, because that's what actually moves goods and money.
What agents can plausibly remove is a precondition: today, Company A has to understand Company B's native interface before anything can happen. If agents can negotiate a shared, machine-readable description of the relationship at runtime, that precondition gets weaker. The API doesn't disappear — it moves one layer down, behind a negotiation and authorization layer:
A possible future interaction
Imagine Company A's agent discovering Company B's B2B agent and saying:
I need access to quoting, ordering, order status, and cancellation.
Company B's agent answers:
I support those capabilities. Orders may be cancelled until dispatch. Transactions above €10,000 require additional authorization. I only support EUR settlement for this relationship.
The two agents don't necessarily need identical native APIs. Instead, they negotiate an Interaction Contract — a machine-readable definition of the relationship. A minimal illustration:
purpose:
supplier_order_management
capabilities:
- quote
- create_order
- order_status
- cancel_order
constraints:
max_order_value:
currency: EUR
amount: 10000
geography:
- EU
cancellation:
allowed_until: dispatch
validity:
expires_in: 30_days
A skeptical reader might reasonably ask: isn't this just OAuth scopes plus a JSON Schema plus a policy engine? Fair question. What we think makes an Interaction Contract a distinct artifact, rather than a fancy permission set, is that it's meant to bind several dimensions together at once — counterparties and identity requirements, permitted business purposes, capabilities, agreed semantics, constraints, data policy, required workflow ordering, delegation rights, obligations (SLAs, confirmations), validity, revocation, and attestation — as one versioned, signed, hashable object. That's closer to a machine-enforceable operational relationship than a scope list.
One clarification worth stating plainly: "Interaction Contract" here means a machine-enforceable technical agreement between two software actors, not a legally binding commercial contract — although the two concepts may eventually need to intersect, particularly once commercial terms are involved.
We're also not fully settled on whether an Interaction Contract is best modeled as one object or as an envelope over several independently versioned artifacts — identity assertions, capability agreement, semantic mapping, policy constraints, delegation constraints, obligations, and attestations. The semantic mapping, for instance, may need to change on its own timeline while the rest of the relationship stays fixed. We don't think this needs to be resolved for the argument to hold, but it's likely to matter once this moves past a prototype.
Where this sits relative to MCP and A2A
Anyone following this space will reasonably ask whether this is just reinventing A2A. It isn't, and we want to be explicit about why, because we'd rather be complementary to existing protocols than start a standards fight we don't need:
- At its core, MCP standardizes agent/tool and resource interaction.
- A2A provides agent ↔ agent interoperability — discovery, capabilities, task exchange between agents.
- Interaction Contract governs the enterprise ↔ enterprise relationship those agents are allowed to establish — the negotiated scope, constraints, and semantics.
- Trust Gateway is the policy decision and execution-authorization layer sitting behind each side.
- ExecutionGrant is the per-operation authority actually handed to an executor.
Put differently: assume A2A solves communication and interoperability between agents. Our question is what governs the relationship the two agents are allowed to establish, and what stops either side from acting outside it.
There are adjacent standards and ideas here that solve important parts of this problem already. OAuth Rich Authorization Requests (RAR) provides a way to express fine-grained, transaction-specific authorization rather than relying only on coarse scopes. AuthZEN standardizes interaction between policy enforcement and policy decision points. MCP addresses tool and resource interoperability, while A2A addresses interoperability between agents.
We're not proposing replacements for those. The hypothesis is about the layer that composes identity, negotiated business semantics, relationship constraints, delegation, and operation-level authorization into a governed cross-enterprise interaction. In that model, existing standards can provide much of the machinery underneath rather than being displaced by it.
Agents propose. Gateway decides. Executors verify.
This is the load-bearing sentence in the whole design, and probably more important than the "B2B agent" framing itself. We don't think two LLMs should negotiate something and then simply execute it — that would be far too dangerous. The architecture deliberately separates reasoning, authority, and execution into different actors:
The agent doesn't hold final execution authority. A separate Trust Gateway control plane evaluates policy and issues short-lived cryptographic execution grants; an executor performs the actual side effect only after verifying that grant.
Here's a property we think deserves a name of its own. Between "what was authorized" and "what actually executes," there's a window where the two can diverge — an authorized transfer(account=A, amount=100) becoming an executed transfer(account=B, amount=10000). It's structurally the same shape as a classic TOCTOU (time-of-check-to-time-of-use) bug, just at the agent-action layer instead of the filesystem layer. In our prototype, execution grants are short-lived and single-purpose, and execution authorization is cryptographically bound to the specific tool and the exact canonical arguments via an input_hash, so a grant is only valid for the precise action it was issued for — not "an action like this one." (Preventing reuse of the same grant across distributed executors is part of the design goal; we're not yet claiming that guarantee is airtight in every deployment topology.) That's one of the security properties we consider important enough not to bury in a longer capability list — alongside delegation, revocation, and distributed policy state, which matter just as much and which we haven't fully covered here.
So the model isn't "agent executes anything." It's: agent proposes intent → Interaction Contract constrains the relationship → Trust Gateway applies deterministic policy → a cryptographically bound ExecutionGrant → executor.
Agents negotiate meaning, not authority
In our hypothesis, the agent negotiates business intent, compatible capabilities, schema mappings, data requirements, transaction constraints, workflow expectations, and delivery semantics. It should never decide whether an enterprise action is authorized — that stays deterministic. More precisely: agents may negotiate the shape of a proposed permission envelope, but they cannot confer authority that the enterprise hasn't independently delegated.
Two agents might negotiate a maximum transaction of €50,000, but if enterprise policy caps it at €10,000, €10,000 should win:
effective authority =
negotiated contract
∩ enterprise policy
∩ identity authority
∩ delegated authority
A negotiated agreement can only make the permitted space smaller. It should never be able to create new authority — though as we note below, even this formula isn't the whole story once multiple contracts combine.
What we've prototyped so far
This isn't purely theoretical, but it's still early, and only a slice of it is public: a portion of the underlying execution-control-plane concepts is open source; most of the current build is private and iterating quickly. Treat the open-source repository as the visible tip of an experiment still taking shape, not the full system.
Concretely, we've implemented the negotiation lifecycle (discover, propose, counter-propose, accept, attest) as working code, and the authorization path: the Trust Gateway verifies canonical terms hashes, counterparty identity, monetary limits, and geographic constraints, and stamps a contract_id and contract_hash into every execution grant issued under that agreement. That gives a provenance chain from what did these two agents agree to what exact operation actually happened — identity, contract, policy, and input hash all feed into the grant, which feeds into the execution result. This is the target behavior we're validating, not a claim that it's proven at production scale.
The harder problem may be semantic, not cryptographic
OAuth, PKI, signing, and grant verification at least give us mature primitives to work with — that doesn't mean enterprise deployment (key custody, federation, revocation, lifecycle) is easy, just that the building blocks exist. The harder unresolved problem in this architecture is closer to: what does cancel_order mean to Company A versus Company B? "Cancel" for A might mean void the PO outright if unshipped; for B it might mean file a cancellation request subject to supplier approval. Two agents can linguistically convince each other those concepts match without them actually matching — a kind of semantic false agreement that's more dangerous than an outright rejection, because it fails silently.
We suspect the safer pattern is not "the LLM invents a mapping and we trust it," but something closer to: agent proposes a mapping → the mapping is captured as a deterministic, versioned artifact → schema and policy validation → optional human or certification approval → the mapping is hashed and versioned → future executions reference the approved mapping, not a fresh inference. In other words, use AI to generate interoperability artifacts, not to be the interoperability artifact.
Why this could change integration
We've spent enormous effort standardizing application interfaces — REST, OpenAPI, OAuth, and now MCP and A2A. Our hypothesis is that the long-term abstraction sits one layer higher: instead of requiring every company to expose the same business API, we standardize the protocol for discovering capabilities and negotiating interactions, while the API layer keeps doing the deterministic work underneath. We'd still need standards — arguably more than ever, for identity, capability discovery, authorization, delegation, revocation, and audit — just not the same application-level interface from every company.
A brief note on interfaces beyond APIs
The same model may eventually extend to human-facing commerce, where a user's agent negotiates directly with a merchant's agent under delegated authority. That's a separate topic, though, and probably deserves its own article.
There are still many hard questions
This is a work in progress, and the open questions probably outnumber the answers so far:
How much should agents really negotiate? Free-form negotiation is tempting but probably a mistake; negotiation likely needs to happen inside well-defined capability and policy boundaries, not from a blank slate.
Composition and cumulative authority. Authorization can't always be evaluated one action at a time. Individually safe grants can become unsafe together — read access to a catalog, permission to submit a purchasing recommendation, and permission to send an external message might each be fine alone and risky combined. Evaluating contract ∩ policy ∩ identity ∩ delegation may also require transaction history, cumulative spend, velocity limits, and separation of duties — which likely means the Trust Gateway needs stateful authorization, not a static per-request check.
Transaction and failure semantics. Negotiating intent is only part of the problem. An order gets created, inventory reservation fails, payment authorization already succeeded, and the network response never arrives — now what? Cross-enterprise actions still need deterministic treatment of retries, idempotency, partial failure, compensation, reconciliation, and disputed outcomes. Agents don't make any of that go away.
Discovery trust. How does Company A know it discovered the real Company B agent, and not an impersonation? Discovery is only useful if the counterparty's endpoint, organization, capabilities, and credentials can be authenticated and kept current — which points back to identity infrastructure, not just negotiation logic.
How should contracts be signed? DID-based signatures are one option, traditional enterprise PKI another — in many environments, both may need to coexist.
How does human approval fit? Some contracts could be automatic. Others should require approval when a new counterparty is involved, financial limits are high, new data categories are exposed, new jurisdictions are involved, or sensitive capabilities are requested.
Where does payment fit? Once an Interaction Contract includes commercial terms and not just capabilities and permissions, it starts looking like a machine-readable commercial agreement — which is exactly why we're careful to distinguish it from a legal contract above.
Why we think this is worth exploring
We don't know whether this exact architecture will become the future of enterprise integration. But we increasingly believe something structurally similar will emerge. Agents are becoming first-class software actors with identities, delegated authority, and increasingly consequential permissions. They are beginning to discover other agents and capabilities, and are likely to initiate increasingly consequential transactions. Once that happens, enterprises will need a controlled interface between the probabilistic agent world and deterministic business systems.
Agents negotiate. Contracts capture agreement. Gateways authorize. Executors execute.
That's the direction we're experimenting with.
We'd like your feedback
We'd be especially interested in hearing from people working on MCP, A2A, agent identity, API gateways, authorization, payments, B2B integration, autonomous commerce, or zero-trust agent architectures. Three questions we're genuinely unsure about:
- The negotiation boundary: which parts of a B2B integration could safely be negotiated at runtime, and which must stay predefined?
- The trust boundary: is "agents propose, gateways authorize, executors verify" the right separation of responsibilities — or does it introduce a layer you wouldn't actually want?
- The semantic boundary: can business semantics ever be safely negotiated dynamically, or will enterprises always need certified canonical models for anything consequential?
Comments here are the easiest way to reach us. If you spend five minutes poking holes in this, we'll read every one of them.
Top comments (0)