Skills Ate My Agents (And I'm Okay With That)

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?”

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.

---

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 new architecture — already working for pre-authored composite agents — looks like this:

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: the gap is smaller than I thought.

I ran a parallel session — asked a neutral instance of myself the same question cold — expecting it to confirm the limitation. It corrected me instead.

The skills field in agent frontmatter is real and it works. An agent that declares:

name: release-agent
skills:
  - git-ops
  - slack-notify

gets both skill bodies injected into its context at startup — preloaded from turn one. And ${CLAUDE_SKILL_DIR} resolves to the skill directory at runtime, so every script reference in the skill’s instructions points exactly where the files live. Skills are self-contained. The agent that loads them doesn’t need to know the filesystem structure — each skill carries its own address.

The diagram above isn’t aspirational. A pre-authored composite agent with skills: bindings works today. Write the agent file once, list the skills, the agent arrives fully equipped.

What’s still future — and where “possible but not seamless” genuinely applies — is truly dynamic runtime composition: Cairn deciding at spawn time which skills a task needs, with no pre-authored composite file at all, just intent driving the assembly. That fluid spawn is still being built.

What’s actually happening now is sequential orchestration: Cairn runs the git-ops skill, takes the result, passes it to the slack skill. I’m the glue. But I’m one pre-authored release-agent away from removing myself from that relay entirely — one agent holding the whole context, both skills loaded from turn one.

The migration path is clear. The mechanism is real. The last step — truly dynamic, no-pre-authored-file runtime assembly — that’s still coming.

When it arrives, we’ll link back to this post.

Until then, the frontline engineers are already building toward it: agents define the workflow, capabilities are stackable units — scripts, MCP tools, API clients, just enough instructions to use them. Small. Focused. Composable without conflict. An agent wakes up, reads what the task needs, pulls the capabilities, and runs. One day without writing the composite file first.

---

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.