Skill hydration: from one giant agent to many ephemeral specialists

2026-04-30

by Uri Walevski

There's a natural temptation to build one agent that can do everything. Give it every tool, wire up every integration, load every skill, and let it figure out what it needs at runtime. It's a clean mental model. One agent, one identity, one place where all the capabilities live.

It works, for a while. Then the agent gets heavy.

The prompt grows. Tool schemas pile up. Instructions start competing with each other. VM provisioning ends up in the default path of tasks that have nothing to do with code. The agent spends more of its context understanding what it could do than focusing on what it actually needs to do right now. By the time it picks a tool, the original task has been buried under three layers of self-orientation.

Gradual tool discovery softens this, but it doesn't change the underlying shape of the problem. The question isn't only "how does the agent find the right tool". The question is why one long-lived agent is the container for so many unrelated jobs in the first place.

Imagine a single context window that has to reply to a message from your wife and also debug a failing GitHub pipeline. There's no version of that prompt that makes sense. The tone, the tools, the priors, the failure modes, none of it overlaps. Introducing threads inside one agent doesn't really fix it either. Each thread still inherits the same bloated system prompt, the same tool surface, the same identity, the same accumulated history. The task gets a sliver of attention inside a body built for a hundred other things.

A more honest pattern is a lot of ephemeral agents, each hydrated for one task.

Not weak agents. Not stupid chatbots with no abilities. Real agents. Claude Code-level agents that can use tools, run code, provision a VM, browse, call APIs, edit files, and complete the work end to end. The difference isn't capability, it's scope. They don't need to carry every possible capability all the time. They need the right ones, right now, and the freedom to disappear when the job is done.

The skill becomes the entry point. A skill is a packaged way to do some class of work: instructions, tools, scripts, conventions, the gotchas someone already hit so you don't have to. When a task arrives, you spin up an agent hydrated with the skill that matches it. That agent exists for that job. One for reviewing a PR. One for deploying a repo. One for diagnosing production logs. One for preparing a launch. One for publishing a package. One for posting to Reddit. Each one starts with the right context, a narrow tool surface, and no obligation to also be your therapist or your build system.

The downstream effects are practical, not philosophical. Less tool confusion, because there are fewer tools competing for the model's attention. Less prompt bloat, because the system prompt only describes the job at hand. Less permanent runtime, because nothing has to stay warm to maintain an identity that wasn't doing anything anyway. The cost of an agent collapses to the cost of the task it was created for.

This also matches where skills seem to be going. Skills are becoming abundant, portable, often open source. They live in repos, package managers, directories, shared links. People publish them the way they used to publish small libraries. If skills are cheap and plentiful, the bottleneck stops being "what can my agent do" and becomes "how fast can I turn a dormant skill into a working agent right now, without manually building a new bot around it". That step, taking something packaged and inert and standing up a capable, scoped agent on top of it, is what skill hydration actually is.

In prompt2bot, this is what the Talk to Skill page does. You point at a skill (a repo, a package, a URL) and an agent spins up already hydrated with it, ready to work. No configuring a bot, no naming it, no wiring tools by hand. The same infrastructure now powers the talk-to-skill flow on tankpkg.dev and agentskills.co.il, so a skill you find in either directory is one click away from a working agent.

None of this kills the long-lived agent. A personal assistant, a support agent, anything that depends on memory and continuity and a stable identity, still wants to be a single ongoing thing. That's a real category and it isn't going away.

Most agent work isn't that category. Most agent work is a task that needs a strong temporary worker with exactly the right skill, and nothing else.

← All posts