Here’s a claim that’s going to sound wrong for the first few seconds and then maybe right: the concept of “an agent” is a transitional one. Persistent agent identities — the research agent, the coding agent, the customer support agent — are going to look, in a few years, like the way “applications” looked in the 1990s before everything moved to the web. We treated them as the natural unit because they were what we knew how to build. The actual unit, the one that has structural durability, is the skill. Future systems will compose skills on demand based on the task at hand, with no fixed agent identity persisting across tasks.
The actual unit, the one that has structural durability, is the skill.
This is a forward-looking argument, not a description of where we are. Most systems today are organized around agents. The shift I’m describing is happening at the edges. But the direction it’s moving is, I think, fairly clear if you look at where the friction is in the current model.
Agents are units of identity; work is a unit of task
The friction is this: agents are units of identity, but real work is a unit of task. The two don’t line up. Consider a task that’s nominally “build a feature in this codebase.” Is this a coding agent’s job? It involves reading code, but also reading documentation, also possibly browsing the web for references, also possibly drafting an explanatory note for a PR, also possibly running migrations, also possibly debugging unfamiliar libraries. We end up cramming all these capabilities into “the coding agent” because we want one agent to own the task.
But the natural shape of the work is: load these specific skills for this specific task, execute, dissolve. There’s no reason a single coherent “agent” needs to exist for the duration.
The shift from “agent” to “task-scoped skill composition” is, in some ways, the substrate finishing what it started. Skills externalize procedure from prompts. Progressive disclosure loads them on demand. Once skills are first-class and composable, the persistent agent is just the envelope they happen to be running inside. You could just as easily compose them fresh for each task, drawing from a much larger skill library than any single agent could plausibly maintain in identity.
Let me describe what this looks like concretely.
What task-scoped composition looks like concretely
You give a task to the system: “Update the marketing landing page to reflect the new pricing tier, and notify the marketing team that it’s done.” A traditional agent design has to figure out which agent owns this. The “coding agent”? The “communication agent”? Some federated team of agents passing the task between them with elaborate handoff protocols? It gets awkward.
The skill-composition design treats this as: select the skills relevant to this task. Probably a read-and-edit-html skill, a git-commit-and-push skill, a slack-message skill, possibly a web-screenshot skill to verify the result. Compose them into a working graph for this task. Execute. Disband. The next task gets its own composition, drawing from possibly entirely different skills. There’s no “the agent” — there’s a procedural graph instantiated per goal, dissolved when done.
What persists in this design isn’t agent identity. It’s the skill library and the model. The model is the reasoning engine that interprets goals and composes skills. The library is the procedural knowledge. Identity is ephemeral — it lives for the duration of a task and then evaporates. This is structurally cleaner than the alternative because it matches the shape of work: most tasks are bounded, and the most natural unit of organization is the task, not the entity executing it.
There’s a precedent in the history of computing for this. Early operating systems were organized around persistent processes. Each process had a long life, a stable identity, a known role. As needs got more dynamic, the unit of organization shifted to functions and then to ephemeral microservices and then to functions-as-a-service. The function spins up to handle a request and disappears. There’s no persistent identity.
The function-style approach won where work was bursty, varied, and best organized around the request rather than the worker. Agent composition is heading the same way for the same reason.
Memory and coherence don’t require persistent agents
There are objections to this view worth taking seriously. The most substantial is around state: an agent that persists can accumulate context about the user, the project, the domain, in ways that ephemeral skill compositions can’t. This is a real concern, but I don’t think it’s actually a defense of persistent agents — it’s a defense of persistent memory, which is a separate concern. The skill-composition design preserves memory across tasks; what doesn’t persist is the identity of the executing system. The memory lives in the substrate, accessible to whatever composition needs it. You don’t need “an agent” to have memory. You need a memory system the skills can use.
The other objection is around coherence: a long-running agent develops a kind of consistency of approach that ephemeral compositions wouldn’t. This is partially true but largely confounded. The consistency that mattered in long-running agents was style and disposition — the way the agent communicated, the way it approached problems. That’s a thin layer; it can be captured in the small kernel that defines the model’s framing, and applied identically to every composition. The deeper consistency — across decisions and trade-offs — comes from memory, which (again) is preserved separately. The “agent personality” that seems coherent is largely a thin overlay over the underlying composition, and that overlay is portable.
What this looks like in practice is something closer to: a model with a small framing prompt, sitting in front of a large skill library, dispatched against tasks. Each dispatch loads the relevant skills, runs them, captures the results, updates memory, and ends. The thing that exists permanently is the library and the memory; the thing that exists for the task is the composition. The thing we used to call “the agent” — the entity that took the task — exists for the duration of a single run and then doesn’t.
The durable artifact is the skill library
The implication for builders is that the durable artifact you’re producing is the skill library, not the agent. If you build great skills — well-scoped, well-tested, composable, discoverable — they’re useful across many tasks, many users, many model upgrades. If you build a great agent, what you’ve actually built is a particular composition of skills for a particular envelope of tasks, and the moment the envelope shifts, the agent design has to shift with it. The investment in skills compounds; the investment in any single agent persona does not.
This is also a hint about where commercial value is going to land. Companies that build great skill libraries — institutional, domain-specific, audited, versioned — are building something durable. Companies that build great agents are, in this view, building shorter-lived products on top of more durable substrates. The substrate is where the value accumulates, and the substrate’s atoms are skills.
I want to be honest about how speculative this gets at the edges. The agent-as-unit is deeply entrenched and there are good reasons it might persist longer than I’m predicting — UX habits, user mental models, accountability frameworks that are easier when there’s a named entity to point at. But the underlying mechanics of the substrate are pushing toward composition, and the engineering pressures are pushing toward composition. The market may insist on calling things “agents” for a while after the actual systems are post-agent. We’ll have agent-shaped products on top of skill-shaped substrates, and eventually the products will catch up.
This brings the series to its concluding move, which is about what all of this implies for the future of AI as a category — not as a research field, but as a layer in the technology stack. That’s the next and final post.