Skills vs. Tools vs. Fine-Tuning: Where Each Actually Belongs

Three ways to change what an agent does, at three different layers

"Just have the agent do X differently" is not one decision, it's a choice between three genuinely different mechanisms that happen to produce similar-looking results from the outside: write a skill (change what's in context for this request), add a tool (give the model something new it can actually call), or fine-tune (change the model's weights). They fail differently, cost differently, and iterate at different speeds, and picking the wrong one for a given problem is a common, avoidable source of wasted effort.

This follows directly from the boundary discussion in the skills architecture piece: that article establishes that a skill is not a tool and not a fine-tune; this one is the decision framework for choosing correctly among the three in the first place.

What each mechanism actually changes

A skill changes what text is in the model's context window for a given request. It's instructions -- methodology, style, a checklist, a format to follow -- and the model still has to reason its way through applying them fresh, every time, using whatever general capability it already has.

A tool gives the model a function it can call: a schema describing inputs and outputs, and real code behind it that executes, reads state, or reaches an external system. A tool doesn't tell the model how to think; it gives the model something to do that the model itself cannot do by generating text -- query a database, run a test suite, fetch a live price.

Fine-tuning changes the model's weights via a training run, so the behavior is baked in before any request-time context exists at all. Nothing needs to be in the prompt for a fine-tuned behavior to show up; that's both the appeal and the cost.

Comparison

The failure-mode row is the one worth sitting with. A skill fails softly -- the model drifts from the instruction, and the fix is a clearer instruction, reviewable the same day. A tool fails loudly and locally -- a bad schema or a timeout is a normal engineering bug with a normal engineering fix. A fine-tune fails quietly and broadly -- a regression shows up as a shift in behavior on inputs nobody thought to eval, discovered well after the training run that caused it, which is exactly why it should be the last resort, not the first idea.

Worked example: teaching an agent to write better commit messages

This is a skill, not a tool or a fine-tune. There's no external state to fetch and no execution to perform -- the entire job is judgment about phrasing, tense, and what belongs in a commit body, applied to a diff the model can already see. A tool would be the wrong layer because there's nothing to call; a fine-tune would be enormous overkill for a behavior that a well-written instruction handles on the very next request, reviewable as a plain-text diff before it ships. This site's own commit-message-writer skill is exactly this case.

Worked example: checking whether a dependency has a known CVE

This is a tool, not a skill or a fine-tune. The model cannot know, from its own weights or from any instruction text, whether left-pad@1.3.0 has a disclosed vulnerability filed yesterday -- that's live external state, and no amount of in-context instruction manufactures data the model was never given. A skill can and should tell the model how to interpret the tool's output (see this site's dependency-vuln-auditor skill for exactly that division of labor), but the lookup itself has to be a real function call against a real vulnerability database.

Worked example: a support bot that must always reply in a rigid 40-token JSON schema at 500ms p99

This is the case fine-tuning actually wins. A skill instructing "always respond in this exact JSON shape" competes for attention with every other instruction in context and will occasionally drift under load -- acceptable for a code-review methodology where a human reads the output, not acceptable when a downstream parser throws on any deviation and the volume is high enough that "occasionally" becomes a real incident rate. A tool doesn't apply at all here since there's no external action to take. Baking the output format into the weights removes it from the in-context instruction-following budget entirely and, at sufficient request volume, is cheaper per request than re-sending a long formatting instruction on every single call. This is the narrow case the comparison table's fine-tune row describes: high volume, low latency tolerance, a format rigid enough that a training run's fixed cost is worth paying once.

The decision in one pass

Ask, in order: does this require calling something external or executing real code? If yes, it's a tool, possibly paired with a skill that tells the model how to use it well. If no -- is the required behavior expressible as instructions a capable model can follow, and does it need to be revisable on a day-to-day basis? If yes, it's a skill. Only when a skill has demonstrably failed to produce reliable behavior at the volume and latency the product actually needs -- not preemptively, not because fine-tuning sounds more rigorous -- does the answer become fine-tuning.

A hybrid that shows up constantly: skill plus tool together

The three-way framing can make it sound like every behavior is purely one of the three. In practice the most common real design is a skill that governs how to use a tool the runtime already has, rather than a skill replacing a tool or a tool replacing a skill. A dependency-scanning tool returns a raw list of CVEs with severity scores; a skill sitting on top of it decides which of those findings are worth surfacing, in what order, and with what framing -- exactly the split described in the CVE worked example above, where the tool supplies facts the model cannot generate and the skill supplies judgment the tool cannot make. Recognizing this hybrid as its own common case, rather than forcing a single choice among the three, is usually what separates a clean design from one where a tool's raw output gets dumped on the user unfiltered, or where a skill invents plausible-sounding CVE data because no tool was wired in to supply the real thing.