We are moving development from local Claude Code to cloud agents and a software factory. What context do those agents need?
What the local developer supplied without noticing: the decisions and history behind the code, the review norms and unwritten conventions, which doc is current and who owns what, and the incident history behind each constraint. Cloud agents start from a fresh clone with no local files and nobody watching, so that context has to arrive over MCP from a context engine that mirrors source permissions.
Cloud agents need the context a local developer supplied without noticing. On a laptop, Claude Code reads the open files, the user's own CLAUDE.md and the MCP servers that engineer set up. The engineer corrects it when it drifts. A cloud agent is a coding agent that runs a task in a vendor-hosted sandbox from a fresh clone, with no access to the engineer's machine. None of that context comes with it. A software factory is an operating model in which fleets of cloud agents take tickets from plan to merged PR, while people set direction and guard quality (what is an AI software factory). The system then has to supply four kinds of context: decisions behind the code, review norms, which document is current and who owns what, and the incident history behind each constraint. The supply route is an MCP connection to a context engine that applies the source systems' permissions, not a longer prompt.
What a local agent borrows and a cloud agent does not have#
Claude Code cloud sessions "start from a fresh clone of your repository. Anything you commit to the repo is available. Anything you've installed or configured only on your own machine isn't available in the session." The user-level ~/.claude/CLAUDE.md and MCP servers added at user scope stay on the laptop. A repo .mcp.json comes along only if it is committed (Claude Code docs). The session runs in an isolated VM and keeps going after you close your laptop, so a wrong turn can go unwatched (Claude Code docs).
GitHub's Copilot cloud agent works in an "ephemeral cloud development environment." It can only change the repository named when the task starts, opens one pull request per task, and stops at 59 minutes. By default the GitHub MCP server gives it that repository's issues and earlier pull requests (GitHub Docs). Cursor's cloud agents run "in isolated VMs in the cloud," and user-level hooks are unavailable because "cloud VMs don't have access to your local home directory" (Cursor docs). Codex Cloud gives each task "its own workspace," built from an environment Codex sets up by inspecting the repository (Codex Cloud docs).
Four products, one shape: a clone, a task, a pre-configured environment, and the MCP servers someone attached.
The four context inputs a factory agent needs#
| Input | Where it lives | What the agent does without it |
|---|---|---|
| Decisions and history behind the code | Merged PRs, review threads, the tickets they closed | Retries the approach that was reverted in April |
| Review norms and unwritten conventions | Review history, plus whatever the rules file states | Uses the deprecated client; puts tests in the wrong place |
| Which document is current, and who owns what | The doc, the wiki page, and the thread that settled which wins | Follows the stale page; tags the wrong reviewer |
| Incident history and the reason behind each constraint | Incident channels, postmortems, the PR that added the guard | "Cleans up" the 30-second timeout an outage put there |
For example, when a wiki page and a design doc disagree on token expiry, a local developer knew which one the team follows, or asked. A factory agent needs that answer supplied, so it does not guess from git blame. The starting packet for an unattended run is in context for background coding agents.
How the agents get it: a context engine on MCP#
Pasting docs into the prompt fails twice over. The docs go stale, and the prompt cannot hold last month's review thread that rejected the approach the agent is about to retry. A longer prompt also costs accuracy: a March 2026 paper finds LLMs show "significant performance degradation as context length increases" (Cao et al., 2026). The alternative is a context engine attached as an MCP server inside the sandbox. A context engine is a service that indexes code history, PRs, issues, docs, chat and incidents together, reconciles them, and returns one cited answer scoped to the asking identity.
Attachment is configuration: a committed .mcp.json for Claude Code, team MCP servers for Cursor, repository MCP settings for Copilot. For headless runs, Unblocked's CLI, token-based MCP connections and REST API use an API token; a team token can be limited to selected data sources when it is created (Unblocked docs). Its context_research tool "returns a synthesized answer with citations" from "code, PRs, docs, issues, and messaging" (Unblocked docs). Access controls flow from the source, so the agent's identity sees only what it is authorized to see in GitHub, Jira, Confluence and Slack (inside the Unblocked context engine). We measured this once, on one production repository, same prompt and model: the engine run used 42 percent fewer tokens and made 64 percent fewer tool calls (same prompt, same model, different context). One run is not a population.
Webflow runs this pattern on Flower, its internal remote-agent platform, with Unblocked connected to the sandbox over MCP. Russ Nealis, Staff Technical Product Manager at Webflow: "When Flower spins up the remote agent sandbox, you can see it reaching out to different MCPs. The most exciting one is Unblocked, because at that point you can see the agent itself gets it. The model's like, 'Oh, now I have the necessary information I need to actually deliver on the ask.'"
What breaks without it#
Three failures show up early, and all three pass CI.
Re-implementation. An agent given a ticket and a clone cannot know the feature already exists, for example under another name in a nearby service. It builds a second copy, and the PR looks fine.
Convention drift. The tests pass, but the agent used the deprecated client and skipped the migration script that ships with every schema change. Each is a review comment. Across a fleet, they pile up.
Confident, wrong PRs. The agent reads the design doc, never sees the PR that overruled it after an incident, restores the old value, and explains why. A tired reviewer approves it. Attended, a wrong turn costs seconds. Unattended, it costs hours of compute and a PR built on the wrong premise. How much autonomy a fleet can take depends on the weaker of context quality and your ability to catch a wrong answer (how much autonomy to give AI coding agents).
Where to start#
Write down what the agent will know at minute zero. If the list is the ticket, the clone and a rules file, add a context engine to the sandbox's MCP configuration. Make the first step of every task an ask, before any file is read. Give the agent a token of its own, scoped to the task. The MCP spec tells clients to "follow the principle of least privilege by requesting only the scopes necessary for their intended operations" (MCP specification). A borrowed engineer session carries that engineer's full access. Then read the citations in the PR before the diff. A software factory is only as good as what its agents can find out.
