Context Management
In agentic development, documents, rules, prompts, ADRs, skills, task history and review notes are not a side archive. They are context, constraints and memory for humans and agents.
Context Management replaces the old Docs framing: Agent Studio separates project-level context from task-level context and makes both useful for agent runs, review and drift control.
Project Context
Before an agent can do useful work, the project explains itself: what it is, how it is built, which rules matter and which decisions stay load-bearing.
Project context is the stable material that guides every agent run in a repository: README, AGENTS.md, architecture records, ADRs, security history, product notes, operating rules and the docs that are visible in chat. This context keeps the workbench aligned with the product instead of each task rediscovering the same rules.
This is why context management is not a docs feature in the old sense. It is an operating layer. It tells a coding agent what kind of system it is inside, what kind of changes are welcome and which trade-offs already have history.
For a human reviewer, the same material reduces review cost. If the architecture records, project rules and security assumptions are close to the task, the reviewer does not have to reconstruct the entire product from memory before making a decision.
Project context is the product speaking before the next agent run starts.
- README, AGENTS.md and setup notes define how the repository is approached.
- Architecture records, ADRs and decision logs explain which constraints must survive code changes.
- Security history, project settings and quality rules describe what a safe result must respect.
- Chat-relevant documents are selectable and visible instead of hidden in folders.
Task Context
A task needs less context than a whole project, but it needs the right context with much sharper boundaries.
Task context is the live packet around a concrete task: prompt, scope, selected agent, protocol, history, Git state, screenshots, code-review notes, security findings and acceptance decision. It is what lets a small slice be executed by an agent and still reviewed like real software work.
The task is where intent becomes work. The prompt describes the intended change, the scope says where work is allowed, the protocol records what the agent did and the evidence shows why the outcome is trustworthy.
This is also the place where follow-up work becomes natural. If the run is incomplete, unsafe, visually wrong or architecturally weak, the next task comes from the task context instead of from a vague conversation.
A good task is small enough to finish and rich enough to review.
- The task prompt and scope describe what the agent may change and what done means.
- Run history, protocol and logs explain what actually happened during execution.
- GitHub/Git state, screenshots and review findings become task-level evidence.
- Task context feeds follow-up tasks instead of disappearing after a run.
Quality-gate task detail from a pinned DEMO-9 task.
Context Sources
Context only helps when it is visible at the moment where work is planned, executed and accepted.
The workbench makes README files, agent instructions, ADRs, prompts, skills and review notes visible where work is planned and accepted. That reduces context loss and makes current rules inspectable.
A repository can contain excellent knowledge and still fail as agent context when that knowledge is scattered. The product surfaces the specific documents that matter for the next run instead of forcing the user to remember every file path.
Agent Studio is not only tracking tasks. It makes the written operating model of the project available to the people and agents doing the work.
- README and setup material define how a project is understood from the outside.
- AGENTS.md and prompt material define how agents behave in the repository.
- ADRs and decision logs explain why the system has its current shape.
Agent Context
The same text that helps a developer reason about the system can become execution material for a coding agent.
Agent runs use context to decide what matters, where to work and how to verify the result. Bad context becomes bad execution. Good context becomes a production asset because it makes repeated agent work cheaper and more reliable.
Documentation is no longer only something a team reads after the fact. In an agentic workflow, it actively steers production, review and repair.
That changes the value of keeping context clean. Stale docs are not just a communication problem. They can become bad instructions, wasted tokens and weaker review decisions.
In agentic software work, stale context is a production defect.
- Project rules are readable by both humans and agents.
- Stable prompts and skills can encode repeated work patterns.
- When agents change behavior, the context that guided them is easy to inspect.
Project and Task History
The product needs to preserve what happened without turning every run into an unreadable archive.
History is not one generic transcript. Project history shows how architecture, security, quality rules and operating assumptions evolved. Task history shows how a single implementation slice moved through agent execution, review, evidence and acceptance.
Project history is slow and structural. It explains why the repository has its current shape. Task history is fast and operational. It explains what happened inside a specific agent run and why the result was accepted or rejected.
Both are useful, but they answer different questions. Mixing them creates noise. Separating them gives humans and agents a cleaner way to find the right memory.
- Project history helps reviewers understand why a rule, ADR or architecture record exists.
- Task history preserves prompts, runs, review decisions, screenshots and follow-up work.
- History answers what changed, why, by whom and with which evidence.
Queryable Job History
A task ledger becomes much more valuable when humans and agents can ask what happened before the next run starts.
Agent Studio history should become an inspectable product feature: jobs, task prompts, agent decisions, logs, evidence, review notes, branches and follow-up work are not only archived. They can be searched, filtered and summarized through the API.
This changes the value of history. A coding agent can inspect job history with ordinary file search, API calls and targeted reads before it needs an expensive model pass. It can answer: when did we make this decision, which task introduced this behavior, what did the agent find, why was the result accepted and which follow-up remained open?
The next layer is aggregation. Small or cheaper models can summarize historical slices, cluster recurring decisions and prepare compact context for a stronger agent. The product does not merely remember; it turns task history into reusable project intelligence.
History becomes a product feature when it can answer why the software is the way it is.
- The API should expose jobs, status, evidence, decisions and review notes as queryable product state.
- Agents can use grep, file search and narrow API reads before spending tokens on broad reasoning.
- Mini-model summaries can aggregate old task history into compact context for new work.
- Past agent decisions become explainable inputs for future review, debugging and planning.
Activity across projects: a queryable ledger of signals, decisions, and actions with per-project and event-class filters.
Context Workers
Context management is too important to depend on one developer manually remembering every document after every change.
Agent Studio can treat context work as real work. Dedicated workers can collect architecture records, detect stale docs, prepare chat context, summarize review findings, check AGENTS.md alignment and turn missing context into follow-up tasks.
This is where the product becomes more than a viewer. A worker can inspect whether a change updates AGENTS.md, whether an architecture note is now stale or whether the next chat requires specific project material in context.
The goal is not to automate judgement away. The goal is to make the missing-context question visible early enough that the human can decide with less cognitive load.
Context work is software work when agents use that context to build the next change.
- Architecture workers keep records and ADR references aligned with implementation work.
- Quality and security workers turn findings into context that future tasks can use.
- Chat-preparation workers make the right project material available before a discussion starts.
Context Review
A feature can be technically correct and still leave the surrounding product knowledge behind.
A product change can invalidate docs, prompts, marketing, examples, onboarding or review rules. Agent Studio can surface that question during review instead of leaving it for later discovery.
This is the bridge between context management and software quality. When code changes, the reviewer can ask whether the written contract changed too. If it did, the product turns the repair into follow-up work.
That makes context review part of the normal loop: implement, collect evidence, review the code, review the context, then accept or create a follow-up task.
- Review aspects can include context impact.
- Drift reports can point to stale product statements and missing pages.
- Follow-up tasks turn context repair into the same task workflow as code work.