--- title: "The Capsule Collaboration Bridge" slug: "capsule-collaboration-bridge" summary: "A first bridge for user-to-user and AI-to-AI collaboration where the shared medium is a verifiable Capsule rather than a central orchestrator." status: "draft" version: "0.1" updated: "2026-05-07" audience: - "product builders" - "agent framework authors" - "collaboration system designers" tags: - "collaboration" - "multi-agent" - "handoff" - "x2x" canonical_path: "/research/capsule-collaboration-bridge" --- # The Capsule Collaboration Bridge ## User-to-User and AI-to-AI Continuity Without a Central Orchestrator ### Abstract Most collaboration systems assume a platform owns the shared state. Most agent systems assume a runtime owns the orchestration. Capsules offer another bridge: the shared medium is a portable, verifiable artifact. A user can hand a capsule to another user. An AI agent can hand a capsule to another AI agent. A system can append an observation and pass the same artifact onward. The bridge is not a chat room, queue, or SaaS workspace. It is an event-bearing file that each actor can verify, read, extend, and return. --- ## 1. Collaboration failure Human-to-human collaboration fails when context is scattered. AI-to-AI collaboration fails when state is trapped in a runtime. Human-to-AI collaboration fails when the model cannot see the history of decisions. The common failure is not messaging. It is continuity. A message says something happened. A capsule carries what happened, the current state of the work, what remains open, and the evidence chain that got it there. --- ## 2. The bridge model The bridge has four actors: - `human:*` - `ai:*` - `system:*` - `capsule:*` All actors write to the same event grammar. That is the X2X premise: user-to-user, user-to-AI, AI-to-AI, and system-to-agent collaboration can share one medium. The collaboration bridge requires only a minimal protocol: 1. verify the capsule 2. read `program.md`, `agents.md`, `manifest.json`, payload references, skills, and recent chain events 3. decide whether to act 4. append a logical event if action occurs 5. checkpoint when control should transfer 6. return the updated capsule or a result envelope --- ## 3. Why the bridge is not an orchestrator An orchestrator decides what runs and when. A capsule preserves what was decided and done. That distinction matters. The same capsule can pass through: - a local human using a CLI - a browser runtime - a hosted cloud agent - a mobile WebView - another LLM with different tools Each environment may have different capabilities. The capsule does not require them to be identical. It requires each actor to record meaningful actions in a shared ledger. --- ## 4. Handoff as the bridge primitive The bridge becomes practical when every transfer includes: - `program.md`: what a human or AI should understand now, including plan and continuation notes - `agents.md`: actors, roles, authority notes, and trust context - `manifest.json`: the content index and skill trust metadata - `payload/`: evidence, generated files, and other referenced bytes - `chain/events.jsonl`: what happened, in order - `skills/`: portable instructions that can help the next host continue the work - `provenance/envelope.json`: the signed outer metadata and verification boundary The next actor does not need the previous runtime. It needs the artifact. --- ## 5. AI-to-AI collaboration AI-to-AI collaboration should not mean one model sends opaque thoughts to another. It should mean one model records a decision/action/result into the capsule and another model continues from the verified state. This keeps collaboration bounded: - no hidden memory dependency - no unverifiable conversation-only state - no platform-specific queue as the only source of truth - no trust requirement that the next model uses the same vendor or framework The receiving model can disagree, fork, or append a correction. The chain records the dispute. --- ## 6. User-to-user collaboration For users, the value is similar. A person can pass a capsule as a work packet. The recipient can inspect the surface, verify the package, see open items, and continue. This is especially useful for high-consequence work: compliance reviews, medical referrals, legal aid packets, incident response, and financial readiness workflows. The companion use-case lab is staged in [capsules-extra/use-cases](https://github.com/virionai/capsules-extra/tree/main/use-cases), with the current build/evaluate lane in [use-cases/use-case-landscape](https://github.com/virionai/capsules-extra/tree/main/use-cases/use-case-landscape). In those workflows, a chat transcript is not enough. A database row is not portable enough. A static PDF is not operational enough. The capsule bridge is the middle layer: portable, verifiable, and resumable. --- ## 7. First implementation target The first bridge should be deliberately small: - one capsule - two users - two AI systems - one handoff - one verification step - one append by each actor - one final checkpoint The candidate scenario set should be derived from the [capsule use-case framework](https://github.com/virionai/capsules-extra/blob/main/use-cases/capsule_use_case_framework.md), not from broad unactionable market lists. Success is not autonomy. Success is continuity: each actor can understand what happened before and leave the next actor a better artifact. --- ## 8. Current bridge evidence: MCP-Hydrate MCP-Hydrate is the first working bridge slice in this repository. It is deliberately modest: a local MCP relay where agents publish public keys, start threads, send already sealed and encrypted Capsule v0.6 messages, wait for inbox items, and fetch encrypted capsule bytes for local hydration. The relay does not accept private keys. It verifies the encrypted outer capsule against the registered sender key, infers recipients from the encryption key bundles, stores the capsule unchanged, and returns encrypted bytes to the recipient. The recipient decrypts locally. That boundary matters for collaboration. The bridge should not become the trusted workspace. It should move a sealed artifact between workspaces. The next Hydrate step is the Inbox Bridge: a host-native watcher that long-polls Hydrate, decrypts and verifies locally, routes by default-deny allowlist, pins sender signing keys, quarantines unverifiable messages, and opens a human-gated session with the received capsule framed as untrusted mail. This gives the collaboration bridge a concrete research agenda: - complete a two-agent reply loop - add signed or self-certifying directory entries - add broker authentication and rate limits - test tampered-capsule and wrong-recipient paths - measure whether capsule hydration improves time-to-resume over transcript replay --- ## Sources and related work - Gemini Enterprise Agent Platform docs describe managed agent runtime, sessions, memory, agent identity, gateway, observability, and evaluation capabilities: https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale - MCP-Hydrate local relay and Inbox Bridge design are staged in this repository under `MCP-Hydrate/` - Capsule format and event model: `capsules-protocol/spec/format.md` and `capsules-protocol/spec/chain.md` - Public capsule skill mirror: `capsule-www/public/skills/capsule/skill.md` - Capsules Extra use-case lab: https://github.com/virionai/capsules-extra/tree/main/use-cases - Capsule use-case framework: https://github.com/virionai/capsules-extra/blob/main/use-cases/capsule_use_case_framework.md