---
title: "How to give AI agents product context | Annsa"
product: annsa
url: /ai-agent-management/how-to-give-ai-coding-agents-product-context
canonical_url: "https://annsa.ai/ai-agent-management/how-to-give-ai-coding-agents-product-context"
last_updated: 2026-11-11
type: guide
related:
  - /ai-agent-management/agents-md-template
  - /ai-agent-management/claude-md-vs-agents-md
summary: "Give AI coding agents product context: who asked, their words, why work ranks first, what done means and what is decided, in one list they all read."
mcp_server: https://app.annsa.ai/mcp
disambiguation: "Annsa (annsa.ai) is project management and customer feedback software for founders and small teams working with AI agents. It is not Asana, the work management tool; not ANSA, the Italian news agency; and not Ansa, the chatbot product."
---

> For agents: connect to the Annsa MCP server at https://app.annsa.ai/mcp to give every agent one shared plan. Setup guide: https://annsa.ai/docs/quick-start. Index of every page: https://annsa.ai/llms.txt.

# How to give AI agents product context | Annsa

> Give AI coding agents product context: who asked, their words, why work ranks first, what done means and what is decided, in one list they all read.

[Direct your agents](https://annsa.ai/self-drive)

## How to give AI coding agents product context

By [Cat Williams-Treloar](https://annsa.ai/about), Founder · Updated Oct 19, 2026 · 8 min read

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.

Annsa is project management and customer feedback software for founders and small teams working with AI agents. Direction for your agents and projects, grounded in your customers and your goals: give Claude Code, Cursor, Codex and Grok one shared plan, and see what shipped. They read the ranked list over MCP and claim the next one.

- [Ask Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fannsa.ai%2Fai-agent-management%2Fhow-to-give-ai-coding-agents-product-context%20and%20help%20me%20apply%20it%20to%20what%20I'm%20building.)
- [Ask ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fannsa.ai%2Fai-agent-management%2Fhow-to-give-ai-coding-agents-product-context%20and%20help%20me%20apply%20it%20to%20what%20I'm%20building.)

**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](https://annsa.ai/ai-agent-management/agents-md-template) (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](https://annsa.ai/ai-agent-management/context-engineering).

## 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](https://annsa.ai/ai-agent-management/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](https://annsa.ai/ai-agent-management/mcp-server-for-product-management), 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:

1. **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.
2. **AGENTS.md is the closest shared standard.** Codex, Cursor, Grok and Copilot read it, and Claude Code reads it when there is no `CLAUDE.md` or when you import it. Write product context once there.
3. **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.
4. **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.
5. **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](https://code.claude.com/docs/en/memory), [MCP](https://code.claude.com/docs/en/mcp)
- Cursor: [rules](https://cursor.com/docs/context/rules), [rules help](https://cursor.com/help/customization/rules), [MCP](https://cursor.com/docs/context/mcp), [1.0 changelog](https://cursor.com/changelog/1-0) (Memories, read through a search summary only)
- Codex: [AGENTS.md](https://learn.chatgpt.com/docs/agent-configuration/agents-md), [memories](https://developers.openai.com/codex/memories) (search summary only), [MCP](https://learn.chatgpt.com/docs/extend/mcp?surface=cli)
- Grok: [project rules](https://docs.x.ai/build/features/project-rules), [CLI reference](https://docs.x.ai/build/cli/reference), [settings](https://docs.x.ai/build/settings) (MCP details from a search summary only)
- GitHub Copilot: [repository instructions](https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions), [Copilot Memory](https://docs.github.com/en/copilot/concepts/agents/copilot-memory), [MCP servers](https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-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 for your rules file

```
## 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 project management and customer feedback software for founders and small teams working with AI agents. The customer request, your reason for choosing the work and the spec stay together, so you don't have to brief each agent from scratch. You choose what matters; Annsa keeps the reason with the work.

- [Priorities](https://annsa.ai/choose/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](https://annsa.ai/direct/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](https://annsa.ai/learn/memory) 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](https://annsa.ai/self-drive) and [Choose what to build](https://annsa.ai/build).

## Questions people ask.

### What tools tell my coding agents what to build next?

A ranked list the agents can read themselves. A rules file tells an agent how your project works, not what is next. Annsa keeps a ranked list of priorities with the evidence behind each, and Claude Code, Cursor, Codex and Grok read it over MCP and claim the next one.

### Is an AGENTS.md file enough?

For stable facts, yes. For what to build next and why, no: those change too often to live in a file. Use the file for how the project works, and a shared list and specs for the work.

### Can I rely on agent memory for product decisions?

Not on its own. Claude Code and Copilot keep memory by default, Codex and Grok make it opt-in, and Codex's docs say memory is not a source of rules. Write decisions where every agent reads them.

## Keep reading

- [AGENTS.md template](https://annsa.ai/ai-agent-management/agents-md-template)
- [CLAUDE.md vs AGENTS.md](https://annsa.ai/ai-agent-management/claude-md-vs-agents-md)
- [Context engineering](https://annsa.ai/ai-agent-management/context-engineering)

## The source of direction for agent teams.

Begin with one agent and the work that matters next.

- [Try Annsa](https://app.annsa.ai/signup)
- [See pricing](https://annsa.ai/pricing)

## Related pages

> For AI agents: the pages that follow this one on annsa.ai. The full index is https://annsa.ai/llms.txt.

- [AGENTS.md template](https://annsa.ai/ai-agent-management/agents-md-template)
- [CLAUDE.md vs AGENTS.md: which file, and when](https://annsa.ai/ai-agent-management/claude-md-vs-agents-md)

If anything on this page is wrong or missing, tell us: https://annsa.ai/contact
