How to give AI coding agents product context
The short answer
To give AI coding agents product context, write down who asked, their words, why the work ranks first, what done means and what you already decided. Then keep it where every agent reads it. A rules file holds the standing facts; a ranked list the agents read over MCP holds the live ones.
Product context is everything an agent needs to build the right thing that is not in the code.
TL;DR
- Put stable facts in a short rules file (AGENTS.md, or CLAUDE.md for Claude Code).
- Put what changes weekly, like what to build next, in a ranked list your agents read themselves.
- Keep decisions in a checked-in file or on the work, not in agent memory.
When to use it: when more than one session or agent builds your product, or when the same background keeps getting retyped. When not: skip the shared list if one agent works one repo alone and a rules file already covers it.
What is product context for an AI coding agent?
An agent can read your code. It cannot read why the code matters. Product context is the part that lives outside the repo:
- Who asked. The person or company behind the work.
- Their words. The quote, not a summary of it.
- Why it ranks first. What it is ahead of, and the reason.
- What counts as done. Lines you can check one by one.
- What is already decided. Options ruled out, rules you set, calls made last week.
With these, an agent can pick the right job and build the right thing. Without them it builds what the ticket title says.
Why does product context get lost?
Context goes missing in three places.
- Between sessions. A new session starts from zero, so you explain the project again.
- Between agents. Claude Code, Cursor, Codex and Grok do not share a memory. What one learned, the next did not see.
- Between you and the work. The customer's words sit in Slack or a call, and the ticket keeps a one-line version.
This is not a model problem. The facts were not written down where an agent could find them.
Rules file, spec or shared list: which should I use?
1. A rules file. A short file at the root of the repo says what the product is for, how it is built and the rules that rarely change. Use it for: stable facts. Not for: anything that changes weekly, like what to build next.
2. A spec per job. One page per piece of work: the problem, what to build, the files to touch and Done When. Any agent can pick it up cold. See spec-driven development. Use it for: one job at a time. Not for: choosing between jobs.
3. A shared ranked list over MCP. One ranked list of work, with the evidence on each row and a spec behind it. Agents read it through MCP, an open protocol from Anthropic for connecting AI tools to outside data, so nobody pastes it into a prompt. Use it for: "what should the agent build next?" and for more than one agent. Not for: a single agent on a single repo with a short plan.
Most teams start with the first, add the second and end up needing the third once more than one agent is building.
How do Claude Code, Cursor, Codex, Grok and GitHub Copilot take in context?
All five read a plain markdown file you write, and all five accept remote MCP servers. They differ in file names, when files load and how memory works. This table comes from each vendor's docs as fetched on 19 October 2026. "Not documented" means the pages we read did not say.
| Rules file it reads | When it loads | Memory across sessions | MCP | |
|---|---|---|---|---|
| Claude Code | CLAUDE.md or .claude/CLAUDE.md (project), ~/.claude/CLAUDE.md (user), CLAUDE.local.md, .claude/rules/*.md. Reads AGENTS.md only when no CLAUDE.md exists, unless you import it with @AGENTS.md. | At the start of every session. Subdirectory files load on demand once Claude touches a file there. Rules with paths: load when a matching file is read. | Yes, "auto memory": Claude writes its own notes to ~/.claude/projects/<project>/memory/. On by default locally. Otherwise each session starts with a fresh context window. | Remote: claude mcp add --transport http <name> <url>. OAuth 2.0 for HTTP servers. |
| Cursor | .cursor/rules/*.mdc (plain .md is ignored), AGENTS.md, User Rules, Team Rules. Also reads CLAUDE.md. .cursorrules is legacy. | Four modes: Always Apply, Apply Intelligently, Apply to Specific Files, Apply Manually. Rules apply to Agent chat only, not Tab, Inline Edit or Bugbot. | Not documented on the rules page. A Memories feature appears in the 1.0 changelog; we found no dedicated docs page. | Remote: url and headers in mcp.json (project or global), or a marketplace button. OAuth supported for remote servers. |
| Codex | AGENTS.md (or AGENTS.override.md) in ~/.codex and every directory from the project root down to where you work. One file per directory. | Built once per run (once per terminal session; restart to pick up changes). Files concatenate root-down; closer files come later and win. | Off by default. Optional "Memories" via memories = true in config.toml. The docs say not to treat memories as a source of rules. | Remote: codex mcp add <name> --url <url>. OAuth: codex mcp login <name>. |
| Grok (Grok Build CLI) | AGENTS.md, CLAUDE.md, .grok/rules/*.md, plus .claude/rules/ and .cursor/rules/ "for compatibility". Global files in ~/.grok/. | For every session in the directory tree; deeper files win. grok inspect lists the loaded files. | Opt-in and experimental (--experimental-memory). The rules page does not mention memory. | grok mcp add exists; remote servers take a URL plus headers or a bearer token. Exact flags and MCP OAuth: not documented on the CLI reference page we read. |
| GitHub Copilot (cloud agent) | .github/copilot-instructions.md, .github/instructions/*.instructions.md with applyTo globs, AGENTS.md (nearest wins), or one root CLAUDE.md or GEMINI.md. | Repo-wide file applies to all requests in the repository; path-specific files when matching files are in play. | Copilot Memory, in public preview. Unused items are deleted after 28 days. On by default for individual plans, admin-enabled for organization plans. | Set in repo Settings as JSON. Remote servers that need OAuth do not currently work. Tools only, no resources or prompts. |
What the table says for a product builder:
- Rules files hold what you write. None of these agents learns who asked for the work or why it ranks first unless you put it there.
- AGENTS.md is the closest shared standard. Codex, Cursor, Grok and Copilot read it, and Claude Code reads it when there is no
CLAUDE.mdor when you import it. Write product context once there. - Keep the file short. Claude Code says to target under 200 lines per
CLAUDE.md. Cursor says under 500 lines per rule. Codex stops adding files at 32 KiB combined. Copilot's own prompt says no longer than 2 pages. Grok sets no cap but recommends short, specific rules. A whole priority list pasted in will crowd out the rest. - Do not rely on memory for product decisions. Claude Code and Copilot have memory on by default; Codex and Grok make it opt-in; Cursor's is thinly documented. Codex's docs say memory is not a source of rules. Anything that must hold goes in a checked-in file.
- Live product data belongs in a remote MCP server. All five accept one, with different setup: one command in Claude Code and Codex, a JSON file in Cursor, repo settings in Copilot. Rules files hold the standing rules; MCP holds the live answer.
Sources (vendor docs, as fetched 19 October 2026):
- Claude Code: memory and CLAUDE.md, MCP
- Cursor: rules, rules help, MCP, 1.0 changelog (Memories, read through a search summary only)
- Codex: AGENTS.md, memories (search summary only), MCP
- Grok: project rules, CLI reference, settings (MCP details from a search summary only)
- GitHub Copilot: repository instructions, Copilot Memory, MCP servers (search summary only)
What should I put in each piece?
| Piece | Where it lives | How often it changes |
|---|---|---|
| What the product is, how to run it, fixed rules | Rules file | Rarely |
| The problem, the plan, Done When | Spec on the job | Per job |
| What to work on next, who asked, why it ranks here | Ranked list | Daily |
| Calls you made | Saved on the work | Each time you decide |
Keep each fact in one place. A fact that lives in two will disagree with itself within a week.
What can I copy into AGENTS.md?
Paste this at the top of your rules file and fill in the brackets. Keep it under a page.
## Product context
- What this product is for: [one sentence, in your customer's words]
- Who it is for: [the person, and the job they hire it for]
- What we are working on now: [read the ranked list, do not copy it here]
- How to find the next job: [where the list lives, and how to claim a job]
- What counts as done: every Done When line on the spec has a receipt
- Decisions that hold: [3 to 5 calls you have made, one line each]
- Ruled out: [options we rejected, and why]
- Ask a person before: [scope changes, anything customers see, security]
Keep the "now" and "next" lines as pointers. Copied priorities go stale within days.
How does Annsa do it?
Annsa is AI agent management, and the source of direction for your agents. A person makes the call; Annsa keeps the reason with the work.
- Priorities is the ranked list. Each row shows who asked, what they said and why it ranks where it does.
- Each priority has one spec: problem, evidence, what to build, files to touch and Done When. You, your agent over MCP, or Ask writes it.
- An agent claims a priority before it starts. One agent holds each priority at a time.
- Decisions and rules stay on the priority, so every agent reads them before asking again.
- Agents settle routine calls by your rules, with undo. Scope, customers, a principle, a real choice or security come to you.
Claude Code, Cursor, Codex and Grok connect to the same server, so they read the same list. See Direct your agents and Choose what to build.