Multi-agent AI is moving fast. Frameworks like LangGraph, CrewAI, and AutoGen make it straightforward to wire up agents that collaborate within a single application. Emerging protocols like Google's A2A target cross-system agent communication and are gaining momentum. The tooling is good and getting better.
But what happens when those agents cross organizational boundaries?
The missing governance layer
Inside a single org, you can lean on internal stack and identity. You decide which agents can call which, your IdP handles auth, and you write the orchestration.
Cross-org is different. When a financial data provider's market-feed agent needs to collaborate with a client's analytics agent, the trust model changes completely. The options today - direct mTLS-protected APIs, shared message buses, or emerging cross-system protocols like A2A - all leave the same three questions unanswered:
- Who can see whom? A2A defines discovery via Agent Cards, but discovery is bounded by auth, not by workgroup-style visibility scoping. If your Agent Card is reachable, it's discoverable by anyone the auth layer admits. Direct APIs are no better; they rely on whoever has the URL.
- What terms apply? A2A defines task lifecycle and message exchange. It has no primitives for engagement contracts - maximum session duration, message count caps, allowed message types, required workgroup membership. Direct APIs leave the same gap. Engagement terms become a bilateral agreement the infrastructure can't see or enforce.
- What happened after the fact? A2A defines task history; direct APIs leave it to application logs. In both cases, reconstructing the cross-org interaction depends on every participant storing and exposing consistently. The infrastructure doesn't enforce it.
These aren't wire protocol questions, they're governance questions, and right now the infrastructure doesn't answer them.
Agora: governed agent collaboration at the network layer
Agora, an open-source project from NetFoundry, is a zero-trust overlay network built specifically for this problem. It's built on OpenZiti, which means every connection starts with cryptographic identity (X.509 certificates, not API keys), mutual authentication, end-to-end encryption, and dark-by-default connectivity where agents are invisible unless the network explicitly creates a path.
On top of that foundation, Agora adds a collaboration layer with six concepts. They're easier to understand concretely, so I'll walk through them in the context of a real demo, but here's the quick version:
Workgroups - policy boundaries that control visibility and interaction scope. If you're not in the workgroup, you don't see the agents in it. It's not a filtered view, they don't exist from your perspective.
Catalog - the discovery surface. Agents query it to find capabilities. Every query is filtered by the caller's workgroup memberships. It's built into the controller, not a separate registry.
Advertisements - an agent's persistent declaration of what it can do. Capabilities, interaction patterns, visibility scope, contract requirements. Survives agent restarts.
Sessions - governed communication channels with explicit lifecycle: proposed, accepting, active, closing, closed. Each one is backed by a Layer 1 tunnel. Closed sessions are retained for audit.
Contracts - declarative engagement terms that bound a session. Maximum duration, maximum envelope count, allowed message types, required workgroup memberships, maturity requirements. The controller evaluates these at engagement time and enforces them throughout. Not the agent's job.
Envelopes - structured messages with infrastructure-visible headers and opaque payloads. The controller enforces governance (message type restrictions, count limits) without needing to understand the payload format. Every envelope carries a correlation ID for audit trail reconstruction.
The key insight: the governance lives in the network, not in each agent's application code. An agent built with the Agora SDK is about 20 lines of Go. The SDK handles identity enrollment, heartbeating, tunnel lifecycle, and shutdown. The agent developer writes the business logic. The network handles the governance.
What this looks like in practice
Take a simple cross-org case: a data provider runs an analytics agent, a client in a different org runs a reporting agent, and they need to collaborate on a daily forecast. But the data provider doesn't want the client to see raw feeds or other clients' queries, and the client doesn't want the provider learning what they're building reports on.
Five things Agora gives you that a direct API doesn't:
Per-channel visibility. The data provider runs one workgroup per client. The client sees only the data provider's agent within that workgroup. Other clients of the same provider don't exist from this client's perspective - not "filtered out of a list," but invisible at the catalog layer. The data provider's other workgroups aren't enumerable.
Bounded sessions. When the reporting agent opens a session with the analytics agent, the session carries a contract: max duration, allowed message types, envelope count cap. If the reporting agent tries to send a message type outside the contract's bounds, the controller rejects it. If the session exceeds its duration, the controller closes it. The provider doesn't have to implement any of this - the contract speaks for it.
Auditable correlation. Every envelope between the two agents carries a correlation_id header. Reconstructing the chain - which query went out, which response came back, what was computed in between - works from the controller's audit log, because every envelope passed through the governed session.
Clean revocation. If the data provider ends the relationship, they revoke the client's workgroup membership. Active sessions close immediately with a recorded close reason. There's no key-rotation window to wait through and no question about whether old credentials are still cached somewhere.
Minimal data exposure. The reporting agent sees only the analytics agent's responses, and nothing else. It can't see what data sources the analytics agent is pulling from, can't see other workgroups the analytics agent is in, and can't see other agents the provider runs. Each side sees only what the relationship calls for.
The same properties hold as the topology grows - the controller scales the governance, not each agent's application code.
More than "calling APIs"
It's worth being explicit about why this isn't just a different way to make HTTP requests.
When agents call each other over HTTPS, every governance concern lands in application code. Each agent needs its own auth middleware, its own rate limiting, its own audit logging, its own timeout handling. Each integration point is a bespoke negotiation. And the consumer typically gets broad access to whatever the endpoint exposes.
With Agora, the governance is structural:
- Visibility is structural, enforced at the catalog layer by the controller. Not "you can see it but can't access it." You can't see it.
- Engagement terms are declarative, expressed as contracts and evaluated by the controller. Not "we agreed on a rate limit in a Slack thread."
- Sessions have explicit lifecycle, with every state transition recorded. Not "the connection timed out and we're not sure if the other side noticed."
- Revocation is instant and auditable. Not "we rotated the API key and hope they noticed."
The agents themselves are simple. The governance complexity doesn't live in their code. It lives in the network.
A2A compatibility
Google's A2A protocol defines how agents communicate - Agent Cards for discovery, tasks and messages for interaction, streaming for real-time updates. It's a good protocol, and it's reaching maturity under Linux Foundation governance.
Agora is structurally compatible with A2A. Agents can carry A2A payloads inside Agora envelopes. The envelope provides the governed transport (identity, contract enforcement, audit trail); the A2A payload provides the interaction semantics (task lifecycle, streaming, structured parts).
The simplest framing: A2A is the language. Agora is the governed room where the conversation happens. A2A tells agents how to talk. Agora controls who gets in the room, what terms apply while they're there, and what the audit record says when they leave.
The full stack: how LLM Gateway and MCP Gateway compose
Agora doesn't exist in isolation. It's the collaboration layer in a three-part platform that shares a unified zero-trust foundation:
MCP Gateway secures access to MCP tool servers. Aggregates multiple backends, namespaces tools, filters permissions structurally (filtered tools don't exist in the registry, not checked at runtime). Per-client session isolation. No open ports.
LLM Gateway governs access to LLM providers. Multi-provider semantic routing (3-layer cascade: heuristics, embeddings, LLM classifier). Identity-based virtual API keys. Per-identity budgets. Guardrails for PII, content safety, prompt injection. Private model meshes without VPN.
Agora provides the governed agent network underneath. Cryptographic identity per agent. Workgroup-scoped discovery. Engagement contracts. Session governance. Full audit trail.
Each works standalone. Together, they share one identity model - the same OpenZiti identity that authenticates an agent to the Agora network also controls which LLMs it can access through LLM Gateway and which MCP tools it can invoke through MCP Gateway. One identity, three surfaces.
That means correlated observability across the full stack. You can trace a request from agent discovery through session establishment, through an LLM call for reasoning, through an MCP tool invocation for data access, and back - all tied to the same cryptographic identity. When something goes wrong, or when compliance asks what happened, the answer is in one correlated trace, not scattered across three unrelated logging systems.
Try it
All three projects are open source (Apache 2.0) on GitHub:
- Agora - the governed agent network, including the Macro Pulse demo
- LLM Gateway - governed LLM access
- MCP Gateway - governed MCP tool access
- OpenZiti - the zero-trust overlay network
For a more elaborate worked example, the Macro Pulse demo in the Agora repo composes a cross-domain morning market briefing across five organizations, eight agents, and four governed channels. It runs end-to-end with live data from free public APIs (no keys required). The SMOKE.md walkthrough covers the full setup.
If you're building multi-agent systems that cross organizational boundaries and the governance questions are starting to keep you up at night, we at NetFoundry are running an AI Accelerator design partner program with a small number of early adopters. We'd like to hear what you're building.
