Stop Building Agents. Build Skills.
The agent is a loop. The skill is the product. Stop investing in the wrong layer.
Every team I have talked to in the last six months is building an agent. Almost none of them are building skills. The ratio is roughly fifteen to one, and the gap is the reason most of these projects will be rewritten inside a year. The agent is the part that looks impressive in a demo. The skill is the part that survives the second model upgrade, the second framework switch, and the second time a senior engineer leaves. One of these things you should be investing in, and most teams are picking the wrong one.
The architectural mistake is easy to make because the words are loaded. “Agent” sounds like the system. “Skill” sounds like a feature. The instinct is to spend engineering hours on the thing that sounds like the system and treat the features as cheap content somebody can fill in later. That instinct is exactly backward, and the cost of getting it wrong only shows up when the model under the agent changes, or the framework changes, or the loop pattern itself changes, which in the current ecosystem is roughly every quarter.
Look at what an agent actually is. Strip the marketing off any production system that calls itself agentic and you find the same skeleton: a loop that calls a model, parses the response, executes any tool calls, feeds the results back, and exits when the model says the work is done. Variations exist around how the loop manages state, how it handles retries, how it composes plans, but those are tactical choices on top of a pattern that fits on a page. The loop is not where your competitive advantage lives. The loop is where your competitive advantage gets written and rewritten as the field moves.
The skill is the opposite. A skill is the encoded knowledge of how a specific job gets done in your specific environment. How your team writes incident postmortems. How your billing system rolls forward a subscription that hit a card decline. How your sales team scopes a contract before it goes to legal. How your support engineers triage a Sev 2 against a Sev 3. That knowledge took years to accumulate. It lives in your senior people, in your Confluence pages nobody reads, in the Slack scrollback from the last time something broke. Packaging it as a skill is the act of moving it out of those places and into a format an agent can use today and a different agent can use tomorrow.
That portability is the part the field is sleeping on. A skill written against the Claude Skills format is a folder of markdown and optionally some scripts. The format is small enough that translating it to whatever Anthropic’s competitors ship next quarter is a half-day exercise, not a rewrite. The agent loop that consumes the skill might get replaced four times in the next eighteen months as the frameworks shake out. The skill itself, if you wrote it against the actual workflow and not against the framework’s idioms, survives every one of those replacements.
The team I am running has tested this directly. We have rebuilt the agent layer twice in the last nine months. Once when we moved off a vendor-hosted runtime to a self-hosted one, once when we swapped the underlying framework to get better tracing. Both rewrites took less than a week. The skills moved across unchanged. The reverse experiment, where we tried to keep one agent and rewrite the skill collection inside it, took six weeks the one time we did it and produced worse results than what we had started with. The economics are not subtle.
The complication, and the reason teams do not arrive at this on their own, is that building skills first feels slow. You spend two weeks writing a skill that documents how a workflow runs, and at the end of those two weeks you do not have an agent. You have a folder of markdown. The pull toward the agent is the pull toward something demoable, something a stakeholder can see moving on a screen, something that produces a Slack thread with screenshots. The skill produces none of that until it is mounted into a loop, and even then the visible artifact is the loop, not the skill underneath it.
The honest counterargument is that not every workflow deserves to be a skill. Plenty of agent work is one-off, exploratory, glue between two systems that will not exist in six months. Writing those as skills is over-engineering, and the team that tries to formalize everything is going to drown in a folder of half-finished SKILL.md files that nobody trusts. The judgment call is which workflows are durable enough to encode and which ones should stay in the loop as inline instructions. The rough heuristic I have landed on is that anything you have explained more than twice to a teammate is already a skill in disguise, and the act of writing it down is just making the existing knowledge legible to the agent.
The deeper reframe is that the agent is infrastructure and the skill is product. Treating the agent as product is the same category error as treating Kubernetes as product. The orchestration layer matters, the choices it makes have real consequences, and it is worth getting right, but the thing your customers or users actually care about is the work that gets done on top of it. Nobody buys a Kubernetes cluster. They buy what runs on it. Nobody is going to buy an agent loop. They are going to buy the collection of skills that the loop happens to execute, and the loop is going to be the cheap, replaceable substrate that makes those skills run.
What does it look like to actually build this way? It looks like a repository structure where the skills directory is the part with the most commit activity, the most code review, the most test coverage, and the most attention from senior engineers. It looks like a CI pipeline that lints skills the way you would lint code, with the description field validated against an LLM-as-judge to confirm it triggers correctly on representative prompts. It looks like a versioning scheme for skills that lets you ship a v2 without breaking the agents that pin to v1. It looks like an internal review process where shipping a new skill goes through the same gates as shipping a new microservice, because in any system that takes this seriously, that is exactly what it is.
The agent, in that world, is the smallest reasonable amount of code that loads the skills, runs the loop, handles the edges, and exits. The agent is something a competent engineer writes in a week. The skills are what the company spends years building. The investment ratio inverts, and the surface area of the thing that has to change every time the model improves shrinks to the part nobody is emotionally attached to.
This is the architectural shift the next year is going to force. The teams that get there early will have a portable, composable library of capabilities they can run against whatever the best frontier model is on any given Tuesday. The teams that stay in the agent-first mindset will spend the next year rewriting their loop every time the framework landscape shifts, and they will end that year exactly where they started.
Stop building agents. Build skills. The agent is the part you throw away.
If this was useful, forward it to one engineer who needs less noise in their feed.