Context Engineering in Cursor: What Its Agent Sees, and How to Change It

Context engineering with Cursor means deciding, for each piece of information, which of Cursor’s mechanisms should carry it into the agent’s context window, and when. Rules that must always hold go in an Always Apply rule or AGENTS.md, and cost context in every chat. Rules for part of the codebase go in rules scoped with globs, loaded only when matching files are in play. Procedures go in skills, which cost a line until used. Heavy reading goes to subagents, which return a result instead of the files behind it. What one request needs comes from @-mentions or the agent’s own search. Files the agent should never see go in .cursorignore. And the state of the work lives outside Cursor altogether, so the next chat, or the next tool, can pick it up.

The general idea is in context engineering for AI agents, and the rule types themselves in Cursor rules for AI projects. This post is about the budget: what each Cursor lever puts in the window, and what it keeps out.

Look before you change anything

Cursor shows you the window. According to its guide to prompting the agent↗ (opens in a new tab), the context ring next to the prompt input shows how full it is, and clicking it opens a breakdown by category: system prompt, tools, rules, skills and the conversation. Check it at the start of a fresh chat in your project. If rules and tools already take a large share before you have typed anything, that is the first thing to cut, because it is paid again in every chat.

Rules: the part you pay for every time

An Always Apply rule is included at the start of the model’s context in every agent chat. So is AGENTS.md, and so is a root CLAUDE.md: Cursor’s rules help page↗ (opens in a new tab) says CLAUDE.md files are always applied to every conversation, regardless of any alwaysApply setting. That catches out repositories shared with Claude Code. A long CLAUDE.md written for Claude is also a long always-on rule in Cursor, so keep it lean or move Claude-only material into files Cursor does not read.

• Always on: what a newcomer needs on day one. Build and test commands, where things live, what must never be touched.
• Scoped with globs: conventions for one area, such as migrations or the mobile app. They load when a matching file is in context, and cost nothing otherwise.
• Apply Intelligently: a rule with a good description the agent can pull in when it judges it relevant. Write the description as a trigger (“use when changing the payment flow”), not a title.
• Manual: a rule you attach with @ when you want it. Nothing loads until you ask.

Rules reach the agent only. They do not affect Tab, Inline Edit or Bugbot PR reviews, so a convention that matters for completions has to be visible in the code itself.

@-mentions: context for this request only

Mentions are the per-request lever. The current set is Files & Folders, Terminals, Chats, Commit (Diff) for uncommitted changes or a branch diff, and Browser. Cursor’s own advice is simple: mention files when you know which are relevant, and skip it when you do not, because the agent finds files through its own search.

• Name the two files that matter rather than a folder of forty. A folder mention is a lot of text to attend to.
• Use @Terminals for the one failing run, rather than pasting a scroll of output.
• Use @Commit (Diff) when you want a review of what changed, so the agent reads the diff rather than whole files.
• Use @Chats to carry a previous conversation into a new one. It lets you start clean without starting from nothing.

Search, and the files it should never see

When you mention nothing, the agent searches. Cursor’s page on search↗ (opens in a new tab) describes Instant Grep, a search engine that builds and queries its index on your machine, and says Cursor does not upload file paths or code to build a search index or store embeddings of your codebase for search. The same page describes an Explore subagent the agent can send off to search many files in parallel, returning summarised findings instead of raw contents.

What you control is what search, and everything else, may reach. Cursor already skips what .gitignore excludes plus a default list: lock files, .env files, build folders such as node_modules/ and .next/, binaries and caches. For the rest, add a .cursorignore at the root, in .gitignore syntax.

# generated code that keeps turning up in answers
src/generated/
*.snap
# fixtures with realistic-looking data
test/fixtures/customers/
# vendored copy nobody edits
vendor/

Two limits are worth knowing. Cursor’s ignore file reference↗ (opens in a new tab) says ignored files are blocked from the agent, Tab, Inline Edit and @-mentions, but the terminal and MCP tools the agent uses cannot be blocked from them: a cat in the terminal still reads the file. So .cursorignore is a context lever, not a security boundary. And a ! negation cannot re-include a file whose parent folder is excluded; exclude the folder’s contents instead and re-include the one file.

Long chats are summarised

As a chat fills the window, Cursor compresses older parts of the conversation into a summary to make room. Anything you said only in chat is subject to that: an instruction from the first ten minutes may survive as a sentence or not at all. Two habits follow. Put anything that must last all session in a rule or a file, not in a message. And when you move to unrelated work, start a new chat and bring across only what you need with @Chats.

Plan mode: a plan the next chat can read

Plan Mode, reached with Shift+Tab, has the agent ask questions, research the code and write a plan you can edit before anything is built. For context engineering the useful property is that the plan is a Markdown file, saved in your home directory by default, and Save to workspace moves it into the project. A plan in a file survives summarisation and can be referenced from a fresh chat. Cursor also suggests that when the agent goes wrong, going back to the plan and refining it usually works better than a string of fixes in the same conversation.

Subagents: read a lot, return a little

A subagent works in its own context window and returns its result to the agent that called it, so a long search or a noisy command does not fill the main conversation. Cursor’s subagents documentation↗ (opens in a new tab) lists three built in: Explore for searching the codebase, Bash for isolating verbose command output, and Browser for filtering noisy page snapshots. Your own go in .cursor/agents/ for the project or ~/.cursor/agents/ for you.

---
name: test-runner
description: Runs the test suite and reports only failures. Use after any code change.
model: inherit
readonly: true
---
Run pnpm test. Report the failing test names, the assertion message and
file:line for each, and the final summary line. Never paste passing output.

The last line of the prompt is the context decision: it defines what comes back. A subagent that returns the whole log has saved nothing.

Skills: long procedures that cost almost nothing

A skill is a folder with a SKILL.md, in .cursor/skills/ or .agents/skills/ for the project, with legacy support for .claude/skills/. According to Cursor’s skills documentation↗ (opens in a new tab), only the description sits in context until the agent decides the skill is relevant or you call it with /. Set disable-model-invocation: true and it loads only when you call it by name. That makes skills the right home for a release checklist or a migration recipe: text you need twice a month should not ride along in every chat as a rule.

MCP servers: every tool is a description

MCP servers live in .cursor/mcp.json for the project or ~/.cursor/mcp.json for you. Each tool a server offers is a description the model reads, and each result it returns lands in the conversation. Switch off servers a project does not use from the Customize sidebar, where a disabled server does not load or appear in chat, and prefer servers whose tools return short, filtered answers. Cursor asks before running an MCP tool by default, which also gives you a look at what is about to come back into context.

Cloud agents start from the repository

Cloud agents, formerly called background agents, run in isolated virtual machines, clone your repository, work on a branch and push it. Moving a local chat to the cloud↗ (opens in a new tab) carries its conversation history and context, but not uncommitted edits: the agent starts from what is committed to the repository it clones. It also reads your user rules, your team’s rules and the project rules in the repository, and it can use the MCP servers your team has configured plus any personal ones you add. But your user rules follow only your own agents, and a chat only the agent you hand it to; what is committed reaches every cloud agent anyone starts on the repository. That is the strongest argument for keeping lasting project context in committed files, AGENTS.md and .cursor/rules, rather than in user rules or in chat.

Keep the state of the work outside Cursor

None of these levers is a good home for what is in progress, what was decided, or what the last chat could not finish. Rules are for things that rarely change; chats are summarised and eventually closed; a plan file describes one change. Put the work on a board the agent reads over MCP. With fenbs connected to Cursor, one Always Apply line (“start by calling fenbs_get_context, then read the task you are given with fenbs_get_item”) gives every chat, local or cloud, the AI context notes people and earlier assistants left, and the task’s problem, plan and comments, at the cost of two tool calls. When the agent learns something the next one needs, fenbs_add_context_note records it on the board, signed with its name, instead of in a chat that will be summarised.