What caught my eye is not that Claude Code has sub-agents, hooks, and skills. It’s that the article treats those three things as if they’re a neatly unified orchestration stack, when the real story is probably messier. I’d be careful about reading too much product intent into it. A lot of this reads like someone taking plausible agent-design patterns and mapping them onto Claude Code because that’s the tool they’re already using.
That doesn’t make it useless. It actually points at the part of agent work that people keep hand-waving past: the boring control plane. Anyone can say “let the model reason.” Far fewer people talk honestly about where you isolate context, where you enforce policy, and where you stop the thing from wandering off into a token bonfire. That’s the useful instinct here. The article is at its best when it’s basically saying: don’t make every step a giant inline mess if you can split the job up, and don’t let every tool call be unconstrained just because the model asked nicely.
I’m a little unconvinced by the confidence around “skills,” though. In the article, skills sound almost like tidy, portable domain packs you can move between systems. That’s an attractive idea, but in practice these packages are usually brittle. The tool list, the prompts, the state, the policy assumptions, the environment details — they drift. A “SAP ABAP skill” on one team’s setup is often not really reusable on another team’s setup without a fair amount of surgery. So yes, the packaging idea is right. The portability claim is where I’d want proof.
The hook discussion feels more grounded to me, especially the emphasis on pre- and post-tool checks. That is the kind of layer people ignore until they’ve already shipped something embarrassing. If you’ve ever had an agent gleefully do the wrong thing because the tool interface was too permissive, the appeal is obvious. I think the article is basically right that guardrails matter as much as the model itself. The part I’d resist is any implication that hooks alone make agent systems “safe and predictable.” They help. They do not make the system trustworthy in any strong sense.
The comparison with n8n/Ollama-style orchestration also rings true, if only because it admits a distinction many AI posts blur: there’s the clever part and there’s the plumbing. A lot of production failures happen when people try to force the clever part to do plumbing work. Using Claude for judgment and a more deterministic workflow engine for repetitive steps is sensible. That hybrid setup is probably where most serious teams will end up, whether they say it out loud or not.
What I’d actually try, if I were building with Claude Code, is much smaller than the article’s grand orchestration framing. I’d start with one or two hard guardrails around tool calls, a very limited sub-agent boundary for genuinely independent work, and a brutal habit of resetting context before it gets sticky. The “if stuck” rule is maybe the most practical idea in the piece, because it acknowledges something people hate admitting: agents do not always recover themselves. Sometimes they just spin. You need a stop condition before that becomes an expensive ritual.
Reference: Sub-Agents, Hooks, and Skills: The Orchestration Layer Claude Code Won't Advertise
