Skills Beat Tools

A few months ago, Every published an agent-native architecture guide that lays out a compelling vision of working with LLMs: Surface composable primitives and atomic tools, and let the agent build out emergent capabilities. This sounds compelling in the abstract, but since reading it, I’ve been thinking through how to make it work in practice. The idea of composable primitives implies a domain-specific vocabulary to design around. It suggests you need to think carefully about what your agent’s verbs should be, which conceptual actions map to which tools, and how to carve the problem space into the right atomic units.

But in reality, it seems like a combination of broad tooling and brute force is just as effective as that kind of careful conceptual design, if not more so. Consider the tooling that powers most effective agents today. Claude Code and OpenClaw aren’t that different under the hood - they can run shell commands and read and write files. With those primitives, they handle an enormous range of tasks - writing and running code, interacting with messaging systems, managing calendars and email. It turns out that “use the computer” and “edit files” already covers most of what a capable agent needs to do. My own agentic investigation work is built entirely on this existing capability set; I didn’t need to design a bespoke vocabulary for it.

This is likely the case across many more domains than we realize. So what are we really talking about when we talk about building agent tooling? The answer, I suspect, is token efficiency - specifically, the shape and location of the supporting data and infrastructure around a task.

Here’s what I mean. You could have a multimodal model do expensive vision processing on every document from scratch, or you could have it consume the outputs of a deterministic OCR pipeline. You could have the agent wade through your existing datastore, figure out the schemas, and work out the required transformations on the fly, or you could maintain a synchronized store already shaped for agent consumption. In both cases, the agent’s fundamental capabilities don’t change. What changes is the surface it’s working on.

Within this framing, there are really two paths to token efficiency. The first is a new tool that connects to existing resources in a way that shortcuts manual discovery and connection work (a specialized search interface, a custom CLI, an API wrapper). The second is a new resource, mapped to existing tooling, that shortcuts the need to figure out new functionality (documentation, restructured data, worked examples). One adds verbs; the other reshapes nouns.

It’s unclear to me which approach is better. So I ran a small experiment.

There are a lot of AI tools out there for sifting through academic literature (I wrote about a few of them last year). But I have a massive library of good research papers already pulled into Zotero, and it would be useful for background research and brainstorming if an agent could effectively search through them.

To evaluate potential approaches to this task, I had Claude Code generate a report on the role of complexity science in communication studies. This was a core part of my dissertation, so I felt like I was well positioned to evaluate the output quality. I gave Claude Code two resources for this task. The first was a purpose-built tool: a co-located index using LanceDB with markdown files for all my papers, standard RAG with an injected prefix providing paper metadata for each retrieved chunk, plus a tool to retrieve and read full papers as needed. The second was an agent skill, a detailed markdown file explaining how to navigate my existing Zotero library. It described the data locations and formats, searching instructions, and examples of common operations.

You can find the SKILL.md file here, if you’d like to use it for your own Zotero library.

Claude Code ran this task with both approaches in isolation, then I manually reviewed the resulting reports.

At a high level, the quality of these two approaches was comparable. Both produced comprehensive reports that cited the key literature, walked through a structured argument, and defined core concepts. The tool version even cited my dissertation, which gets ego points.

Read the tool version and skill version of these reports.

On closer inspection, though, the skill approach was better. Its report was longer, but not just for length’s sake; it cited more sources, followed a more natural progression from theoretical foundations to key empirical applications, and wrapped things up with a forward-looking survey of future work that the tool-based report lacked.

The efficiency story is more complicated. The skill approach had fewer overall turns (31 vs. 46), fewer tool calls (19 vs. 36), and 48% fewer total input tokens. By those measures, it was clearly more efficient. But the CLI-based tool’s query pattern hit the cache far more often, because it provided smaller, more incremental outputs. The skill approach tended to flood the context with data pulled in from the Zotero library in larger chunks. So while the skill was technically more efficient by raw token count, it was likely more expensive in practice - a tradeoff that could potentially be refined with better guardrails on the skill’s data retrieval patterns.

For this test case, the results clearly favor teaching an agent to use the tools we already have over building new specialized infrastructure. Writing a markdown file is much easier than building out a LanceDB index, and it produced better results.

How universally this applies is an open question. The existence of mature RAG systems at least implies there’s still a real need for specialized tooling in many contexts. But to the extent that the skill-based approach does generalize, it’s good news: Markdown files are cheap, portable, and easy to iterate on.

This will be the big question as the next generation of agent tooling takes shape: What is the right confluence of data, tooling, and agent adaptation required to maximize both performance and token efficiency?

We can sketch out where this might be heading. Every’s agent-native architecture guide describes a principle it calls parity, the idea that a converged set of verbs should serve both human-facing UI and agent-facing commands. If you take that seriously, the tradeoff I’ve been describing starts to dissolve. You’re not choosing between building new tools for the agent and teaching the agent your existing tools, because they’re the same.

Whether full parity is realistic remains an open question. We may always need some level of adaptation, in the form of agent-specific scaffolding, reshaped data, or specialized interfaces. But the more a workflow requires careful collaboration between humans and agents, the more desirable convergence looks. If an agent and a person are working on the same project, reaching into the same data, and handing tasks back and forth, the cost of maintaining separate interfaces compounds quickly.

The path forward likely involves less custom agent infrastructure than the current discourse suggests, and more thoughtful design of the surfaces that both humans and agents share. The tools might already be good enough, but the question is whether the rest of the environment is shaped to let them work.