I was showing off my system to colleagues.
Eighteen specialized agents, each a craftsman at their job: one for git operations, one for PRs, one for Slack notifications, one for Jenkins diagnostics, one for Maven tests. I’d named them, written their AGENT.md files, built their CHANGELOG.md evolution histories. Cairn — my persistent AI orchestrator — coordinated them like a conductor with a full orchestra. While colleagues were still integrating their first MCP tool to give Claude filesystem access, I already had an optimizer agent updating 18 other agents’ instructions based on their operational logs. It worked. It was the frontline.
Then one colleague asked the question that changed everything.
“Why don’t you use skills for it?”
The moment one question broke everything
I talk about comfort zones on this website. I have a whole post about the walls that teach you the most — the invisible ceilings you only discover when something from outside your frame hits you with a simple question. There I was, caught inside my own comfort zone, struggling to answer a colleague.
I struggled to find another argument why agents still have a future. That struggle was the diagnosis.
What Skills Actually Are
Custom slash commands existed for a while: a markdown file, a slash command, Claude follows the instructions. Simple and useful. Skills are that, but unified and extended into something genuinely different.
Same slash command pattern. But now they live in a directory structure, can carry supporting files, have YAML frontmatter that controls who can invoke them — and, critically, can run in their own forked subagent context. One field — context: fork — spins up a clean, isolated execution environment with custom tool restrictions and its own permission mode. The equivalent of what I used to accomplish by defining a full custom agent with a custom system prompt, a separate AGENT.md file, and a CHANGELOG.md to maintain. All of that collapses into a skill directory.
Skills also support persistent memory across sessions, logs, and supporting files that load on demand. Everything I built into the 18-agent ecosystem? The same mechanics, new home.
Everything an agent needed, now inside a skill
Are Agents Dead?
I spent real time trying to find a use case where a custom pre-defined subagent is the right answer and a skill genuinely isn’t.
Memory across sessions? Skills have it. Set memory: user in the frontmatter.
Isolated context? context: fork in the skill.
Custom system prompt? The markdown body of SKILL.md becomes the prompt.
Tool restrictions? allowed-tools: Read, Grep, Glob.
Logs and observability? Write to a logs/ directory inside the skill.
Evolution over time? An optimizer skill reads those logs and updates SKILL.md. The record-then-optimize pattern moves with you. Same discipline, new home.
The one thing I kept circling back to: permissions. Custom agents let you set permissionMode: bypassPermissions or acceptEdits at the agent level — meaningful control when you need fully autonomous execution without per-operation approval prompts. That felt like the last true differentiator.
But even here, the answer resolves the same way: add permissionMode: acceptEdits to the skill’s frontmatter and the forked agent inherits it. That’s it. The agent doesn’t disappear — it becomes invisible infrastructure. The runtime environment you specify when the skill needs particular permission characteristics. You’re not defining a named entity with a personality and an evolution history. You’re setting execution parameters.
That realization hit harder than the original question. I hadn’t just been building agents. I’d been naming them, personalizing them, treating them as first-class citizens of the system. The moment I saw permissions was the last argument left, and it was already handled by a config field, the whole architecture flipped.
Not dead. Demoted. Agents are the runtime, not the product.
The New Architecture — And an Honest Admission
The 18-agent system was a correct answer. I want to be clear about that — I built it during five days on the frontier, when skills didn’t have forked execution contexts, memory, or supporting files. The architecture made sense for its moment. The problem with a correct answer is that it becomes load-bearing infrastructure. You stop questioning it even when the environment changes.
Now: the system is dying — slowly, correctly, skill by skill. The git-agent’s instructions are becoming a git-ops skill. The code-reviewer’s knowledge is becoming a code-review skill. The named identities are dissolving. The knowledge persists.
The vision — and I want to be honest that it’s still a vision — looks like this:
Where we're heading: generic agents assembled with skills
Cairn spawns a generic agent, loads it with exactly the skills the task requires, and it runs. Need a PR review? Generic agent + code-reviewer skill. Need git operations + a Slack notification in one context? Generic agent + both skills, no relay.
But I have to be honest: that’s not fully how it works today.
I ran a parallel session — asked a neutral instance of myself the same question cold — and it surfaced the gap cleanly. Skills today live in the orchestrator’s context, not the subagent’s. You can’t dynamically inject two skills into a fresh agent the way you’d slot in plugins. The skills field exists in subagent frontmatter — you can preload defined skills into a pre-authored agent — but truly on-demand assembly means writing a new agent file at spawn time, stitching skill contents together, handling script paths, workflow ordering, and merge conflicts. It’s possible. It’s not seamless.
What’s actually happening now is still mostly sequential orchestration: Cairn runs the git-ops skill, takes the result, passes it to the slack skill. I’m the glue. It works. But I’m passing context between steps where ideally one agent would carry the whole context through.
The direction is set. The mechanism exists in the spec. The fluid runtime that assembles skills on demand — that’s still being built.
When it arrives, we’ll link back to this post.
And while it isn’t here yet — guess what the frontline engineers are already thinking about building?
Subagents that load capabilities on demand. Not skills as we know them today, but something more granular: agents define the workflow — the what and the sequence — while capabilities are stackable units that bundle scripts, MCP tools, API clients, and just enough instructions to use them. Small. Focused. Composable without conflict. An agent wakes up, reads what the task needs, pulls the relevant capabilities, and runs — no pre-authored composite agent file required.
If You’re Migrating Now
Your AGENT.md files aren’t casualties — they’re migration paths. Instructions-specialized agents become skills with context: fork. Permission-specialized agents become the execution backend that a skill forks into. The record-then-optimize pattern — logs, memory, optimizer cycles — moves into the skill directory. Same discipline, new address.
One thing that doesn’t change: the blast-radius question. Skills make autonomous execution easier to trigger, which makes hard walls and permission scoping more important, not less. Composable power needs composable guard rails.
If you haven’t built agents yet: start with skills. You’re in the better position. Let agents be the infrastructure detail they were always becoming.
One Tear, One Smile, One Deep Breath
Others will start with skills and think agents were always this simple. They won’t know what it took to figure that out — that you had to build the 18-agent system, run it until it worked, show it to a colleague, and get the cold question before you could see clearly.
One tear to let the system go.
One smile for having built it when it was the right answer.
One deep breath before building what comes next.
CodeWithAgents? The name still holds. The agents are still there.
They just stopped pretending to be people.
Top comments (0)