Sharing context with a capsule

What a capsule is

A packaged, scoped bundle of context behind one URL: the decisions, the relevant code, the thread — enough to pick up where you left off.

Not a transcript. The recipient gets working context. Point another agent at the link and it starts with what you had, without you re-explaining anything.

It can represent one session, one project, or a workspace. It can be a fixed snapshot or a live capsule that refreshes from its source. Large capsules do not have to dump everything into the first response: a recipient can inspect a primer and load only the sections needed.

Where it earns its keep

Handing off. Going on holiday mid-migration. The capsule is what the covering person needs, and it takes a sentence to make.

Onboarding. A new person gets the context of one area rather than access to everything.

Briefing another agent. A different assistant, or a colleague's agent, needs your context for one task. A capsule is the scoped bundle it can open.

Talking to someone outside. A contractor or a support engineer needs the context of one problem, not your workspace.

Returning to your own work. Make a self-only snapshot before a risky change or a long break, with no share link at all.

Reviewing a change. Package the plan, decision, relevant code context, and open questions so the reviewer starts at the reasoning rather than the diff alone.

Choose the recipient and purpose

A capsule can be prepared for:

• only you;
• authenticated workspace members;
• an external agent;
• a controlled public link;
• support;
• a public-safe bootstrap link.

Its purpose can be onboarding, handoff, snapshot, debugging, review, bootstrapping a new agent, or another named use. Purpose is not just a label: it makes the expected audience and contents easier to audit later.

Scope, code, redaction, expiry, and revocation

Six controls matter:

• Scope — what's in it. One session, one project area, one topic. Narrower is better.
• Code inclusion — none, loaded only when requested, or included inline.
• Personal material — excluded unless the share policy deliberately allows it.
• Redaction — external links use conservative defaults.
• Expiry — it stops working on its own.
• Revocation — kill it early, any time.

That last one is the difference from an export. An exported markdown file is out there forever.

When your connected assistant creates a share through the production MCP, it fills in a safe policy when you did not specify one:

• External-agent, public, and support links default to three days, single-use, read-only access, strict redaction, no personal material, and no code. A short grace window lets one consuming agent finish parallel reads after the first open.
• Authenticated team links default to seven days and multiple uses. Their authenticated policy can include personal context and make code available on demand.
• Public-safe bootstrap links default to 14 days and multiple uses, but remain a strict primer with personal material and code excluded.

Creating a session capsule through the MCP also mints a safe external-agent share by default. Ask for a self-only audience when you want the capsule without any share link.

The dashboard offers task-specific presets instead: external-agent and one-off support shares default to 24 hours and one use, a public read-only URL defaults to 24 hours and multiple uses, and an authenticated team link defaults to seven days and multiple uses. Those dashboard presets use standard redaction while still excluding personal material and code from external shares.

Either path can return a more specific policy than the request, so inspect the returned audience, expiry, redaction, code setting, and use limit before sending the URL. Override a safe default only when the recipient actually needs the additional material.

External shares can be single-use, reusable until expiry, or capped at a specific number of opens. Risky settings—personal material, inline code, little redaction, or a long-lived external link—require an explicit opt-in rather than slipping through as defaults.

Build a support capsule on purpose

A customer reports repeated sign-outs and support needs enough context to investigate. Start with a project-scoped debugging capsule containing:

• the customer-safe incident summary and visible impact;
• the screenshot with the provider error;
• the current auth decision and the relevant runbook section;
• the narrow code catalog needed to locate the refresh path;
• the open question support is being asked to answer.

Leave out personal transcripts, environment values, credentials, internal customer identifiers, unrelated accounts, raw debug logs, and internal-only tickets. Use on-demand code rather than inline code unless the recipient must see exact source. Preview the context document, confirm the redaction summary, then send the external URL—not the authenticated dashboard URL.

The recipient can load the screenshot or relevant section when needed and acknowledge what was read. If the link is opened by the wrong process first, a single-use share may be consumed; revoke it and create a new narrow share rather than widening the old policy.

Making one

Ask your connected assistant: "create a capsule for this so I can send it to Sam." Name the intended session, project, or topic when the current scope would be too broad.

A session capsule mints an external-agent share by default — a link safe to give to something that isn't you.

What a recipient can inspect

A capsule can expose a readable context document, a paste-ready bootstrap prompt, and three graph views: an explorer map, a knowledge graph, and a code graph. A recipient can stream or load individual chunks instead of hydrating the whole package.

The sender can inspect the share history and audit trail. A consuming agent can acknowledge which sections it read and attach a note. That turns “I sent the link” into an inspectable handoff rather than an assumption that the important part was seen.

Compare and refresh

You can compare two capsules to see what changed between snapshots. A live capsule can refresh when stale, and a recurring capsule can be scheduled for cases such as a weekly project briefing. Scheduled capsules can be listed or removed without deleting unrelated shares.

Use a fixed snapshot for an incident, review, or historical handoff where the exact state matters. Use a live or scheduled capsule when the recipient needs an updating view.

Capsules and handoffs

A handoff is the workflow record: who, what, current state, open questions, next steps, and completion status. A capsule is the context bundle. Use both when someone is genuinely taking over; use the capsule alone when they only need to see what you see.

Capsules and exports

A capsule is curated for a purpose and protected by a share policy. A large export is a paged data job over transcripts, decisions, lessons, or documents. Do not use an export as a substitute for a narrow external share.

If it doesn't work

The link doesn't work for them. It expired, reached its use limit, or was revoked. Ask to list your capsules and shares, then make a new one if needed.

It contains more than I intended. Scope narrower — one session or one topic, not the project. Exclude personal material and code unless the recipient needs them.

They can see it but their agent can't use it. They need to give their assistant the Agent URL rather than open the Dashboard URL in a browser.

It is too large to open at once. Start with the primer or context document, then load the relevant section or chunk.

A scheduled capsule is stale. Check whether the schedule still exists and whether its source workspace or project remains accessible.

Next

• Working as a team
• Handoffs
• Past sessions