Codex subagents and skills, honestly compared

What people are asking for when they say Codex subagents and skills

The searches for Codex subagents and skills almost always come from people who used a named-agent or skill mechanism in another tool and want the same thing here. Underneath, they want two separate capabilities, and it helps to name them apart.

One is delegation. Spawn a scoped helper to do a bounded job, have it report a summary back, and keep its 40,000 tokens of file reading out of the main conversation. The value is context hygiene more than parallelism.

The other is reusable procedure. A written recipe the agent loads when relevant, so your database migration process or your release checklist does not have to be retyped every time. That is what a skill is.

Check the current docs before you build on a feature name

Agent tooling is moving fast and the vocabulary is not settled between vendors. Rather than tell you which flag exists this month, we tell teams to check the Codex documentation and release notes directly before designing a workflow around a named capability. Anything else in an article this age is a liability.

What has been stable is the substrate: AGENTS.md for repo context, non-interactive runs, configurable sandbox and approval levels, and MCP for connecting external tools. You can build both capabilities out of those.

Delegation without a subagent feature

The pattern is a scoped, non-interactive run that produces a written artefact, which your main session then reads.

• Run a read-only investigation in its own process, with a prompt like "map every place we construct a database session and write the findings to notes/sessions.md. Do not modify code."
• In your main session, read that file. You get the conclusion at a few hundred tokens instead of the exploration at tens of thousands.
• For work that writes code, give each run its own git worktree so two of them cannot collide in the same tree.

It is more manual than a built-in mechanism. It is also transparent, which matters when something goes wrong and you need to see exactly what the helper read.

Skills as files, not features

A skill is a procedure the agent can find and follow. You can get most of the benefit by keeping a docs/procedures/ directory of short markdown files and pointing at them from AGENTS.md: "for anything touching the schema, follow docs/procedures/migrations.md."

Keep each one under a page and write it as steps with commands, not prose. The failure mode we see is a 2,000-word document that reads like onboarding material. The agent skims it the same way a new hire does, and picks up the vibe rather than the rules.

Honest limit: this approach depends on the agent choosing to read the file. It usually does when the pointer is explicit and the trigger condition is concrete. It does not when your instruction file has grown to 400 lines and everything competes for attention.

What to do this week

Pick the one procedure your team explains to newcomers most often. Write it as a numbered list of commands in a single file. Add one line to AGENTS.md telling the agent when to open it. Then watch the next three runs and see whether it does. That test tells you more about your setup than any feature comparison will.

If you want help putting this into practice, talk to us.