For teams shipping services-as-software agents

The context layer your agent needs. Already built.

Your agents decide who gets seen, who gets approved, what happens next. Wire holds the context behind those decisions.

The plumbing

Six pieces, every time.

Your context is your moat, and every agent team builds the same plumbing around it. Wire ships it built, in every container.

01 · Ingest

From anywhere

Files, connectors, pipelines, or agents writing directly. It all becomes queryable context, parsed and connected in the background.

02 · Scope

A secured perimeter

Separate context per customer, per session, per agent. Each scope is its own container with its own endpoint, and your agent only ever sees what the task needs.

03 · Permission

Nothing escalates

RBAC and per-credential tool allowlists decide which agents and people touch each scope. One credential full access, another search-only.

04 · Retrieve

Search agents can actually use

The right slice back over MCP, across corpuses too big for any context window, with provenance on every result.

05 · Sync

Always the live version

When the source changes, your agent reads the new one. No stale snapshots, no rebuild scripts, no versioning logic in the agent.

06 · Disclose

Reproduce what the agent saw

Every access logged with the agent and the user who authorized it. When someone asks why the agent decided something, you can show what it saw.

The SDK

Who brings the context?

Your users can bring their own containers, or your backend provisions them with one org key. Four shapes cover how agents connect.

Many of your agents · their container

Your users bring their own context

The user approves in the browser and your agents get a scoped endpoint to their container. They own the context, it bills to them, and your product never touches the data.

Coding assistant. Grounds in the project's decisions, from IDE to CLI to chat.

Research agent. Reads their notes and sources, writes back findings they keep.

Connect flow docs →
BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/)
BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/)
BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/)
AvataaarsPablo Stanleyhttps://avataaars.com/https://avataaars.com/Remix of „Avataaars” (https://avataaars.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use.” (https://avataaars.com/)
BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/)
BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/)
mia/project-notes owned by mia

their container · a scoped endpoint per agent · bills to them

Your org · many agents, one container

One knowledge base, the whole fleet

Your backend provisions containers with one org key. Point every agent at a shared container and they all read the same live version.

Ops copilot. Answers from the org's runbooks and product docs.

Team workspace. Many agents write findings back and read each other's work.

Provision mode docs →
BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/) BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/) BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/) BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/)
company-kb
├─ playbook.md
├─ product-docs.pdf
└─ api:notion-sync

one shared container · every agent reads the same live version

Your org · one agent, one container

A container per customer

For work that is bespoke to each account: its own data in and out, its own container, and the agent that works it. Nothing bleeds between accounts, and your customers never see Wire.

AE agent. Works each account's unique deal shape, usage, and history.

Per-client workspace. One client's engagement, documents, and conversations in one place.

Provision mode docs →
BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/)
client-acme
BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/)
client-globex

one container per customer · nothing bleeds between accounts

Your org · one agent, many cases

Beta

A case per matter

For repeatable processes: every case runs the same playbook, so the work is about adherence. The agent opens an isolated case per ticket, return, or claim, and writes pin to the policy version it saw.

Returns agent. The same refund policy for every request, a case per return.

Claims processor. Every document and decision stays in its claim, retained after close.

Case containers docs →
BotttsPablo Stanleyhttps://bottts.com/https://bottts.com/Remix of „Bottts” (https://bottts.com/) by „Pablo Stanley”, licensed under „Free for personal and commercial use” (https://bottts.com/)
client-acme shared playbook
case:ticket-4812 case:ticket-4820 case:deal-118

one parent, isolated cases · the playbook shared underneath

Privacy & security

Privacy is a substrate property.

Before an agent touches production data, a CISO asks four questions. Wire answers them in the substrate, not in controls your code bolts on top.

What can it access? Isolated.

Each container is its own permissioned environment. A connected agent only ever sees what it has been scoped to.

Who authorized it? Permissioned.

Scoped credentials with tool allowlists. RBAC on every read and write. Nothing escalates.

Can you prove it? Auditable.

Every access on the record: who read what, when, and on whose authority.

Can you revoke it? Revocable.

Pull a credential and the access is gone. No standing keys to hunt down.

Every inbound write is scanned for prompt injection before it is stored, and customer content is never used for training. Need a DPA, a security review, or deployment options for a regulated buyer? Talk to us.

Regulation is coming for agent decisions

If an agent decides something about a person, you must show what it saw and why.

Automated-decision rules in the EU, Colorado, and California all converge on the same demand. You cannot prove that on context you do not control and cannot see. Wire's disclosure trail is built for exactly that question: every access logged with the agent and the authorizing user, tied to the context that was served.

Common questions

How does the connect flow look in practice?
Your app calls the SDK to start the connect flow. The person whose context is being used sees a short code in a browser tab, picks an existing container or creates one, and confirms. The SDK call resolves with a scoped MCP endpoint and key for your agent to use through MCP or the REST API.
Does the container owner need a Wire account?
In connect mode, yes: that is what keeps your product out of the data-handling business, and anyone can spin up a container in seconds and claim it later, so first-time friction is small. In provision mode, no: your organization owns the containers, and your customers never touch a Wire account.
What does my agent end up storing?
Only what you choose to. The SDK is stateless and hands you the connection details once. Persist whatever fields you need wherever you keep your own state.
What does this cost me as the builder?
Nothing for the SDK itself. In connect mode, Wire bills the account that owns the container being used, which is your user. In provision mode your organization owns the containers, so usage bills to you, per end client, and your customers never see Wire at all.
Can the same container be used by multiple agents?
Yes. That is the point. One context layer can power many agents, so the people behind a container do not have to set their context up again every time they pick up a new tool.
We create containers from our backend, not through end users. Is that supported?
Yes. That is provision mode: register an agent, generate an org API key, and your backend creates and manages containers in your own organization. No consent screen, no end-user Wire account, one bill: yours. Your whole team sees provisioned containers in the dashboard, attributed to the agent that created them.
How do I keep one customer's tickets or sessions separate from another's?
Open a case for each one. Cases are isolated working spaces inside a container: every case reads the same shared context from the parent, writes stay in their own case, and no case can see another. The case is created the first time an agent connects to it, using an id from your system. Case containers are in beta.

Learn more

Context engineering for production agents.

Article

Why MCP failures are a context engineering problem

New research analyzed 3,282 MCP bug reports across GitHub. The patterns reveal a context delivery problem, not a protocol problem. Here's what it means.

Article

Why multi-agent AI systems fail at context

Up to 86.7% of multi-agent AI runs fail. Most failures trace back to how agents share context, not the agents themselves. Here's why and how to fix it.

Article

Why every agent handoff corrupts your context

Every multi-agent handoff is a lossy compression event. Learn which five types of context degrade at agent handoff boundaries and how to preserve them.

Add Wire to your agent

Spin up a container. Wire the agent in.

Spin Up a Container Book a Demo

Already convinced and want the SDK? Build with Wire →