Interoperability
Bring your agent. Keep your code.
Loom speaks the open agent protocols the industry has settled on — and turns any agent, written in any language against any framework, into a first-class citizen of the fabric. No rewrite, no lock-in, no learning the plumbing.
Two layers, cleanly split
The agent-interoperability world converged on exactly the split Loom always bet on — and both halves are now Linux‑Foundation-governed, not any one vendor's.
A2A — agent to agent
Agent2Agent is the horizontal protocol: agents discovering and delegating to one another. Its Agent Card — a JSON descriptor of identity, skills and security — is the closest thing in the wild to a Loom capability manifest. Loom speaks A2A at its edge and ingests the Agent Card directly.
MCP — agent to tool
The Model Context Protocol is the vertical one: an agent reaching for tools. Loom keeps it at the edge exactly where it belongs — every MCP tool call is re-wrapped in a signed envelope with a real principal before it touches the fabric. Open-ended discovery outside; accountable plumbing inside.
Speak it, ingest it, or ignore it
Every external spec plays one of two roles: a protocol Loom speaks at the edge, or a description Loom ingests to mint a capability. The rest we deliberately leave alone.
Your agent is a black box. Loom makes it a citizen.
Every Loom agent already separates two things: fabric citizenship — registration, heartbeats, signed envelopes, retries, audit, cost — from agent logic, the code that actually does the work. The first lives in a thin adapter; the second is a black box bolted onto it.
Ingesting your agent means attaching your black box to that same adapter — without your code ever learning the adapter exists. Loom asks one small thing of it, and carries everything else.
One shell, and you're a citizen
The adapter is the fabric doing the fabric's job around your code: it takes the signed envelope, does the ceremony, hands your agent plain JSON, and turns the answer back into an accountable fabric event.
It verifies
HMAC signature, deadline and idempotency key are all checked in the adapter. A redelivered request is caught; an expired one is dropped. Your code never sees an envelope, a broker or a key.
It invokes
The adapter strips the envelope to bare payload plus a little scrubbed context — principal, tenant, remaining deadline — and calls your agent with plain JSON in, plain JSON out.
It accounts
The answer is re-wrapped as a result envelope; the action lands in the audit stream and the cost meter. Everything your agent does is attributable, whether or not your agent knows it.
One tiny contract, any language
Loom doesn't dictate your Dockerfile, your language or your framework. It asks for a handful of things and carries the rest itself.
- Answer POST /invoke — JSON in, JSON out, matching your declared schemas.
- Answer GET /health — so the fabric knows you're alive.
- Ship a manifest — an A2A Agent Card, agent.json or OpenAPI spec.
- Declare your idempotency — the one thing only you can know.
You never touch RabbitMQ, envelopes, HMAC, heartbeats or the tenancy vault. That's the adapter's job.
# your container, any language
POST /invoke
{ payload: { … },
context: { principal, tenant, deadline_ms } }
→ { result: { … } }
GET /health # → 200 ok
manifest: agent-card.json # skills + schemas
idempotency: at-least-once-safeFour ways to bind
Whatever shape your agent arrives in, it binds one of four ways — the only real difference is where the adapter points.
Proxy a remote
Your agent already runs somewhere — a SaaS, an A2A service. The adapter points at its URL; nothing of yours runs inside Loom. This is the A2A / MCP edge.
Host a container
You hand Loom a container. It runs beside a Loom adapter sidecar that calls it over localhost. Your Dockerfile can be anything that answers /invoke.
Adopt the SDK
Want to re-home fully? Subclass the fabric SDK and write one handler. Best latency, deepest integration — and Loom generates the skeleton from your manifest.
Synthesise from a spec
If all you have is a declarative manifest that composes existing capabilities, there's no code to run at all — Loom compiles it into a native transducer.
Everything the fabric requires, met on your behalf
Heartbeats
The adapter is the citizen — it heartbeats. It polls your /health; if you go dark it deregisters your capability and says so in the audit stream. Fabric liveness and agent liveness stay cleanly apart.
Identity & envelopes
HMAC verification and signing, the requesting principal, OAuth2 callbacks — all handled in the adapter. Your code sees scrubbed plain fields, never a signed envelope.
Retries & idempotency
The adapter honours the idempotency you declared — it won't blindly re-run an agent that isn't safe to re-run; it dead-letters instead, for an operator to inspect.
Deadlines
Every request carries a deadline; the adapter enforces it and passes the remaining budget into your /invoke so a well-behaved agent can cooperate.
Cost attribution
Route your model calls through the vault — a base URL we inject — and every token is attributed per tenant. Keep your own keys and you're still metered, at invocation granularity.
Audit
Every invocation lands in the audit stream with who asked, who acted and what it cost. Your black box stays private; its behaviour is fully accountable.
From a manifest to a citizen, in one path
Point Loom at a definition and it does the rest — the boundary is the only place a foreign trust model is ever converted; nothing foreign reaches the plumbing.
Read the manifest · mint the capability · pick the binding · stand up the adapter. Then it's just another citizen — composable in transducers, audited, cost-attributed like everything else.
Bring the agent you already have
Tell us what your agent is built on — A2A, MCP, a raw container, a framework export — and we'll show you the path into the fabric.