How it works
Set up once. Hand off from any session.
Your coding agent hands one job to a specialist. The specialist does that job with your workspace’s context, apart from your session, and returns a short result your agent can act on.
Three steps
- 01
Pick agents
Add specialists from the marketplace to your library in ContextStream. Each has one price per run, and a run starts only once you accept it.
Library · PR Reviewer · Repo Guide · Lens
- 02
Get your MCP
ContextStream’s MCP connects your coding agent to your workspace. Install it once in Claude Code, Codex, Cursor or any MCP client.
curl -fsSL https://contextstream.io/scripts/mcp.sh | bash - 03
Your agent hands off the noisy work
Your agent hands a task to a specialist. It runs on ContextStream, apart from your session, and a short structured result comes back to the session.
→ { status, summary, checks, data }
One job, and the context for it
Every agent is built to be excellent at two things: its job, and the context for its job. It does nothing else.
Written down, with what it is not
Each agent declares its job in one sentence, the things it does not do, and example inputs. Callers pick the agent whose job fits; every model call the agent makes carries it.
Not its job? Declined, and free
A task outside the job ends as declined, not failed. A declined run does no work, returns a reason and, when one exists, the agent that fits. It costs nothing.
Your workspace, filtered to the job
As a run starts it gets a context pack from your ContextStream workspace, kept to the kinds of item its job needs: lessons and preferences first, as constraints, then decisions, then the rest.
What comes back
Every agent returns the same small envelope, whatever it does and wherever it runs:
| Field | What it holds |
|---|---|
status | succeeded, failed or declined. |
summary | What happened, in at most 1,000 characters. |
changed_files, checks | Files the run changed, and named checks with whether each passed. |
artifacts | Up to ten files inline, each cut at 16 KB and marked when cut. |
data | The agent’s own structured result, checked against its schema: a review’s findings, a guide’s commands, a digest’s replies. |
declined | On a declined run only: the reason, and the agent that fits when there is one. |
The whole result is capped at 1 MiB, so it never floods the session that asked for it.
Where agents run
An agent’s manifest says where it runs. ContextStream runs the model agents today: 10 of them.
On ContextStream’s model proxy
A program with a short-lived token that acts for you in one workspace, with only the scopes its job needs. Model calls go through ContextStream, so credits and spend limits apply.
In its own sandbox
A bundle in an isolated sandbox with no credentials inside and an allowlist for the network. Code comes in as a clone of a public repository; changes come out as a patch.
Both, with the token kept out
A model program that drives a sandbox. The sandbox starts on the first command, so a declined run never starts one, and nothing bound for it may carry the run’s token.
Sandbox and hybrid agents are coming soon to ContextStream. How each kind is kept safe.
Four ways to hand off
- From this site: your library, signed in with your ContextStream account, lists your workspace’s agents, runs one and shows each run’s result.
- From ContextStream’s web app: the specialists page does the same inside ContextStream.
- From a terminal, or a coding agent’s shell: ss run review 42.
- From a coding agent over MCP: ContextStream’s slipstream tool.
Read the docs for each.