Every agent I have put into production started the same way: connect it to everything. Snowflake MCP, dbt MCP, GitHub MCP, a few internal servers. It works in the demo. Then you look at the token bill and the first thirty percent of every turn is tool definitions the agent will never call.
Tools are capabilities. Skills are procedures.
A tool is a function the agent can call: run this query, open this PR. A skill is a file the agent reads that tells it how we do things here: which dbt layer a model belongs in, how tests are named, what a good PR description looks like. Tools are loaded up front because the runtime needs the schema. Skills are loaded when the task needs them.
That difference is the whole cost story. On the Zendesk Data Platform we moved our conventions out of system prompts and into a versioned skills directory. The agent starts with a short index of skill names and one-line descriptions. It loads the full skill only when it decides the task calls for it.
What changed
- Context per run dropped, because the agent stopped carrying every convention for every task.
- Behaviour became reviewable. When an agent does something odd, the answer is in a file a human wrote, not buried in a prompt.
- Onboarding got easier. New engineers read the same skills the agents do.
Where tools still win
Anything that touches a live system stays a tool. Skills should never contain credentials or side effects. The pattern that has held up: a small, stable tool surface, and a growing library of skills that describe how to use it well.
The failure modes to design for
Two show up in the security literature and both apply to skills as much as tools. A rug pull is a skill that changes after you approved it; pin versions and review diffs. Shadowing is a skill whose instructions quietly override another's; keep skills narrow and never let one skill describe another's job.
If you take one thing from this: your agent's context is a budget, and skills are how you spend it on purpose.