It's All Prompt

I've been chewing on this for a while and want to write it down: underneath, it's all prompt.

We went from LLM, to prompt engineering, to context engineering, to harness engineering, to "loop engineering," to "agent engineering." Every couple of months a new word shows up. But if you go back to basics, all of it solves the same idea. In the end it's always a prompt. What changes around it are the tools, the connectors, whether it keeps running until it finishes or not. The essence is the same.

What follows is how I bring that down to something practical.

The intuition

When I look at the things I work with every day (a one-off prompt, a skill, a routine, a tool, an agent) my sense is that they're all the same thing. I don't mean they do the same thing, I mean they're made of the same material: an intention written in natural language, plus context, plus the ability to act.

The real difference isn't what it is. It's how it's packaged, when it runs, and what permissions it has.

The practical distinction

Concept	What it is	In one word
Prompt	The raw instruction. Manual, one-off, no structure. "Review this PR and flag bugs, edge cases, and naming."	Intention
Skill	The same prompt, but packaged: instructions, criteria, examples, supporting files, sometimes scripts. "PR review skill: checklist, team standards, comment format, severity."	Packaged intention
Routine	The prompt turned into a habit. It has a trigger. "Every time I open a PR, run this review."	Intention with a trigger
Tool	Not the prompt. The external capability. GitHub, Linear, Gmail, terminal, tests. "Read the diff, run specs, comment on GitHub."	External action
Agent	Prompt + tools + loop. It doesn't just answer: it acts, verifies, retries. "Review the PR, run tests, detect the failure, propose a patch, comment, create an issue."	Intention + tools + loop

In short:

• Prompt = intention.
• Skill = packaged intention.
• Routine = intention with a trigger.
• Tool = external action.
• Agent = intention + tools + execution loop.

Notice that a "prompt to review PRs," a "routine to review PRs," and a "PR review skill" can have the same content inside. What changes is the product around it: persistence, invocation, permissions, what context gets loaded, whether there's a UI, whether it keeps history, what outputs are expected.

Same PR review, depending on what I need:

• I want to paste it by hand: prompt.
• I want to use it the same way every time: skill.
• I want it to run on its own whenever there's a new PR: routine.
• I want it to read GitHub, run tests, and comment: agent with tools.

The question for classifying any idea isn't "what feature is this?" It's: does it need to run once, repeat, act on tools, or live as a reusable capability?

Why the semantic layer is misleading

If it's all prompt, why does the distinction matter?

Because the value isn't in the semantic layer. It's in the product layer. The user not having to think up the prompt, paste context, decide when to run it, or copy the result somewhere else. That's the whole difference between "I throw a prompt at a chat" and "I have an agent that solves this without me showing up."

The essence is the same. The work is in the packaging.

Where this gets crystal clear: eve

Vercel shipped eve ("Next.js for agents"). What caught my attention isn't the infra. It's that eve takes exactly this distinction and turns it into a filesystem convention:

agent/
  instructions.md   → the prompt (always-on system prompt)
  skills/           → markdown (the usual skills)
  tools/            → typed tools
  subagents/        → delegate to other agents
  evals/            → validate that the result is good
  channels/         → where it's accessible from (Slack, Linear, etc.)
  schedules/        → triggers

What I thought of as conceptual layers (prompt → skill → tool → subagent), Vercel packaged as folders. An agent is literally a directory. It's living proof that all of this is the same thing: when you bring it down to files, the "layers" are folder names.

The other side: the harness matters more than the model

Matt Pocock has a line that points the same way: everyone is obsessed with the model, with the Formula 1 engine, when the engine is only one part of the system. The harness (the prompts, the skills, the environment the model runs in) carries as much weight as the model, and on top of that you have far more control over the harness than over the model.

This closes the loop on "it's all prompt": if the essence of everything is prompt + context + tools, then what sets you apart isn't which model you use. It's how well you build the stuff around it. A good harness lets you run a cheaper model; a bad harness needs a more expensive model to compensate.

A word we don't need: "loop"

There's one thing I don't buy, and it's the "loops" hype that went viral around June 2026. To me we've overdone it.

First, because leaving an agent running until it gets something done isn't new. It's been around a while (Geoffrey Huntley's "Ralph loop" is from mid-2025). Selling it as a new technique is pretty marketing-driven.

Second, because the word is badly chosen. "Loop" sounds like burning tokens, like leaving something spinning. Pocock says it better himself: it's not a loop, it's a queue. You have a backlog of tasks and nodes that pull from it. That's how development always worked: there's a queue, someone adds things, someone resolves them. The idea of "a single infinite loop that does everything" looks nothing like how any team works.

And third, Claude Code already does that. If you specify a goal well with solid spec-driven development, the agent iterates on its own until it's done. You don't need to wrap that in a new word. I prefer "goal" over "loop" to explain it: it's what Codex uses, and it describes what actually happens better. You define the destination, not the number of laps.

The close

Your sense that "it's all the same" is correct at the semantic layer. It's all prompt: written intention, plus context, plus tools, sometimes plus a loop.

But that's not a reason not to build. It's exactly the opposite. Because the essence is simple and shared, what separates people who get a lot out of AI from people who get little isn't knowing the latest framework. It's knowing how to package the intention in the right form for each case, and how to build the harness around it.

The model comes from others. The prompt, and everything you build around the prompt, comes from you.