The pieces of context you give AI

The same model can behave very differently in two projects. The difference is usually not the model but the context it gets: does it know how to run the tests, which folders are off-limits, and what steps to follow for a certain kind of task?

Mainstream tools now support four ways to give AI context. Each has a different job, so do not mix them up.

The four pieces

Mechanism	What it covers	When it loads	Where it lives
AGENTS.md	Project-wide rules: commands, conventions, boundaries	At the start of every session	Repository root (and optionally subfolders)
Rules	Rules for specific folders or file types	When matching files are involved	A tool-specific folder, such as .cursor/rules/
MCP	External capabilities: browsers, databases, docs search	When the agent calls them	The tool's MCP config file
Skills	How to do a kind of task: steps, scripts, templates	Full text only when a task matches	A folder containing SKILL.md

How to divide the work

• Write AGENTS.md first. Nearly every tool reads it, so it is the highest-leverage file you can add. Keep it short and concrete: commands, conventions, boundaries.
• Rules only hold what AGENTS.md cannot. For example, "files under tests/ follow this pattern", or behavior specific to one tool. Do not copy AGENTS.md into them.
• MCP fixes "AI cannot", not "AI does not know". Use MCP to let the agent drive a browser or query a database; use AGENTS.md to tell it your conventions.
• Skills fix "this task has a set procedure". Release steps, writing migrations, weekly reports: these do not need to take up context until they are used.

A common mistake

Putting everything in AGENTS.md. It loads in full every session, so a long file crowds out the context the agent needs for real work, and the model is more likely to miss details. Once it grows past a screen or two, move parts into Rules or Skills.