What is a context system?
Everything your AI coding agent needs to do one job properly, in one repo.
That is the short answer. The longer one takes about four minutes, and it starts with the five things a context system usually gets confused with.
Your AI coding agent already gives you five things.
Standing rules, skills, plugins, subagents and MCP servers. If you have spent any time in Claude Code or Codex you have met all five, and they are the five a context system gets mixed up with, so they are worth ten seconds each.
Standing rules
One file your agent reads before it does anything, every session. The only thing always in front of it, which is why it has to stay short.CLAUDE.md in Claude Code, AGENTS.md in Codex
Skills
A procedure your agent picks up when the task calls for it. This is how a system can be thorough without slowing every conversation down.a /deploy skill that stays out of the way until you deploy
Plugins
How a skill gets installed into somebody else's setup. A plugin answers how this reaches a colleague.installed from a marketplace in one command, like a package
Subagents
A second agent, started for one piece of work with its own brief. Useful when you want an opinion from something that has not seen the first one.a reviewer that reads your diff without seeing your reasoning
MCP servers
A way to hand your agent tools and data from outside itself. It widens what your agent can reach.your issue tracker, your database, your internal docs
Every one of those five answers “how”, and none of them answers “what”.
Standing rules are a file your agent loads. Skills are a folder it opens. Plugins are how either one travels. Subagents and MCP servers widen what it can do and reach. They are all loading mechanisms, and they are all empty until you put something in them.
A context system is what you put in them, aimed at one job. It uses every one of those five, and it adds three things your agent has no concept of.
Facts it can cite
no tool provides this
- Your sources of truth, in the repo
- Every claim comes back with somewhere to check it
- The end of answers assembled from memory
Work it produces
no tool provides this
- Real deliverables, generated by code the system owns
- Change your mind, re-run, and the whole set comes back right
- Nothing exported by hand at three in the morning
Checks that hold the line
no tool provides this
- Standards drift over months, quietly
- These catch it the moment the work slips
- The reason quality holds a year from now
Those three are simply files in your repository, which has a useful consequence: most of what makes a context system valuable has nothing to do with which agent you run it in, and you own all of it outright the moment you clone one.
Which agent you use barely matters.
Claude Code and Codex have converged further than the noise suggests. Skills are close to identical in both, down to the filename and the frontmatter. Moving a system between them is mostly renaming a directory.
| Concept | Claude Code | Codex |
|---|---|---|
| Standing rules | CLAUDE.md |
AGENTS.md, concatenated from the repo root down to your working directory |
| Skills | .claude/skills/<name>/SKILL.md |
.agents/skills/, scanned from your working directory up to the repo root |
| Skill format | SKILL.md with name and description in frontmatter, loaded only when the agent decides to use it. The same in both, and the strongest genuine equivalence here |
|
| Plugins | Installed from a marketplace, able to bundle skills, agents, hooks and MCP servers | Documented as the way skills are packaged and shared |
| Subagents | .claude/agents/, Markdown with frontmatter |
.codex/agents/, TOML with three required fields |
| MCP servers | Configured per project or per user | Configured in config.toml |
Subagents are the one piece that gets rewritten going between them. Standing rules and skills travel with a rename. Codex hooks and custom prompts were out of scope for this comparison and no equivalence is claimed for either.