What is context engineering?
Context engineering is the practice of deciding what an AI model sees while it works on a task: which instructions, documents, data, tools and history go into its context window, in what form and at what moment. Prompt engineering tunes the wording of one request; context engineering designs everything around it.
For AI coding agents, the most valuable context is rarely more code. It is what the code cannot tell them: what the system is supposed to do, what the team’s words mean, which boundaries matter and why past decisions were made.
Why AI coding agents lose context
- Context windows are finite. An agent cannot read the whole codebase and every document at once, so it reasons from whatever it happened to load.
- Prompts don’t persist. The context someone pasted into yesterday’s session is gone today, and a colleague’s agent never saw it.
- Docs drift. Wiki pages and READMEs describe the system as it was, and an agent cannot tell which parts are still true.
- Code shows what, not why. It reveals current behavior, bugs included, but not the intended rules or the reasoning behind them.
The result is an agent that confidently builds the wrong thing, or builds the right thing with the wrong names in the wrong place.
The project context AI agents actually need
From prompt stuffing to context on demand
Instead of pasting documents into every prompt, an agent connected to SpecsGraph pulls exactly what the task needs through MCP read tools:
Because the context is structured, an agent asks for the Orders context or for requirement ORD-12 directly, instead of searching prose and hoping. The MCP tool reference lists every tool.
AI agent context management for a whole team
Context engineering usually happens one developer and one session at a time. SpecsGraph makes it shared:
- One source for every agent. Claude Code, Cursor, GitHub Copilot and any MCP client read the same approved model, which is what makes AI agent collaboration work.
- Reviewed before it counts. Context changes arrive as proposals, so a hallucinated rule never becomes something the next agent trusts.
- Versioned like code. Every revision is a Git commit, so you can see what the agents were told at any point and why it changed.
- Scoped by design. Bounded contexts keep the context of each task small and relevant, instead of pouring the whole system into the window.
Put it into practice
Tell agents to use the shared context at the start of every session. Many clients read AGENTS.md at the repository root; Claude Code reads CLAUDE.md, which can import it.
## Shared context lives in SpecsGraph
Requirements, domain terms and design decisions for this repository are in
SpecsGraph, available through the `specsgraph` MCP server.
Before you change behavior:
1. Read the affected context with get_context and the requirements you touch.
2. Use the words from list_glossary_terms, in specs and in code.
3. Check list_decisions before you reverse an earlier choice.
When behavior changes, propose the spec change in SpecsGraph and cite the
requirement ID (for example ORD-12) in your commit message.Working well with agents has the full version and example prompts, and Connect an agent sets up the MCP connection in four steps.