Case Containers

Case containers give an agent a private working space for each thing it handles, a support ticket, a customer, a session, while every case reads the same shared context from its parent container. The parent holds what is common: policies, runbooks, product knowledge. Each case holds what belongs to one matter, and no case can see another.

The pattern is the same across very different agents:

Agent	The parent holds	A case is
Appointment setter	The pitch, objection-handling playbook, and scheduling rules	One prospect. The thread’s history, objections, and scheduling state stay with that prospect, so a hundred parallel conversations never blur together.
Returns agent	Return and refund policies	One return request. The agent records the customer’s details, checks them against policy, and the case closes when the refund is decided.
Claims processor	Underwriting guidelines and coverage rules	One claim. Every document and decision the agent handles stays in that claim, retained for years after it closes.
Events manager	The event itself: venue, schedule, FAQ	One guest. Their RSVP, plus-ones, dietary notes, and questions live in their case, and every guest gets answers from the same event details.
Office pizza agent	Dietary preferences, the budget, the vendor shortlist	One week’s order. Who’s in, the vote, what got ordered. Next Friday starts a fresh case with the same standing knowledge.

In every shape, the agent searches from inside the case and gets merged results, the case’s own record plus the relevant shared knowledge, and each result says which of the two it came from.

Beta

Case containers are in beta and available on containers running the new runtime.

Enable cases on a container

1. Open the container in the Wire dashboard
2. Go to Settings → Case Containers
3. Turn on the toggle and pick a default retention

Turning the toggle off later blocks the creation of new cases only. Existing cases keep serving, and you can still close, reopen, or delete them.

How agents open a case

The clean way to run cases is the Wire SDK in provision mode: your backend provisions the parent container with an org API key and gets back its endpoints, and your agents derive each case’s endpoint from them. That keeps container creation, credentials, and case routing in code instead of hand-assembled connection strings.

A provision agent can only reach containers it created, so provision the parent through the agent, then let your team review and fill it from the dashboard, where provisioned containers are fully manageable. Access follows the agent, not any single key: if a key is lost, issue a new one on the same agent and it reaches all of that agent’s containers and cases.

A case is created the first time an agent connects to it. There is no separate create step. Add /s/ and your case id to the container’s MCP URL (the mcpUrl the SDK returns):

The case id comes from your system: a ticket number, an order id, a session id. Reusing the same id reconnects to the same case. The REST API works the same way, with /s/YOUR_CASE_ID between the container id and the tool path.

Authentication is unchanged. The same keys and OAuth flow that reach the container reach its cases.

Note

Generate one case id per matter, not per request. A fresh id on every request creates a new case each time, and creation is rate limited to catch exactly that mistake.

What agents see inside a case

• Writes stay in the case. Anything the agent writes lands in the case, never in the parent.
• Reads merge both. Search and explore return case entries and relevant shared context together. Every result says where it came from, so the agent can weigh case facts against shared knowledge.
• References are pinned at write time. When an agent writes into a case, Wire links that entry to the most relevant shared context as it stood at that moment. Navigating from the entry later surfaces those references, including the policy version the agent actually saw, even if the policy has since been superseded.

For the reference trail to stay meaningful, treat the parent as append-only: when a policy changes, write the new version as a new entry rather than deleting the old one. Wire links the versions, and agents get both the policy as it was and the policy as it is.

Case lifecycle

A case is Active or Closed. Close a case from the dashboard (or your system can stop using it and let it close on idle). Closed cases reject agent traffic until reopened, and their data is handled by their retention setting:

Retention	What happens
Keep until deleted	Idle cases close; their data stays until you delete it
Auto-delete when idle	Idle cases close and their data is removed
Keep 1 year / 7 years	Closed cases are kept for the window, then removed

The default retention applies to new cases; you can change it per case in the table. Deleting a case that is still inside a retention window asks for an explicit override, and the override is recorded in the container’s activity feed.

Costs

Case entries count toward the parent container’s storage like any other entries, and agent tool calls from inside a case are billed like calls to the container itself. Opening a case is free.