Skip to main content

Bridges Overview

Bridges are VPC peering for AI workspaces. They create end-to-end encrypted, contract-governed communication channels between Roundtable workspaces using the A2A protocol (Agent-to-Agent, JSON-RPC 2.0 over HTTP). Specialized AI agents collaborate on complex tasks that span teams, domains, or data boundaries — authenticated by cryptographic contracts and encrypted so that only the contracted parties can read the content.

Why Bridges Are Powerful​

In most organizations, knowledge lives in silos. Your engineering team operates in one context, analytics in another, and security in yet another. Bridges break down these silos by letting workspaces delegate tasks to each other without sharing credentials, merging data, or losing specialization.

Each workspace keeps its own:

  • AI provider and model — tuned for its domain
  • System prompt — optimized for its specific role
  • Data connections — scoped to what it needs
  • Tool permissions — limited to relevant capabilities

Bridges let these specialized workspaces work together as a team.

Use Cases​

ScenarioSource WorkspaceTarget WorkspaceWhat Happens
Revenue analysisEngineeringAnalyticsEngineering workspace delegates "summarize last week's revenue" to Analytics, which has BigQuery access and a data-focused system prompt
Incident triageSecurityDevOpsSecurity workspace queries infrastructure logs via the DevOps workspace, which has shell access to monitoring tools
Customer escalationSupportEngineeringSupport workspace delegates a bug investigation to Engineering, which can read code and query error databases
Report generationExecutiveAnalyticsExecutive workspace asks Analytics to build a weekly KPI summary from Snowflake data

Plan Requirement​

:::info Team, Business, or Enterprise Bridges are available on the Team ($50/ws/mo), Business ($100/ws/mo), and Enterprise plans. Team plan workspaces can use bridges with preset contracts only. Business and Enterprise plans support full custom contracts. :::

Key Concepts​

Bridges support a cross-workspace execution model with two mechanisms:

Intent Compilation (ICE) — Structured Execution​

For structured operations — queries, tool calls, data pipelines — use the intent_bridge tool. ICE compiles the operation into a deterministic execution plan that runs directly on the target workspace without invoking its LLM. The source AI reasons about what to do; ICE executes it in ~15ms hot / ~15s cold (with wake-on-request).

Source AI reasons → intent_bridge compiles → Target workspace executes deterministically → Result returned

ICE is the preferred path for any operation that can be expressed as a structured intent. See Intent Compilation Engine for details.

Wake-on-Request​

Workspaces scaled to zero replicas are automatically woken when a bridge call arrives. Both bridge_workspace and intent_bridge implement this transparently:

  1. Caller sends request → receives HTTP 503 (target sleeping)
  2. Caller scales target deployment 0→1 via Kubernetes API
  3. Caller retries every 5s with fresh HMAC signatures (up to 120s)
  4. Target responds once healthy (~15s typical cold start)

No user intervention required — the AI simply waits and returns results.

Delegate (Invoke Target AI)​

Delegation sends a task to another workspace's AI agent and waits for the result. The target workspace processes the request using its own AI provider, model, tools, and data connections, then returns the response.

Source Workspace → "Summarize Q2 revenue by region" → Target AI processes → Result returned

Delegation is the last resort — use it only when you genuinely need the target workspace's AI to reason about a task (e.g., summarizing data, drafting a report, or making judgment calls). For everything else, prefer ICE.

Architecture​

Bridges use direct A2A communication (Agent-to-Agent protocol, JSON-RPC 2.0 over HTTP) with a contract-enforcement relay through the control plane. Every request carries a cryptographic contract token so that the target pod can independently verify the terms without calling back to the control plane.

┌──────────────┐  HMAC-signed request   ┌────────────────┐  Verified request  ┌──────────────┐
│    Source     │ ─────────────────────► │  Control Plane │ ──────────────────► │    Target    │
│  Workspace   │                         │   (relay +     │                     │  Workspace   │
│              │ ◄───────────────────── │   enforcement) │ ◄────────────────── │     Pod      │
└──────────────┘       Response          └────────────────┘      Response        └──────────────┘

Dispatch flow (control plane):

  1. Source workspace calls bridge_workspace with a target and task.
  2. Control plane looks up the active (or pending_amendment) contract for the source→target direction.
  3. Verifies the requested action is in the contract's allowedActions — rejects with 403 if not.
  4. Generates a contractToken: HMAC-SHA256(secret, contractId:sortedAllowedActions) — a cryptographic fingerprint of the contract's terms.
  5. Signs the full request: HMAC-SHA256(secret, taskId:timestamp:contractId:action) — binds the specific action and contract into the signature.
  6. Forwards the request to the target pod with contractId, contractToken, and the extended signature.

Enforcement gate (target pod):

The pod's bridge receive handler runs four checks in order — all must pass:

StageCheckFailure
1HMAC signature valid + timestamp ≤ 5 min old401 Unauthorized
2contractId exists in local RT_CONTRACTS manifest403 CONTRACT_NOT_FOUND
3contractToken matches locally re-derived HMAC of manifest terms403 CONTRACT_TOKEN_INVALID
4Requested action is in local manifest's allowedActions403 ACTION_NOT_PERMITTED

Enforcement is self-reinforcing: the pod independently re-derives the contract token from its own manifest copy. Even if a request bypassed the control plane, the pod would reject it. Tampering with allowedActions in transit fails at stage 3 before stage 4 is ever reached.

:::tip Security by Design Every bridge request is authenticated by a governance contract — a typed, approved agreement that defines what actions are allowed. The contract's terms are cryptographically bound into every request, so neither the control plane nor any infrastructure component can grant permissions that weren't explicitly approved by both workspace admins. :::

Intent Compilation Engine (ICE)​

For structured operations (queries, tool calls, data pipelines), Roundtable offers compiled intent bridges via the intent_bridge tool. These bypass LLM inference entirely on the receiving workspace, executing deterministically in ~15ms instead of 2-8 seconds.

See Intent Compilation Engine for details.

Next Steps​