Loom

WHAT LOOM IS

Loom is an LLM gateway. You build your application against one consistent contract — a managed agent, with sessions, memory and tools — and Loom guarantees that contract over any provider. Where a provider offers managed-agent capabilities natively, Loom adapts to them; where it doesn’t, Loom supplies the missing capabilities itself. Rather than collapsing every provider down to a lowest-common-denominator completion API, Loom levels every provider up to the same managed-agent contract.

That contract is OASP — the Open Agent Session Protocol — a vendor-neutral standard shaped on the Anthropic Managed Agents API, written as the first step toward building Loom. Loom is its reference implementation, but the product is the point: the standard is the contract it stands on.

ONE CONTRACT, NOT ONE PROVIDER

Developers should write against a contract, not a provider. A single application shouldn’t need an anthropic endpoint and an openai endpoint — there is one contract, and it’s the same managed agent whether or not the provider underneath has any concept of one.

An early cut of Loom did the opposite — a route per provider, mirroring each provider’s own API — which is exactly the pattern the contract exists to prevent. The contract comes first; providers are adapted to meet it.

A MANAGED AGENT OVER ANY PROVIDER

A gateway that normalises every provider down to a shared completion API gives you the intersection of what they have in common — the lowest common denominator. That is a fine fit when the requirement is broad, provider-agnostic reach. Loom’s requirement is the opposite: the same managed agent, whatever the provider underneath happens to support. The contract is a guarantee held at the top, not a floor set by whatever every provider shares.

• If a provider has no concept of memory, Loom is the memory.
• If a provider offers only completion and has no notion of a session, Loom provides the session.
• Wherever a provider lacks a managed-agent capability the contract promises, Loom fills it in. Where it has one natively, Loom uses it.

CHANGE THE ENDPOINT

Because the contract is shaped on the Anthropic Managed Agents API, an application already using that API adopts Loom by changing one thing. Loom keeps an Anthropic-compatible entry point, so you point your existing client at the Loom server and it works on day one — same code, now with the gateway’s provider adapters, virtual keys, budgets and usage underneath it.

Change the endpoint. Then migrate the API surface as required.

// Point your existing Anthropic managed-agents client at Loom.
// Same code — provider adapters, virtual keys and budgets underneath.

- baseUrl: "https://api.anthropic.com"
+ baseUrl: "https://loom.example/v1"

That compatible route is an on-ramp, not the surface you develop against long-term. From there you migrate onto the contract as you need it. Getting onto Loom is an endpoint swap, not a rewrite.

WHY OASP EXISTS

The product and the standard are easy to confuse, so it is worth stating the relationship plainly.