Building agents

When to write a Skill, and when to build an agent

There are two ways to give an agent new expertise. You can write it down as a Skill that any capable agent loads when it needs it, or you can build a domain-specific agent that does the work as itself. Most of the time a Skill is the right place to start. This article covers when it stops being enough, and what to do then.

Two ways to package expertise

A Skill is a folder of know-how: a SKILL.md file with the steps, decision rules and output format, plus any reference material, templates and scripts. A general agent such as Claude Code loads it when a task calls for it and works through it. The Skill runs inside that agent, with the agent's identity, tools and access, and usually with a person watching.

A domain-specific agent runs as itself. It has its own identity, its own tools and permissions, an owner, and an address that other agents and people can reach. It can keep memory across weeks, run on a schedule, and be given a budget and a way to stop it.

Skill

What it is: A method an agent loads
Runs as: The agent that loaded it
Access: Whatever its host has
Memory: The current task
When it runs: When someone asks
Changing it: Edit a file

Domain-specific agent

What it is: A specialist with a role
Runs as: Itself, with its own identity
Access: Its own credentials and limits
Memory: Builds up over time
When it runs: On request, on a schedule or on events
Changing it: A new version, tested and deployed

Start with a Skill

A specialized domain is not a reason to build a new agent on its own. The usual path works better:

Do the task once, successfully, with a general agent.
Capture the method that worked as a Skill: the steps, the checks, the templates and any scripts.
Use the Skill for a while, and change it as you learn.

A Skill is cheap to write and cheap to change, and every agent on your team can load the same one. A team that keeps a small number of agents and a growing library of Skills is far easier to maintain than a fleet of one-off agents, each with its own deployment, versions and permissions to look after.

When a Skill is no longer enough

Build a domain-specific agent when at least one of these becomes true.

Someone outside your trust boundary needs the result. Another company, another team, or an agent that cannot or should not run your method needs to send a request and get an answer back.
The work is an ongoing role. It owns something over time, such as brand health for a product, and needs memory that builds up: past analyses, learned exceptions and preferred sources.
It has to run when nobody is watching. It runs on a schedule or reacts to events, and nobody is there to start it or read the result as it is made.
It needs access the caller should not have. It uses its own API keys, a paid data source or private data. A Skill runs with whatever access its host has, so a Skill that needs secrets should become an agent.
Its output has to be accounted for. The result must be signed, audited or paid for, with a fixed input and output contract that is tested before each release.
It needs a stop switch of its own, separate from whoever happens to be using it.

A Skill shares the method, and an agent shares the result

The question of who needs the expertise is where most advice gets confusing. If many agents need it, should it be a Skill, because Skills travel well? Or an agent, because many callers need one address? The answer depends on whether the caller can, and should, run the method itself.

Inside one company, where every agent can load the Skill and is allowed to see the method, share the Skill. Each agent applies it with its own access, and nothing new has to be deployed.

Across a trust boundary, share an agent. The caller in another company should not hold your keys, see your private data, or run a method you do not want to hand over. It needs to send a request to an agent it can verify and get a result back that it can check. That is the case AgentMesh is built for: each agent on the network has a verified identity, its owner decides who can reach it and what it may spend, every message is signed, and one switch stops it.

Usually you need both

Building an agent does not retire the Skill. The agent keeps using the Skill for its method, so the know-how stays in one place and the agent's people can still read and change it. Often there is a second, thin Skill on the other side as well, one that teaches a person's agent when to call the specialist and what to do with its answer.

An example: a brand analyzer

What is needed	Build	Why
Audit our brand and produce guidelines, for our own team	A Skill	A method a person runs and judges, with the team's own access
Apply our brand to the page or deck I am working on	A Skill	It works on the file that is open, with a person watching
Keep a living brand bible, watch competitors, and send a weekly brand health report	An agent that uses the brand Skill	An ongoing role, with memory and a schedule
Read any company's brand from its website, for other companies' pipelines	An agent	Callers in other companies need the result, and it reaches outside sites

Two signs you chose wrong

A Skill that holds secrets, or calls paid services with the user's own keys, has outgrown being a Skill. Make it an agent with its own credentials and limits.
An agent that only one person calls, always with that person watching, with no memory, schedule or private access, is paying for deployments, versions and tests it does not need. Make it a Skill.

A simple rule: write a Skill by default. Build an agent when the result has to cross a trust boundary, when the work needs its own memory, schedule or credentials, or when someone must be able to account for it, pay for it or stop it on its own.