Skip to main content
Bridge comes up in the same conversations as MCP and A2A because all three sit near the agent stack. They are related, but they do different jobs. Bridge is the context layer. MCP is the tool-and-resource layer. A2A is the agent-to-agent coordination layer.
This page is the conceptual map. For the current Bridge CLI surface, see Commands, Configuration, and Providers.

​
Three different jobs in the stack

The easiest way to think about the three layers is to ask what problem each one solves.
LayerCore questionTypical surface
MCPHow does an app or host talk to tools, resources, and prompts?Client-server protocol
A2AHow does one agent discover and collaborate with another agent?Agent-to-agent protocol
BridgeHow does an agent read durable context from storage through one stable interface?Local-first CLI and provider model
These layers can overlap in a real system, but they are not interchangeable.

​
Where Bridge fits

Today, Bridge is a local-first CLI that sits between your agent framework and your storage backends. That means Bridge gives you:
  • one config file: bridge.yaml
  • one command model: ls, read, status
  • one output format: structured JSON
  • one provider abstraction over multiple backends
Right now, that abstraction is implemented for:
  • the filesystem
  • Postgres
The short version is that Bridge standardizes context access, not agent communication and not model-host tool protocol by itself.

​
Where MCP fits

MCP is useful when you want a standardized protocol between a client or host and the tools, resources, and prompts that it can use. In practical terms, MCP is good at things like:
  • exposing tools to an MCP-aware host
  • exposing resources and prompts through a common protocol
  • negotiating capabilities between an MCP client and server
Bridge complements MCP rather than replacing it.

​
Bridge vs MCP

Use Bridge when your main problem is storage normalization:
  • your agent needs to read files, tables, or future storage backends
  • you do not want custom SDK logic for each backend
  • you want one local, machine-readable interface
Use MCP when your main problem is host-tool integration:
  • your host expects MCP servers
  • you need MCP-native tools, resources, or prompts
  • you want a protocol boundary between a client and a server

​
How they work together

Bridge can sit behind an MCP server. That pattern looks like:
  1. an MCP-aware host calls a tool or resource
  2. the MCP server calls bridge
  3. Bridge resolves the provider and returns structured JSON
  4. the MCP server passes the result back through the MCP surface
That lets you keep MCP at the host boundary while Bridge handles storage differences underneath.

​
Where A2A fits

A2A is useful when one agent needs to discover, contact, and collaborate with another agent. In practical terms, A2A is good at things like:
  • agent discovery
  • capability negotiation
  • long-running task collaboration
  • communication between agents without exposing their internal memory or tool implementation
Bridge complements A2A rather than replacing it.

​
Bridge vs A2A

Use Bridge when your main problem is durable context:
  • multiple agents need a stable way to read the same underlying project or backend context
  • you want storage access to look the same across backends
  • you want a context surface that is separate from a specific agent framework
Use A2A when your main problem is coordination:
  • one agent needs to delegate work to another
  • agents need a common language for collaboration
  • you care about agent discovery, task lifecycle, or modality negotiation

​
How they work together

A2A helps agents talk to each other. Bridge helps them refer to the same context. A simple mental model is:
  • A2A answers: “Which agent should do this work, and how do they collaborate?”
  • Bridge answers: “What shared context can those agents read while doing it?”

​
The stack Bridge is aiming for

The website and strategy materials describe a broader Bridge direction than the current CLI alone. Today:
  • Bridge CLI is local-first
  • Bridge focuses on reading context from your own storage
  • Bridge does not yet provide a hosted cross-organization context layer
Over time:
  • Bridge Cloud is intended to add permissioned sharing, discovery, and access control
  • that is where Bridge starts to look more like a shared context layer across teams and organizations
That distinction matters because the conceptual vision is broader than the currently shipped CLI.
If you read Bridge as “the missing layer in the AI protocol stack,” the practical meaning today is narrower: Bridge already fills the storage-normalization gap locally, and the broader cross-org context layer is the direction Bridge Cloud is meant to extend.

​
A useful mental model

If you want a shorthand:
  • MCP gives your host a standard way to reach tools and resources
  • A2A gives agents a standard way to reach other agents
  • Bridge gives agents a standard way to reach context across storage
That is why Bridge can live alongside both protocols without competing directly with either one.

​
Example architectures

​
Bridge by itself

You have one agent and multiple storage backends. 
Agent -> bridge read -> filesystem / Postgres / future providers
This is the simplest Bridge setup and it is fully aligned with what the CLI ships today.

​
MCP plus Bridge

You already use an MCP-aware host, but you do not want your MCP server to contain custom storage logic for every backend. 
Host -> MCP server -> bridge -> storage backends
Here, MCP handles host integration and Bridge handles context normalization.

​
A2A plus Bridge

One agent delegates work to another, and both need a common view of relevant context. 
Agent A -> A2A -> Agent B
Agent A -> bridge -> shared backend
Agent B -> bridge -> shared backend
Today that shared backend is still your own storage. In the longer-term Bridge vision, Bridge Cloud is where permissioned shared context across teams and organizations would fit.

​
What Bridge is not

Bridge is not:
  • a replacement for MCP if you need an MCP-native tool and resource protocol
  • a replacement for A2A if you need agent discovery and inter-agent collaboration
  • a full hosted security or policy platform today
  • a complete shared-session system today in the CLI alone
That clarity is important because Bridge becomes easier to understand once it is framed as a distinct layer instead of a universal protocol replacement.

​
When to reach for each layer

  • Reach for Bridge when you want one stable context interface across storage backends.
  • Reach for MCP when you need a standard client-server protocol for tools, resources, or prompts.
  • Reach for A2A when agents need to discover each other and collaborate on tasks.
  • Use them together when you need both communication and durable context in the same system.

Introduction

Start with the high-level story of Bridge as a local-first context layer for agents.

CLI interface

See how that conceptual model turns into JSON contracts and provider-based commands.

Commands

See the concrete CLI surface that Bridge ships today.

Providers

See what Bridge actually exposes from the filesystem and Postgres right now.