The Gap Between "Agents Can Talk" and "Agents Should Talk"

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, you write the orchestration. It works.

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:

1. 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.
2. 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.
3. 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; A2A handles wire protocol well. 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:

1. Workgroups - policy boundaries that control visibility and interaction scope. If you're not in the workgroup, you don't see the agents in it. Not a filtered view. They don't exist from your perspective.

2. 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.

3. Advertisements - an agent's persistent declaration of what it can do. Capabilities, interaction patterns, visibility scope, contract requirements. Survives agent restarts.

4. 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.

5. 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.

6. 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.

Macro Pulse: five orgs, eight agents, governed collaboration

The Macro Pulse reference demo ships with Agora. It's a cross-domain morning market briefing that blends signals from independent data providers - the kind of scenario where governance isn't optional.

The setup

A financial services firm wants a daily "macro pulse" brief that combines market data, weather signals (supply-chain and energy proxies), and internet activity (search trends, news sentiment). The data comes from independent providers who don't want to share raw feeds with each other or with the client.

Five organizations. Eight agents:

• markets-co runs three agents: equity indices (S&P 500, sector indices), FX pairs (major currencies), and commodities (WTI crude, gold, Henry Hub gas)
• weather-co runs one agent: current and forecast weather for economic hubs
• signals-co runs two agents: search trends (Wikipedia Pageviews) and news sentiment (GDELT)
• analytics-co runs two tool agents: a correlator (Pearson r between any two time series) and a narrator (template-driven prose summaries)
• enterprise-client runs one orchestrator: the pulse-agent that composes the briefing

Four inter-org workgroups connect providers to the client. Each provider gets its own channel: markets-channel, weather-channel, signals-channel, analytics-channel.

The governance narrative

This is where Agora earns its keep. Five properties that you don't get from "just call each service over HTTPS":

Per-channel visibility. markets-co cannot see signals-co. They don't share a workgroup. Nothing in Agora surfaces the other's presence, capabilities, or identity. The consuming client is the only party with visibility across all four channels. Each provider operates as if it's the only data source.

Bounded sessions. Every session the pulse-agent opens carries a contract: max_duration_seconds=60, allowed message types defined. If the agent tries to send a message type outside the contract's bounds, the controller rejects it. If the session exceeds its duration, it's closed. The provider doesn't need to implement any of this - the contract speaks for it.

Auditable correlation. Every envelope carries a correlation_id header. The full chain - which tickers were requested, which weather cities were queried, which correlation was computed, which narrative was generated - is reconstructible from controller audit logs, because every envelope passes through the governed session.

Clean revocation. A provider can revoke a workgroup membership or decline a new invitation. The client loses access instantly. Active sessions are closed immediately with a recorded close reason. Unlike API key revocation, there's no rotation window to wait through and no question about whether old copies are still in use somewhere.

Minimal data exposure. The correlator agent receives two time series. That's it. It doesn't see the tickers, the weather cities, the client's identity beyond what envelope headers carry. The narrator gets numeric inputs and produces prose. Neither tool agent has any visibility into the broader context of the briefing. Each agent sees exactly what it needs and nothing more.

The output

The pulse-agent prints a structured morning brief - markets (S&P 500, USD/EUR, gold, WTI crude with 7-day changes), weather (conditions at economic hubs with supply-chain implications), signals (search volume shifts, news sentiment), cross-domain correlations (any pair with |r| > 0.4), and a deterministic prose summary. No LLM calls. The narrator is template-driven. The entire output is reproducible given the same inputs.

The demo runs with embedded snapshot data by default (fully offline, deterministic) or with live data from free public APIs (Yahoo Finance, Open-Meteo, Wikipedia Pageviews, GDELT) using the --live flag. No API keys required for any data source.

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

A fair question: how does this relate to Google's A2A protocol?

A2A defines how agents communicate - Agent Cards for discovery, tasks and messages for interaction, streaming for real-time updates. It's a good protocol. 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

The Macro Pulse demo runs end-to-end with live data sources. The SMOKE.md in the repo walks through the full procedure.

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.