Skills, Subagents, Hooks, and MCP: The Mental Model Engineering Leaders Are Missing
Skills, subagents, hooks, MCP. Most leaders treat them as one pile of jargon and let whoever wired the agent that morning decide. Each answers a different question, and the question is yours.
Four words keep showing up in the same sentence, used as if they meant the same thing: skills, subagents, hooks, MCP. They land in your engineers' setups. They show up in changelogs and LinkedIn posts. Most engineering leaders treat them as one undifferentiated pile of agentic jargon, or as one vendor's feature list, and reach for whichever the loudest person on the team configured last. That instinct is the problem. These four are not variations on a theme. Each one answers a different question, and the question is yours to answer, not your tooling's.
AI coding agent architecture is the set of building blocks that determine how an AI coding agent does work: skills (the methods it has available), subagents (the work it gives separate context and delegated responsibility), hooks (what runs automatically at lifecycle events), and MCP (the external capabilities exposed to it through a governed boundary). Choosing among them is a decision-rights, review-standard, and system-access decision, not a tooling preference.
Here is the claim this whole piece defends. The four building blocks have four distinct primary responsibilities, and the choice between them is an operating-model decision rather than a tooling one. If that mapping were false, if these were really overlapping features whose choice came down to taste, you could treat them as a menu and pick by vibe. They are not, and you cannot. A skill is not a hook with a different name. A subagent is not a smaller MCP. Collapse them into one pile and you do not just lose precision. You hand the operating-model decisions they each encode to whoever wired the agent that morning.
Most of the writing on this topic stays at the developer's desk. It explains what each thing is, how to build one, which agent ranks highest this quarter. That altitude works for an engineer setting up their own environment. It is the wrong altitude for the person accountable for how AI-assisted delivery runs across the organization. The same four objects look different from the operating-model layer, and that is the layer where you have authority and where the cost of getting it wrong compounds.
Four blocks answer four different questions
Four blocks, four questions. That is the entire mental model, and it fits on one line each. It is worth memorizing because the moment you can name which question a given problem belongs to, the choice between the four stops being a matter of preference and becomes a matter of fit.
| Building block | The question it answers | The delivery problem it owns |
|---|---|---|
| Skill | What reusable method or knowledge should be available? | The same task follows a consistent method instead of being re-derived ad hoc each time |
| Subagent | What work should receive separate context and delegated responsibility? | Keeping the main thread clean, parallelizing independent work, containing scope when tools and permissions are constrained |
| Hook | What should happen automatically at this lifecycle event? | Making something run on its own at a lifecycle point: validate, transform, notify, record, or block |
| MCP | What external capabilities should be exposed through a governed integration? | Exposing the exact systems and tools a task needs through a standard boundary, with authorization deciding actual access |
Read the right-hand column again. Those are not four flavors of "make the agent better." They are four separate decisions, each with its own owner, its own failure mode, and its own answer to the question of who decided this and on what authority. The rest of this article walks each one, names the delivery problem it solves, and is just as precise about when it is the wrong choice. The wrong-choice cases matter more than the definitions. Anyone can tell you what a hook is. The signal that someone has actually built with these is that they can tell you when a hook is the wrong tool.
Skills encode a method so it survives the person who wrote it
A skill packages reusable instructions, knowledge, and workflow guidance so recurring work follows a consistent method without re-deriving it each time. It can be invoked automatically when the work matches or called deliberately by a person, and it can carry judgment points and request a human decision where one is needed. What makes a skill worth having is that the method lives in the substrate rather than in the head of whoever happens to be driving, so your strongest engineer and your newest hire both reach for the same encoded approach. The execution is still probabilistic, not a guarantee of an identical run, but the method they follow is shared instead of improvised.
That is why a skill is the right tool for the "AI enablement isn't sticking" problem. Most teams adopt an AI code assistant, see a burst of individual productivity, then watch it plateau because nothing about how the work gets done actually changed. People got faster at the same ad-hoc process. A skill is where "use a tool" becomes "redesign how this role does the work." Encode your code-review preparation, your migration procedure, or your incident-writeup format as a skill, and you are doing role-level redesign expressed in the agent substrate. The method that used to live in one senior person's habits becomes a shared approach the whole function can run. Claude Code skills are the concrete instance most teams meet first, but the principle is tool-independent: a skill makes a reusable method available as a shared, inspectable default. It improves consistency without guaranteeing identical execution.
A skill is the wrong choice in two cases, both common. The first is genuinely one-off work. If you will do this exact task once, encoding it as a reusable method costs more than the task. The second is subtler: work that has no stable method to encode at all. A skill captures an approach worth repeating, and a skill can absolutely hold judgment points and ask a person to decide at the right moment. What it cannot do is invent structure where there is none. If the work is pure improvisation every time, with nothing recurring to package, there is no method to write down yet, and forcing one into a skill just freezes a guess. The test is simple. Is there a reusable method or body of knowledge here that recurring work should follow? If yes, it is a skill. If every run is genuinely novel with nothing to carry forward, it is not.
Subagents isolate a unit of work so its mess stays contained
A subagent isolates context and delegated responsibility: it works in its own conversation, with its own attention budget, and the intermediate work stays outside the main context unless it is returned. That isolation buys you a main thread that stays focused and independent work that can run in parallel where the runtime supports it. It also lets you contain operational scope, but that containment is not automatic. A subagent can still modify shared files and call external tools, and some permission modes are inherited from the parent. The blast radius is contained only when the subagent's tools, permissions, workspace, and write scope are constrained separately, as a deliberate decision rather than a property you get for free by spawning one.
The delivery problem subagents own is the one every long agentic session eventually hits. A single agent trying to hold the whole task in one context degrades as that context fills with the residue of subtasks: the failed attempts, the verbose tool outputs, the exploration that did not pan out. Hand a bounded piece, say a research pass over a codebase or a batch of independent file edits, to a subagent, and that piece runs in isolation and reports back clean. The common framing for this is "single agents fail on complex work, so use a layered architecture." True at the builder's desk. At the operating-model layer the same fact reads differently: a subagent is a decision about which units of work are independent enough to isolate, and that is a separation-of-concerns decision about your delivery process, not a clever agent trick.
Subagents are the wrong choice when the work needs the full conversation context to be done well. If the task depends on everything that came before, the nuance of the discussion, the decisions already made, the constraints surfaced three steps back, then isolating it strips out exactly what it needs. The other wrong case is the trivially small task. A subagent has a handoff cost: framing the task, spawning the context, parsing the return. For work smaller than that overhead, the isolation costs more than it saves. Reach for a subagent when a unit of work is both bounded and independent. When it is neither, keep it on the main thread.
Hooks turn a standard into something that runs whether or not anyone remembers it
A hook fires automatically at a defined point in the agent's lifecycle. The question it answers is "what should happen automatically at this lifecycle event," and the answer can take several shapes. A hook might run a shell command, call an HTTP endpoint, or run an LLM prompt. It might validate, transform, notify, record telemetry, advise, or block what happens next. Enforcement is one of those shapes, not the definition. What every hook has in common is that it runs because the lifecycle reached the point where the hook is wired, every time the matched lifecycle event occurs, independent of anyone's discipline. The standard, or the notification, or the record does not depend on anyone reading it, remembering it, or choosing to apply it under deadline pressure.
This is where a written policy stops being a PDF. Most review standards in most organizations live as documents: a wiki page about commit conventions, a checklist about what to verify before merge, a norm about running the formatter. Documents are hopes. They work exactly as well as the most rushed person's memory on the worst day. A hook makes that standard automatic at a matched lifecycle event. The post-edit step that runs the test suite, the matched-event check that rejects a secret before the change lands, the gate that blocks output failing a contract: each is a review standard the agent now runs on its own. A hook becomes enforcement only when its handler is deterministic, blocking, fail-closed, and protected from unauthorized configuration changes; prompt-based or agent-based hooks stay probabilistic, and many hooks simply notify, transform, or record. Where it is the enforcing kind, a hook is the layer where a quality harness actually grips. If you have read about quality harness engineering as the emerging reliability stack, hooks of the enforcing kind are that grip: the eval gates and contract checks that fire on their own.
A hook is the wrong tool for the blocking use case when the review it would enforce is judgment-heavy and cannot be reduced to a deterministic check. If the standard is "does this architectural change make sense given where we are headed," no hook can decide it, because the answer is not computable from the diff. Wire judgment-heavy review into a blocking hook and you get one of two bad outcomes: a gate so loose it passes everything, which is theater, or a gate so strict it blocks legitimate work, which trains people to bypass it. The discipline is to use a blocking hook only for standards that are genuinely deterministic, a quality gate you can express as a check, and to leave the judgment calls to human review where they belong. A hook can still help around that human review, by notifying the right person or recording that the change happened, but the decision to pass or block stays with a person.
MCP standardizes how servers expose tools, resources, and prompts to the agent
MCP, the Model Context Protocol, standardizes how servers expose tools, resources, and prompts to the agent through a standard integration boundary: a database, a ticketing system, a document store, an internal API. The mechanism is a governed integration surface. Through an MCP server, you choose which systems and which operations a task can reach. The word to hold onto is "exposed." MCP is not a plugin store you stock for convenience, it is the boundary where you decide what gets surfaced to the agent in the first place. What the agent can actually access then depends on the server's own authorization, the credentials it holds, the operations it exposes, your client permissions, and any approval steps, not on MCP alone. The agent may also reach things outside MCP entirely, through shell, filesystem, web, or native tools, which is exactly why MCP scope is a decision worth making deliberately rather than a complete access boundary on its own.
That reframing is the whole governance weight of MCP, and it is the part the desk-level writing skips. Every MCP server you connect is two things at once: an exposure decision and a supply-chain dependency. An exposure decision, because you have just made some system reachable to the agent, and the agent can request the operations the server exposes, subject to the server's authorization, client mediation, and any approvals. A supply-chain dependency, because that server is now an integration dependency in the agent execution path, with its own maintainer, its own update cadence, and its own potential to be the weak link. Exposing a system broadly because it is easier than scoping it is the same mistake as giving every new hire root on day one. The actual permission still lives in the server's authorization, but the breadth you choose to expose sets the ceiling, and when something goes wrong, that ceiling is the size of the problem.
MCP is the wrong choice, or more precisely a liability, when reach is granted for convenience rather than need. The failure mode is not connecting MCP at all, you usually have to. The failure mode is connecting it wide. An agent that can reach everything is an agent whose every prompt is now a query against everything, including the data that prompt had no business touching. The governance move is to treat MCP scope as a deliberate exposure decision: which systems you surface, which operations you expose, reviewed alongside the server's own authorization and your client permissions the way you review any access decision. Think of your connected MCP servers the way you think of your software supply chain, because that is what they are.
Watch the four compose, and the menu framing falls apart
Picture a single delivery workflow running end to end, and the four blocks stop looking like alternatives. A migration needs to happen across a large codebase. The method for doing it well, the order of operations, the checks at each step, the rollback plan, is encoded as a skill, so the same method is available as a shared default no matter who kicks it off. The actual file-by-file work goes to a subagent, which receives a restricted workspace and a scoped set of tools so the main thread stays clear and the migration's intermediate churn does not pollute the session. MCP exposes the external pieces the work needs, the migration inventory and the CI operations, through a governed boundary. A hook fires on each change the subagent produces, running the test suite and blocking anything that breaks the contract, so the standard holds without anyone watching. And separate permission rules constrain which repositories the subagent may actually modify, so the breadth of the change is bounded by an explicit grant rather than by what happened to be reachable.
Skill, subagent, hook, MCP, separate permission rules, one workflow, each doing the one thing it is for. The skill carried the method. The subagent carried the context and delegated work. MCP exposed the external capabilities. The hook ran the automatic check. And the permission rules, sitting alongside all of it, bounded what could actually be touched. These primitives can technically overlap, but each has a different primary responsibility: a skill should carry the reusable method, a subagent the delegated context, a hook automatic lifecycle behavior, and MCP standardized external exposure. Using one to imitate another usually makes ownership and control less clear, which is why they read as complementary primitives rather than competing features, and the clearest proof is watching them work together. Once you see them compose, the question "which one is best" dissolves. It was never the right question.
The real decision is operating-model design at the substrate layer
The deeper mechanism is that these four blocks sit among the primitives an engineering organization uses to install repeatable, governed, AI-enabled delivery, and choosing among them is operating-model work that has quietly migrated down into the agent substrate. They are not the only governance-relevant pieces. Permissions, sandboxes, CI controls, memory, policies, and observability all matter too, and the four blocks here are the subset whose choice most clearly reads as an operating-model decision. BCG's 2026 survey found that employees at companies pursuing end-to-end workflow redesign (its Reshape and Invent group) were 24 percentage points more likely to see measurable business improvement than those focused on individual productivity, and it stresses operating-model redesign over tooling (AI at Work: Why Strategy Matters More Than Tools). The operating model changes first and the tools follow, and these four blocks are one place that change becomes concrete.
Look at what each choice actually decides. Which standards get encoded as hooks is a review-standards decision: you are choosing which parts of your quality bar stop depending on human memory. Which methods become shared skills is a decision-rights decision: you are choosing how a role does its work and making that method a shared default instead of leaving it to the daily improvisation of whoever is at the keyboard. Which work gets isolated into subagents is a question of how you decompose and contain delivery. And which data an agent may reach through MCP is a system-access decision with direct security and supply-chain weight. Three of those map straight onto the components of an operating model, decision rights, review standards, and system access, which is why treating them as tooling preferences is a category error. You are not picking favorite features. You are designing how your organization delivers.
The leader's job here is not to personally pick every skill, hook, subagent, and MCP connection, and not to have an opinion on which agent is best this quarter. It is to decide who owns each class, what governance applies, and which of these decisions require review. Practice owners author the skills that encode a function's method. Workflow owners define which work is delegated to subagents. Platform or quality owners maintain the hooks that run automatically at lifecycle events. System owners approve which external capabilities get exposed through MCP. Leadership sets that ownership map and the review bar; left unset, those decisions get made by whoever configured the environment last, which means your operating model is being authored by accident. Set deliberately, they become the substrate-level expression of how you want your delivery to run. That deliberate authorship of the substrate, treating the agent's building blocks as operating-model decisions rather than tool choices, is the lens I call Shift Harness, and it is the difference between adopting AI and installing it. If you want the fuller frame, Shift Harness is where the operating-model thesis lives in full.
So the next time those four words show up in the same sentence on your team, the useful response is not to ask which one to buy. It is to ask which question you are actually answering, and to make sure you, and not the last person who touched the config, are the one answering it.
