5 AI Agent Terms Every Operator Should Know
AGENTS.md, agent skills, MCP, A2A, and sub-agents — the five pieces that turn a model into something that runs a company. Here's what each one is in plain English, ranked by what actually moves the needle for a small team. The model is the commodity. This stack is the moat.
There's a good explainer making the rounds — IBM's "5 AI Agent Terms You Need to Know." It's clean, and the structure is right: five terms, grouped into the parts inside the agent, the parts that reach outward, and the part that scales. I'm keeping that skeleton. But a definitions video tells you what the words mean. It doesn't tell you which ones matter when you're the person whose company actually runs on them.
I run five AI-native companies — Sena, Precis, Gavel, TrueStandard, and GameTape — with co-founders, AI agents, and zero hired employees. All five run on exactly these five primitives. So does the website you're reading this on: this guide was written by an agent skill, working from an AGENTS.md, pulling transcripts through an MCP-style cache, with a sub-agent spawned to read the codebase. It's a live artifact of the stack it describes. I'll point that out as we go, because it's the cheapest proof I have.
To rank the five honestly, I checked them against the room. I keep a cache of roughly 26,000 comments from the YouTube channels where people build agents for a living — and the people shipping real systems are not asking about all five equally. One of them gets 14 times the chatter of another. That gap is the whole point of this guide. So: the five terms, in plain English, reordered by what actually moves the needle.
5
terms = the whole agent operating stack
124
comment threads asking about MCP in our cache
14×
more cache chatter on MCP than A2A
0
hired employees running this stack across 5 companies
What Is the Agent Operating Stack?
Five pieces turn a model into a working agent. Two shape how it behaves (AGENTS.md, skills), two let it reach outward (MCP, A2A), and one lets it scale past a single context window (sub-agents). I call the set the Agent Operating Stack.
A large language model on its own is a conversational partner. Smart, but inert — it generates text and reasons, and then it stops. Everything that turns it into an agent that does work lives in the layer wrapped around the model. That wrapper is the stack. Here's the whole thing on one page, in the three zones IBM grouped them into:
Inside the agent
how it behaves
AGENTS.md
The rules it reads on startup — commands, conventions, guardrails.
Agent skills
Reusable task playbooks that load only when relevant.
Reaching outward
tools & other agents
MCP
A standard plug to your tools and data — CRM, DB, Stripe.
A2A
A standard for one agent to hand work to another.
Beyond one context
how it scales
Sub-agents
Children spawned with fresh context for big or parallel work.
Here's why an operator should care about the wrapper and not the model. The models are already good enough; they get better on someone else's schedule, and everyone gets the upgrade at once. What you can actually build a durable advantage on is the stack around the model — the instructions, the skills, the tool connections, the orchestration — because that's the part shaped to your company and nobody else's. It's the harness, not the horse.
And these five aren't fringe jargon. In my cache, the most-saved videos from builders are multi-hour courses whose chapter lists read like this stack verbatim — one timestamped comment marks "1:18:00 sub agents… 1:26:00 skills," another "dos and dont of .claude." This is the curriculum the people building agents are actually studying. The rest of this guide is the operator's annotation on it.
What Is AGENTS.md (and Is It the Same as CLAUDE.md)?
AGENTS.md is a plain-text README written for your agents — the commands, conventions, and hard rules they read every time they start work in a project. Claude's version is called CLAUDE.md. Same idea, different filename.
It's just a markdown file at the root of a project. When the agent starts work, it reads whatever is in there — which commands to run for tests, what coding conventions the codebase uses, how a pull-request title should be formatted. Think of it as a README, except the reader is a machine that will actually do what it says: write "run the test suite before committing" and the agent runs the test suite before committing. The files can nest, too — a root file for the whole company, more specific ones deeper in, with the closer file winning. AGENTS.md started at OpenAI and is now an open standard under the Linux Foundation; Claude's CLAUDE.md is the same concept under a different name.
Here's the operator's take, and it's the most important sentence in this section: this is where most of the leverage is, and it costs you an afternoon. Everyone fixates on models and MCP servers. The file that decides whether your agent guesses or ships in your house style is a text document anyone can write. The repository behind this very website has one — it's literally a symlinked AGENTS.md → CLAUDE.md, about 250 lines of source-of-truth priority, the exact commands to run, and nine hard rules the agents are not allowed to break. It is the cheapest, highest-return thing in the whole stack.
For a mid-market company, the mental model is this: AGENTS.md is the place you write down the institutional knowledge that currently lives in one senior person's head. "We always do it this way." "Never touch that." "The real source of truth is here, not there." That's not a coding artifact — that's your operating standard, finally written somewhere an agent can execute it instead of asking. If you do nothing else on this list, do this one.
What Is an Agent Skill, and When Does It Load?
A skill is a folder with a SKILL.md and a one-line description that says "use me when the user wants X." It only loads into context when the task matches — so an agent can carry hundreds of capabilities without drowning in any of them.
Inside the folder is the SKILL.md plus whatever scripts or resources the task needs. The trick is the description in the metadata: it tells the agent "invoke me when the user wants to build a PowerPoint" (or write a guide, or reconcile invoices). If the request matches, the agent pulls the skill in. If it doesn't, the skill just sits there, out of the way, taking up none of the context window. That's the part that matters — it's called progressive disclosure, and it's how you give an agent a lot of capability without paying for all of it on every task.
This guide is the example. It was written by a skill called guide-from-channel-data. Until I asked for a guide, that skill was not in the agent's context at all — it sat dormant alongside eight others in this repo (the ones that sync the channel cache, run the daily sales desk, ship the weekly brief). When I typed the request, it loaded, did its job, and got out of the way. If "an agent skill is a reusable SOP" sounds abstract, that's the concrete version: a written-down procedure the agent reaches for only when it's the right tool.
Builders are visibly working out where the line sits between a skill and everything else. A representative thread from my cache: an operator asking a creator for "your recent take on DOE vs Claude Skills… the pros and cons of each, and did you attempt to combine the two to take the best of both worlds?" The confusion is real, and the operator answer is a frequency test. Always-on, project-wide rules go in AGENTS.md, because the agent needs them every session. Occasional, task-specific capability becomes a skill, because the agent needs it sometimes — and progressive disclosure keeps the other 95% of sessions clean.
For a mid-market team, skills are how you turn "the way Dana does the monthly board deck" into something any agent can run on demand — without that procedure cluttering every unrelated task. We even give a few away at agrahri.com/skills, so you can see the shape of one before you write your own.
What Is MCP (Model Context Protocol)?
MCP is the standard plug that lets an agent reach your tools and data — Notion, Stripe, a database — without a custom connector for each. An MCP server wraps the tool; any MCP-speaking agent can use it. It started at Anthropic and is now under the Linux Foundation.
An agent that can only talk is half a tool. The other half is reaching outside itself — into APIs, databases, dev tools, SaaS platforms. The problem MCP solves is that every one of those has its own interface, so without a standard, every agent would need a bespoke connector for every system it touches. That's the mess. MCP is the agreed-upon socket: you stand up an MCP server that wraps a tool — Notion, your payments system, your warehouse — and from then on any agent that speaks MCP can use it. The agent speaks MCP; the server handles the messy underlying API. These are the agent's hands.
This is the busiest layer in my entire cache — 124 separate comment threads wrestling with it. And the chatter isn't all evangelism, which is exactly why it's useful. One operator describes the real architecture and the real wall in the same breath: "an orchestrator like Claude and having MCPs of tools connected to it… I tried something like this but it doesn't seem scalable across time." Right next to it, the skeptics: "Love to hear that MCP is just BS," and the sharper "MCP is dying, skill-wielding agents can just use WIF." The standard is young, contested, and changing. That's normal for the layer everyone's actually building on.
The operator's take: MCP is worth wiring, but not for everything. You don't need an MCP server for every tool in your stack — you need it for the two or three systems your agent touches every single day. The transcripts behind this guide come through our own MCP-style cache so the agents don't re-fetch them; that's the pattern — connect the daily-driver systems, leave the long tail alone. When a vendor's pitch is mostly MCP-this and MCP-that, the question to ask is "which two of my systems does this actually need to touch," not "how many can it."
What Is A2A — and Do You Actually Need It Yet?
A2A (agent-to-agent) is a standard for agents to talk to each other: each publishes an "agent card" describing what it does, and others read it to delegate work. It's real, it's from Google, it's under the Linux Foundation — and for almost every mid-market company in 2026, it's the one layer you can skip.
The idea is clean. Say a procurement agent negotiates a contract and needs sign-off from a finance agent that approves spend. Without a standard, those two need a custom integration. With A2A, each agent publishes an agent card — a description of what it does and how to talk to it — and the procurement agent reads finance's card and hands off the contract. Genuinely useful, eventually. But "eventually" is doing real work in that sentence, and an operator should hear it.
9
comment threads in our cache
124
comment threads in our cache
The numbers tell the story. Across the channels where people build agents for a living, MCP shows up in 124 comment threads; A2A shows up in 9 — about 14 times less. And when A2A does come up, it's framed as the future, not as Monday's work: "less tech products will rely on browser extensions… and later migrate to webMCP and A2A standards," or in the swarm-intelligence register, "early-stage agent-to-agent interaction ecosystems." The people shipping production agents right now are not, by and large, building agent-to-agent coordination. They're wiring MCP and spawning sub-agents.
So here's the operator's call, and it's the contrarian one in this guide: you almost certainly don't need A2A yet. Across five companies, I use zero of it. When real coordination is required, it's one orchestrator spawning sub-agents and writing to shared files — simpler, debuggable, and it works today. Keep A2A on your radar as the standards mature. But when it shows up in a vendor deck, ask the only question that matters: have you shipped one, or is this a slide?
What Are Sub-Agents, and When Should You Spawn Them?
A sub-agent is a child the main agent spawns with its own fresh context window to do one chunk of work and hand back a result. It's how you handle jobs too big for one context — reviewing thousands of files — or embarrassingly parallel ones, like twenty independent checks at once.
Sometimes one agent isn't enough — not because the task is hard, but because it doesn't fit. Reviewing a codebase with thousands of files would blow out a single context window just loading them. Twenty independent checks done one at a time is twenty times too slow. The fix is the same in both cases: the main agent spawns a sub-agent, hands it a narrow job, and the sub-agent runs in its own clean context, does the work, and returns just the result. The parent's context stays uncluttered; the work gets done in parallel.
This guide used one. Early on I needed to know exactly how the site's email-gating worked before I could publish this page ungated — a question that means reading a controller, the routes, and the sitemap. Instead of dragging all that into the main thread, the main agent spawned a sub-agent to read those files and hand back a one-page map of the mechanism. The main context stayed focused on writing. That's the whole pattern: send the child to read 500 files, get back a paragraph. Unlike the other four terms, sub-agents have no formal standard document — but the concept shows up almost identically in every modern agent system.
It's also the highest-skill of the five, and the cache shows the rough edges. One builder marvels that a four-hour research job felt "like having 30 agents working in parallel… researching, distilling it down." Another names the gotcha precisely: "he is talking about using 10 sub-agents in parallel but they are breaking the auto-compact logic." Both are true. Fan-out is the closest thing to a superpower a small team has — and it's the one most likely to bite you if you spawn ten of them without thinking about how the results come back.
For an operator, this is the term that explains the headline claim. "Two people doing fifty-people throughput" isn't a bigger model — it's one operator orchestrating many sub-agents on work that used to need a department. It's the most powerful primitive on the list and the last one you should reach for, because it only pays off once the first three are solid. Worth going deep on once you're there — I wrote the engineering-grade version, context budgets, fan-out, and self-correcting loops included, in Every Agentic Engineering Hack I Know.
Which of the Five Should You Wire Up First?
If you run a company and want agents doing real work, the order isn't the order the terms were introduced in. Here it is by leverage-per-hour for a small team — roughly 80% of the value is in the first three.
Hour one · highest leverage
AGENTS.md
Write down your commands, conventions, and hard rules in one plain-text file.
Why here: Cheapest, highest-return move in the stack. Turns an agent that guesses into one that ships in your house style.
Week one
Two or three skills
Turn your most-repeated tasks into skills, each loaded only when its description matches.
Why here: Your written-down SOPs, executable on demand — without cluttering every other task.
Week one–two
One MCP
Connect the single system your agent touches daily — your CRM, your database.
Why here: Gives the agent hands where it matters. Resist wiring an MCP for everything.
When work won't fit
Sub-agents
Spawn children with fresh context for jobs too big for one window, or parallel ones.
Why here: The fan-out that lets two people do fifty-person throughput. Highest skill, biggest payoff.
Skip for now
A2A
Leave it. Revisit only when you have multiple production agents that must negotiate.
Why here: Real but speculative for mid-market. Zero of my five companies use it today.
The shape of this list is the whole point. The cheapest things — a text file, a couple of written-down procedures, one tool connection — carry most of the load. The flashy things at the bottom are real but later. Most companies that "tried AI and it didn't stick" never wrote the AGENTS.md; they jumped to the orchestration demo and skipped the constitution.
If you want the version of this pointed at your actual company — which function to make agent-run first, and which two systems to wire — that's the audit. It's the same reasoning as this build order, applied to your demand instead of the generic case. The deeper teardown of how these layers fit a whole company is in What "AI-Native" Actually Means, and the demand behind all of it is mapped in What 26,000 Operators Are Actually Asking About AI.
Frequently Asked Questions
Is AGENTS.md the same as CLAUDE.md?
Same idea, different filename. AGENTS.md is a plain-text README written for your coding agents — the commands to run, the conventions to follow, and the rules they read every time they start work in a project. Claude reads a file called CLAUDE.md instead; some setups symlink one to the other so both names point at the same file. AGENTS.md started at OpenAI and is now an open standard under the Linux Foundation. The format barely matters — what matters is that the file exists, because it's the single highest-leverage, lowest-effort thing you can give an agent.
What is the difference between MCP and A2A?
MCP (Model Context Protocol) is how an agent reaches outward to tools and data — a standard plug so one agent can talk to Notion, Stripe, or your database without a custom connector for each. A2A (agent-to-agent) is how two agents talk to each other — each publishes an "agent card" describing what it does, so others can delegate work to it. MCP is the busy, useful layer most teams need now; A2A is real but still mostly speculative for mid-market companies. In a cache of ~26,000 builder comments, MCP comes up roughly 14 times as often as A2A.
Do I need sub-agents to run agents in my company?
Only when a job won't fit in one agent's context window or is embarrassingly parallel. A sub-agent is a child the main agent spawns with its own fresh context to do one chunk of work and hand back a result — useful for reviewing thousands of files, or running twenty independent checks at once. It's the highest-skill, highest-payoff of the five terms for a small team, because it's how two people get fifty-person throughput. But it's not where you start: most of the value lives in AGENTS.md, a couple of skills, and one MCP.
When should I use an agent skill instead of just writing it into AGENTS.md?
Put always-on, project-wide rules in AGENTS.md — it's read every time the agent starts work. Put occasional, task-specific capability in a skill — a folder with a SKILL.md that only loads into context when the task matches its description. The test is frequency: if the agent needs it every session, it belongs in AGENTS.md; if it needs it sometimes (build a deck, run a specific report), make it a skill so it stays out of the context window until it's relevant.
Which of these five terms should a mid-market company set up first?
In order of leverage-per-hour for a small team: (1) AGENTS.md — write it in the first hour; (2) two or three skills for your most-repeated tasks — week one; (3) one MCP for the single system your agent touches daily, like your CRM or database; (4) sub-agents, once a job won't fit one context; (5) A2A — skip it for now and revisit only when you have multiple production agents that genuinely need to negotiate. Roughly 80% of the value is in the first three.
Get the operator teardowns by email
I publish how the AI Operating System actually gets built — the stack, the architecture, and real numbers from the five companies I run with zero hired employees.
Free operator research. No spam.
Want this wired up for your company?
The build order above is the generic case. The audit points it at your actual company — which function to make agent-run first, which two systems to wire, and the order to build your own AI Operating System. I take a few a month.
Apply for an audit