Cross-Company Agent Collaboration Without Shared Infrastructure

The Protocol Fragmentation Problem

As of early 2026, there are four major proposals for how AI agents should communicate. Each addresses a different slice of the problem. None of them address all of it.

An industry observer put it bluntly: "20 standards for the same need essentially results in no standards." Each protocol optimizes for its creator's use case. A2A assumes agents have HTTP endpoints. MCP assumes agents access tools through a local server. ACP assumes a centralized orchestrator. ANP assumes decentralized identity infrastructure. None of them solve the fundamental transport problem: how do two agents that sit behind NAT, on different networks, owned by different companies, establish a secure connection?

This is not a standards problem. It is an infrastructure problem. And it is the reason cross-company agent collaboration has not happened at scale despite years of hype.

Transport vs Application: Why You Need Both Layers

The confusion in the agent protocol space comes from conflating two distinct layers:

• Application layer: What messages do agents exchange? What is the format of a task request? How do agents describe their capabilities? This is what A2A, MCP, and ACP define.
• Transport layer: How do agents find each other? How do they establish connections through NAT? How is the connection encrypted? How are peers authenticated? This is what none of those protocols define.

A2A says "send a JSON-RPC message to the agent's HTTP endpoint." It does not say how to reach that endpoint through a firewall. MCP says "connect to the tool server via stdio or SSE." It does not say what happens when the tool server is on a different network. The application-layer protocols assume transport is solved. For agents within a single organization's infrastructure, this assumption holds. For agents across organizations, it breaks immediately.

The question people keep asking -- "How is this better than MCP?" -- misses the point. A transport layer is not competing with an application protocol. It is the foundation that application protocols run on top of. HTTP is not "better than" REST. HTTP carries REST. Pilot is not "better than" A2A. Pilot carries A2A.

Pilot as the Transport Layer

Pilot Protocol gives every agent a 48-bit virtual address in the format N:NNNN.HHHH.LLLL -- 16 bits for the network, 32 bits for the node. This address is independent of the agent's physical location. An agent can move from AWS to GCP, from a data center to a laptop, and its Pilot address stays the same.

Agents find each other through a registry -- a lightweight rendezvous server that maps virtual addresses to current physical endpoints. The registry does not relay traffic. It simply tells Agent A where Agent B is right now, and the two agents establish a direct UDP tunnel between them. If both are behind NAT, the protocol's three-tier traversal handles it automatically: STUN discovery, UDP hole-punching, and relay through a beacon if hole-punching fails.

Every agent generates an Ed25519 identity key pair at first startup. This key pair is the agent's permanent identity. Trust is established through a mutual handshake protocol:

# Agent A initiates trust with Agent B
pilotctl trust request 1:0001.0000.0042 --justification "Research collaboration with PartnerCo"

# Agent B reviews and approves (or rejects)
pilotctl trust list-pending
pilotctl trust approve 1:0001.0000.0017

# Both agents can now communicate
pilotctl send-message 1:0001.0000.0042 "Ready for task delegation"

This is fundamentally different from API key exchange. Both sides must explicitly approve the connection. Either side can revoke trust instantly. The justification field creates an audit trail. And the trust relationship is cryptographic -- it is not a shared secret that can be leaked, but a signature chain that proves both parties consented.

Cross-Org Trust Model: Scoped Handshakes, No Shared Infrastructure

The critical property for cross-company collaboration is that neither company needs to deploy shared infrastructure. Each company runs its own agents. The agents connect through a public rendezvous server (or each company runs its own, and they federate). Trust is established agent-to-agent, not organization-to-organization.

This scoping is deliberate. When Company A's research agent trusts Company B's data agent, that trust relationship exists only between those two agents. It does not grant Company B's other agents any access. It does not grant Company A's other agents any access to Company B's network. Each trust relationship is a scoped, bilateral agreement between two specific identities.

What a trust handshake includes

• Requester's Ed25519 public key: Proves identity cryptographically
• Justification text: Human-readable reason for the trust request (audit trail)
• Requester's tags: Capability descriptors the other side can inspect
• Ed25519 signature: Proves the request was not tampered with

The approver verifies the signature, reviews the justification, and decides whether to accept. Once accepted, both sides store each other's public key. All subsequent communication is encrypted end-to-end with X25519 key exchange and AES-256-GCM.

Revocation

Trust revocation is instant and unilateral:

# Revoke trust from a specific agent
pilotctl trust revoke 1:0001.0000.0042

# The revoked agent can no longer:
# - Resolve your address (you become invisible)
# - Open connections to your ports
# - Send you events or messages

Because agents are private by default, revoking trust makes your agent invisible to the revoked peer. They cannot even discover that your agent exists on the network. This is the opposite of the A2A Agent Card model, where agents advertise their capabilities publicly. In Pilot, agents are dark until they choose to be seen, and only to peers they explicitly trust.

Example: Company A's Research Agent Talks to Company B's Data Agent

Here is a concrete walkthrough. Company A builds AI research agents. Company B provides financial data analysis. They want to collaborate: A's research agent sends a query, B's data agent runs the analysis and returns results.

Setup (one time per agent)

# Company A: install and start research agent
go install github.com/TeoSlayer/pilotprotocol/cmd/pilotctl@latest
pilotctl daemon start
pilotctl join 1
pilotctl set-hostname research-agent-a
pilotctl tags set role=research,domain=finance

# Company B: install and start data agent
go install github.com/TeoSlayer/pilotprotocol/cmd/pilotctl@latest
pilotctl daemon start
pilotctl join 1
pilotctl set-hostname data-agent-b
pilotctl tags set role=analysis,domain=finance,accepts=queries

Establish trust

# Company A's agent requests trust with Company B's agent
pilotctl trust request 1:0001.0000.0042 \
  --justification "Q1 financial research collaboration per MSA dated 2026-01-15"

# Company B's agent reviews and approves
pilotctl trust list-pending --json
# {"address":"1:0001.0000.0017","justification":"Q1 financial research collaboration..."}
pilotctl trust approve 1:0001.0000.0017

Collaborate

# Company A: submit a task to Company B's agent
pilotctl task submit 1:0001.0000.0042 \
  --description "Analyze Q1 revenue trends for NASDAQ tech sector" \
  --payload '{"sectors":["tech"],"exchange":"NASDAQ","period":"Q1-2026"}'

# Company B's agent processes the task and returns results
# Company A receives the result over the encrypted tunnel
pilotctl task status <task-id> --json

Go integration for programmatic use

package main

import (
    "encoding/json"
    "fmt"
    "log"

    "github.com/TeoSlayer/pilotprotocol/pkg/driver"
)

func main() {
    d, err := driver.Connect()
    if err != nil {
        log.Fatal(err)
    }

    // Submit task to partner's data agent
    task := map[string]any{
        "description": "Analyze Q1 revenue trends for NASDAQ tech sector",
        "payload": map[string]any{
            "sectors":  []string{"tech"},
            "exchange": "NASDAQ",
            "period":   "Q1-2026",
        },
    }

    result, err := d.SubmitTask("1:0001.0000.0042", task)
    if err != nil {
        log.Fatal(err)
    }

    // Result arrived over encrypted tunnel
    // No shared API, no API keys, no firewall rules
    var analysis map[string]any
    json.Unmarshal(result, &analysis)
    fmt.Printf("Analysis: %v\n", analysis)
}

At no point did either company deploy shared infrastructure. No shared API gateway. No shared message queue. No shared database. No shared cloud account. Each company runs its own agents on its own infrastructure. The agents connect peer-to-peer through encrypted tunnels, with trust established by mutual cryptographic handshake.

Security Properties

Cross-company communication demands stronger security properties than internal communication. Here is what Pilot provides at the transport layer:

End-to-end encryption

Every connection between trusted agents is encrypted with X25519 key exchange + AES-256-GCM. The encryption happens at the tunnel level, between the two agent daemons. The registry, beacon, and any relay infrastructure see only encrypted payloads. Even if the rendezvous infrastructure is compromised, the attacker cannot read the traffic between agents.

Each connection uses a random nonce prefix, preventing nonce reuse across sessions. The key exchange happens during the secure handshake (port 443), and the resulting symmetric key is used for all subsequent communication on that connection.

Trust revocation

Either party can revoke trust at any time, with immediate effect. The revoked agent cannot reconnect, cannot resolve the revoker's address, and cannot discover the revoker on the network. This is instant and unilateral -- no waiting for certificate expiration, no CRL distribution delay, no need to coordinate with the other party.

Audit trails

Pilot uses structured logging via Go's slog package. Every trust operation, connection establishment, and data exchange is logged with structured fields. Combined with the webhook event system, organizations can pipe agent activity into their existing SIEM infrastructure:

# Forward all agent events to your monitoring system
pilotctl set-webhook http://localhost:9090/siem-ingest

# Events include: trust.request, trust.approve, trust.revoke,
# connection.open, connection.close, task.submit, task.complete

No prompt injection surface

One critique of application-layer agent protocols is that they create prompt injection attack surfaces. When Agent A sends a natural language message to Agent B, and Agent B feeds it into an LLM, the message itself can contain prompt injection payloads. Pilot does not solve this -- it is a transport-layer protocol, not an application-layer protocol. But by separating transport from application semantics, Pilot allows organizations to implement their own sanitization and validation logic at the application layer without the transport layer interfering.

The Pilot + A2A + MCP Stack: How They Complement

The three protocols are not competing alternatives. They operate at different layers and serve different purposes:

• Pilot Protocol (transport): Addresses, tunnels, encryption, NAT traversal, trust. How agents connect.
• A2A (agent-to-agent semantics): Task delegation, capability advertisement, status updates. What agents say to each other.
• MCP (agent-to-tool access): Tool discovery, invocation, result formatting. How agents use tools.

In a full stack deployment:

1. An agent discovers a peer through Pilot's registry and tag system
2. It establishes a trust handshake (Pilot layer)
3. It fetches the peer's A2A Agent Card over the Pilot tunnel (A2A over Pilot)
4. It delegates a task using A2A's JSON-RPC format, sent over the encrypted tunnel
5. The receiving agent uses MCP to access local tools needed for the task
6. The result travels back over the Pilot tunnel

Pilot solves the problems that A2A and MCP do not address: peer discovery behind NAT, encrypted transport without TLS certificate management, and cryptographic trust establishment without a shared identity provider. A2A and MCP solve the problems that Pilot does not address: standardized task semantics and tool access patterns.

                  Application Layer
  +-----------+     +-----------+     +-----------+
  |    A2A    |     |    MCP    |     |  Custom   |
  |  (tasks)  |     |  (tools)  |     |  (yours)  |
  +-----------+     +-----------+     +-----------+
        |                 |                 |
  +---------------------------------------------------+
  |              Pilot Protocol (transport)            |
  |  Addresses | Tunnels | Encryption | NAT | Trust   |
  +---------------------------------------------------+
        |                 |                 |
  +---------------------------------------------------+
  |                 UDP / Internet                     |
  +---------------------------------------------------+

This layered architecture means you are not locked into any single application protocol. You can use A2A for agent-to-agent task delegation, MCP for tool access, and your own custom protocol for domain-specific communication -- all over the same Pilot tunnels, with the same trust model and encryption.

Getting Started

Cross-company agent collaboration starts with two commands on each side:

# Both companies install and join the same network
go install github.com/TeoSlayer/pilotprotocol/cmd/pilotctl@latest
pilotctl daemon start
pilotctl join 1

# Establish trust (one-time, mutual)
pilotctl trust request <partner-address> --justification "Collaboration purpose"

# Start communicating
pilotctl send-message <partner-address> "Ready to collaborate"

No shared infrastructure to deploy. No API contracts to negotiate. No firewall rules to configure. No VPN to provision. Two agents, two trust handshakes, and a direct encrypted tunnel between them. That is the cross-company collaboration model that the agent ecosystem needs.