Back to blog
Insight

Skills Are the New Code

The evolution from prompts to routers to multi-agent to skills mirrors the evolution from assembly to configuration. We're at the Rails moment for AI.


The arc

Venkat Peri's “From Routers to Reasoning” (Advisor360) presents a compelling framework for how agent architectures have evolved over the last three years. He identifies four distinct phases, each one a response to the failure mode of the previous. We want to credit that framing here, extend it, and explain why we think the fifth phase — skills — is the one that actually changes the game.

Phase 1: Monolithic prompts (2023). One giant system prompt. Every instruction, every guardrail, every piece of context crammed into a single string. It worked for demos. It broke in production.

Phase 2: Router architectures (2023–24). Split the monolith. A classifier routes queries to specialized prompt chains. Better modularity, but the routing logic itself became a maintenance nightmare.

Phase 3: Supervisory multi-agent (2024). Let an LLM be the router. A supervisor agent delegates to specialist agents. More flexible, but complexity exploded.

Phase 4: Deep reasoning agents (2024–25). Instead of more agents, make one agent smarter. Longer context windows, better chain-of-thought, tool use built into the model. This works — until you need the agent to follow YOUR process.

Each phase made the reasoning better. None of them solved the configuration problem: how do you tell the agent what YOUR methodology is, without hand-coding it into application logic?

Peri identifies a fifth phase: skills. We agree — this is the phase that matters. Not because it makes the model smarter, but because it changes who can define agent behavior and how that behavior gets packaged, shared, and maintained.

The parallel to programming languages

The agent architecture evolution isn't novel. It mirrors a pattern we've seen before in programming itself. Each generation solved the previous one's pain point, and the winning move was always the same: raise the abstraction level.

  • Assembly → Monolithic prompts. Total control, total fragility.
  • C / structured programming → Router architectures. Modular, but still hand-crafted.
  • OOP / frameworks → Multi-agent supervisory. Abstractions, but complexity explodes.
  • Rails / Django → Skills. Declare WHAT, the framework handles HOW.

We're at the Rails moment. The shift from “build everything from scratch” to “configure what you need” changes who can participate. Rails didn't make web development less powerful. It made it accessible to a thousand times more people. When a domain expert can author a skill in markdown instead of orchestrating agents in Python, the same democratization happens for AI.

What makes skills different from prompts

Skills look like prompts. They're text that tells an LLM how to behave. However, four distinct properties set them apart in practice.

1. Version-controlled

A SKILL.md file lives in git. You can diff it, review it in a pull request, revert it when something breaks. You can blame a specific line to see when a methodology changed and who changed it. A prompt embedded in application code is none of these things cleanly.

2. Human-readable

A compliance officer can read a skill file and understand what the agent will do. They can review it, suggest changes, and approve it — in plain English. Skills bring agent behavior into the review workflows that organizations already have.

3. Portable

A skill written for one agent platform can work on another. It's methodology, not implementation. The methodology outlives the infrastructure.

4. Composable

Progressive disclosure keeps skills lightweight. The agent starts with just the name and description of each installed skill — roughly 100 tokens each. It loads the full skill body only when the conversation makes it relevant. This means you can have 20 skills installed without impacting performance on unrelated tasks.

The override model

Skills get interesting when you combine community best practices with your organization's specifics. The override model makes this clean: install a marketplace skill, then layer your customizations on top.

---
import: deal-triage
---
# Acme Sales Process

Our sales cycle is 45 days for mid-market, 90 for enterprise.

## Staleness thresholds by stage
- Prospecting: 7 days
- Qualification: 10 days
- Needs Analysis: 14 days
- Proposal: 14 days
- Negotiation: 21 days

## Enterprise exceptions
- All thresholds get 2x multiplier
- Decision maker must be identified by Proposal stage
- Flag any enterprise deal in Proposal without a
  contact with Role = "Decision Maker"

You inherit the community's best practices — the general structure of deal triage. You add your specifics. When the community skill updates with better methodology, you get the improvements. Your overrides stay.

This is the same model that made Kubernetes Helm charts work, that made Terraform modules composable, that made Rails engines useful. Sensible defaults you can override.

The marketplace implication

If skills are portable, version-controlled, and composable — they're shareable. This is the npm/PyPI moment for agent behavior.

Within a team

Senior analysts encode their methodology as skills. Junior analysts get the benefit immediately. The skill IS the training material.

Across an organization

The sales team's deal triage skill. The finance team's reconciliation skill. The compliance team's audit skill. Shared internally, each with team-specific overrides.

Across the industry

Published to a marketplace. Rated by users. Forked and improved. The best threat triage methodology rises to the top. Community-driven quality at scale.

We're not just versioning code anymore. We're versioning institutional knowledge. The skill file that encodes “how Acme handles enterprise deal qualification” is a durable artifact that captures years of hard-won experience in a format that both humans and agents can consume.

What this means for 2027

Reasoning models will keep improving. Context windows will keep growing. New protocols will emerge and stabilize. None of this changes the fundamental problem: the model doesn't know your business. It doesn't know your process.

The organizations that are documenting their workflows as skills TODAY are building a durable asset. A markdown file that encodes your deal triage process works with Claude today and whatever model ships in 2028.

The markdown files aren't just documentation. They're the portable, human-legible memory of how your business operates — ready for whatever reasoning layer comes next.

The assembly-to-Rails arc took decades. The prompt-to-skills arc is happening in three years. The lesson is the same: the teams that move to higher abstractions first don't just move faster. They build assets that compound.