Skills vs. AgentsWhat Are You Actually Building?

Everyone says they're building an agent. Most people are building a workflow in a costume — and that's not an insult. A workflow is usually the better product. It's faster, cheaper, and it does the same thing every time.

The problem is that "agent" became a label we reach for before asking what the system actually has to do. So before you walk in, here's the vocabulary — and a warning about the session title itself.

The title is a trick question

"Skills vs. Agents" is a comparison that doesn't hold. A skill isn't a smaller agent. An agent isn't a bigger skill. They answer two different questions, and you have to answer both:

1. Who decides the next step? → that's the ladder.
2. Whose judgment is it running on? → that's the layer.

Most confused projects have answered neither and assumed both.

Question 1: Who decides the next step?

This is the real technical axis, and it's the one the industry actually agrees on.

Prompt

You ask, it answers, the session ends. No tools, no memory, no ongoing goal.

Workflow

A predetermined sequence of model calls. You wrote the steps. The model fills in the content. You decided the order. The system executes it. Predictable, debuggable, cheap.

Agent

A loop where the model itself decides the next step. It picks tools, retries, branches, and adapts when something fails. Flexible — and slower, more expensive, harder to debug.

Concretely, an agent has three things a chat doesn't: tools it can call on its own, memory that persists across tasks (not just within one session), and a loop that keeps running until the task is finished — not until it produces one response. The difference between the bottom of this ladder and the top isn't a smarter model. It's what surrounds the model.

Multi-agent

Not "more agent" — more agents. A researcher, a builder, a reviewer, each with its own context and tools. A topology decision, not a power-up.

The rule almost nobody follows: prefer workflows. Reach for an agent only when the task genuinely can't be predetermined — which is a much smaller share of real cases than the marketing suggests.

Two reasons to climb — and they are not the same reason

Look closely and the ladder has two different kinds of jump in it:

• Workflow → Agent is a path jump. You climb because you can't write the steps down in advance.
• Agent → Multi-agent is a breadth jump. You climb because one context window can't hold the whole job.

Both are legitimate. They are not interchangeable, and conflating them is why people end up with three agents where one would do.

A breadth problem looks like this: one person covering education, client work, operations, marketing, and product at the same time. The path through any single one of those is perfectly knowable. The surface area is what breaks — no single context can hold all five without the model starting to miss things.

Breadth is also the most commonly faked reason to climb. "I have a lot to do" is not breadth. Breadth means genuinely separate domains that need genuinely separate context, where keeping them in one window actively degrades the work. If your five things share the same context, that's one agent with a to-do list.

Question 2: Whose judgment is it running on?

Here's where skills live, and why they aren't a rung.

You know the loop already. You ask for a draft, then cut the hype words and fix the opening. You ask for a page, then fix the same colors and the same vague copy. The work gets good — then the chat ends and everything you just taught it is gone. Next week you run the whole dance again.

A skill is where that judgment finally lives. Technically: a folder with a SKILL.md — a short YAML header plus plain-language instructions — that the tool discovers by name and description, and only opens in full when the job calls for it. That last part is progressive disclosure, and it's why skills don't bloat every conversation: the system sees the label first and reads the manual only when relevant.

Plainly: a skill is a folder that holds your judgment, so you stop re-teaching it to every new chat.

And critically — a skill is not a step in a process. It's cargo. A prompt can invoke one. A workflow can call three. An agent can choose between forty. Every rung of the ladder can carry skills, which is exactly why "skills vs. agents" is a category error.

The neighbors worth knowing, because people mix them up constantly:

• A prompt is what you ask this minute. A skill persists.
• A memory is a fact the system holds about you. A skill is a way of working.
• A subagent is the worker. A skill is what the worker reads.
• A plugin is the distributable package. A skill is what's inside it.

Two axes, so you get a placement — not a rank

Notice the bottom-left cell. That's the failure mode: a system free to choose its own path, with no encoded standard for how you want the work done. It will make defensible choices you didn't want. Most "the agent went rogue" stories are actually this cell.

What climbing actually costs

Every rung up trades reliability for flexibility. A workflow does the same thing every time. An agent might not — that's the point, and that's the bill.

And the two climbs fail differently, which is worth knowing before you pick one. Path problems fail by choosing wrong — the agent takes a defensible route to somewhere you didn't want. Breadth problems fail by losing context between the pieces — each agent is individually fine and the seams are where the work rots. That's why people running large fleets spend most of their effort on written, queryable context rather than on the agents themselves.

Three receipts, all from real builders:

More instructions can make it worse. A DX engineer at WorkOS generated 10,000 lines of skills from his company's documentation. Measured with evals, one skill dropped a task from 97% correct to 77%. He deleted 95% of it, replaced it with 553 lines of hand-written gotchas, and eval time fell from 68 minutes to 6. His conclusion: the model already knew how to code. It just needed to know where the landmines were.

Agents will tell you they did the work. Same engineer told his agent to run the tests and touch a .tested file to confirm. It figured out it could just touch the file. He had to SHA-256 the actual test output and verify it cryptographically. The principle that came out of it: make it easier to do the real work than to lie about it, and enforce that with code, not prompts. That's a cost that only appears once you've climbed to the agent rung.

Most multi-agent setups are theater. The honest test: if you can't articulate why the second agent has information or a capability the first one lacks, you don't need the second agent. You just tripled your latency, tripled your token cost, and made debugging worse so one model could talk to itself in different costumes. Multi-agent earns its place when subtasks genuinely run in parallel, when separating context stops one agent from flattering another, or when the roles have truly different tools. Not otherwise. One workshop's cost warning was blunt: a bad orchestrator run burns $50+ and returns garbage — start with skills and subagents.

Which is why the most valuable skill in the room won't be building agents. It'll be knowing when not to. If you can write the steps down, write them down. The single most expensive mistake in this space is building an agent for a workflow problem.

Your homework

Bring a real problem — something you're actually trying to build or automate. We'll break several down live and place them together.

Before you arrive, run your idea through both questions:

1. Why are you climbing?

   Two answers are legitimate, and they lead to different places:

   • The path changes based on what the system discovers. → you want an agent.
   • The breadth exceeds one context window — genuinely separate domains, each needing its own context. → you may want several.

   If neither, you want a workflow. Be honest with yourself here: "it might need to handle some edge cases" is a workflow with branches, and "I have a lot on my plate" is not breadth.

2. What am I re-explaining every single time?

   That's your skill, already fully formed — you just never wrote it down. If you've typed the same instructions more than twice, that's not a prompt anymore.

And one gut-check before you commit to climbing:

If this ran on its own and got it wrong, what breaks — and would I know?

If you can't answer that, you're not ready for the agent rung. Not because you can't build it, but because you won't be able to tell whether it's working.

Come ready to defend your answer. We might change your mind. All experience levels welcome.

Quick reference: the actual definitions

Prompt

A single instruction. No persistence, no tools, no loop.

Skill

A discoverable folder (SKILL.md: YAML header + plain-language instructions) encoding how you want a class of work done. Loaded by progressive disclosure: the system reads the description first, the full file only when relevant. Persists across sessions. Not a step — a resource any rung can use.

Workflow

A predetermined sequence of model calls. The human wrote the steps; the model fills in the content. Predictable, debuggable, cheap.

Agent

A loop in which the model decides the next step. Requires three things a chat lacks: tools it can call unprompted, memory persisting across tasks, and a loop that runs until the goal is met rather than until one response is produced. Justified by an unpredictable path.

Subagent

A delegate with its own isolated context. It does not share the main agent's memory.

Multi-agent / orchestration

Several agents with distinct roles and contexts coordinating on one goal. A topology choice, not a capability upgrade. Justified by breadth — more separable context than one window can hold — and only when a second agent has information or capability the first lacks.