Skills, Agents, Loops, Graphs: The Four Words Everyone Is Throwing Around

A junior engineer on my team asked me last week if we were "behind on graphs." He had been reading the feeds. First everyone was building skills, then agents, then loops, and now apparently graphs, and he was worried we skipped a step. I told him we didn't skip anything. We've been running all four of these for years. Nobody handed out names for them until this year.

That conversation is why this article exists. If you've been reading AI engineering content lately, you've hit these four words stacked together like a maturity ladder you're supposed to be climbing. There is no ladder. There are four small ideas, most of them old, that got new names because a lot of people started writing about the same thing at once and nobody agreed on vocabulary first.

Quick definitions before we start, including where each one usually lives:

Skill is a written playbook for one task. It is portable on purpose: a personal skill works across projects, a workspace skill lives with the team and only applies there. Same format either way. The point is reusable procedure, not a one-off chat instruction.
Agent is something that owns a goal and makes decisions to get there. It usually lives in a repo: the boundaries, tools, and context for that codebase sit next to the code it is allowed to touch. An agent without a home tends to mean an agent without a leash.
Loop is the part that repeats: try, check, try again. It is not a separate file you install. It is the runtime pattern around the work, usually inside an agent or a job runner, with a wired stop condition so the repeat cannot outrun the budget.
Graph is the wiring between multiple pieces: who runs after whom, and what happens when something fails. It sits above the individual agents and skills. Think pipeline, workflow, or orchestration config that spans steps, handoffs, and failure paths, not a single repo's playbook.

That's it. Everything below is just those four ideas with the details filled in.

Build them, don't just name them

If you want ready-to-use builders for all of this, grab anipublik/everythingAI. It's a living collection of portable playbooks for skills, agents, loops, and graphs: load a folder into your AI tool of choice and build the real artifact instead of re-explaining the same discipline from scratch. Check that repo for the AI builders you can actually use.

Skill: it's a runbook

If you have ever written a runbook, you have written a skill. It has a name, a note about when to use it, and the steps to do the job right. The only new part is that the reader is a model instead of the new hire, and the "when to use it" line matters more than it used to, because the model picks which playbook to reach for based on that line alone.

The word gets oversold as "giving the AI a new capability." It isn't a capability. The model could already write a report or parse an invoice. What the skill does is make it do that job the same way every time: your format, your rules, your edge cases handled. Consistency is the product, not capability. Anyone who has watched two engineers follow the same runbook and get the same result already understands why this matters.

The part people skip

The trigger line decides everything. A skill with great steps and a vague "helps with documents" description never gets picked up. Write the trigger the way a real person would ask for the job, including the lazy phrasings: "get the numbers off this" fires more often than "extract structured line items."

Agent: it's a job description with a leash

A skill has no responsibility. It runs when called and stops. An agent is different because it owns an outcome: it decides which skill to use, in what order, whether the result is good enough, and whether to keep going, stop, or hand the problem to a person. That decision-making is the whole difference. Everything else is packaging.

If you have ever written a job description and an approval matrix for a new role, you already know how to design an agent. Same questions, same order:

What outcome does it own? One sentence. If the sentence has two unrelated outcomes, it's two agents.
What is it allowed to do on its own, and what needs sign-off first?
What must it never touch?
When does it stop trying and hand off, and to whom?

The hype version of this word is "autonomous AI." Drop the word autonomous. A useful agent is a decision-maker with a leash, and the leash is the design. An agent whose boundaries fit in one sentence about vibes is not an agent, it's an incident with a date already on the calendar. The teams doing this well spend most of their design time on the boundaries, not the prompt.

Loop: it's a while loop, and most "loops" aren't

Strip away everything and a loop is: do something, look at what happened, let that change what you do next, repeat. You have written this a hundred times. The only new part is that the decision in the middle is made by a model instead of an if statement.

Here is the one test that matters, and it's the test most of the scary "agentic" stories fail. Does what happened in round one change what happens in round two? If yes, you have a loop. If every round does the same thing no matter what the last round returned, you have a repeat button with branding.

Real loops

Agent reads a failing test, changes the patch because of it, runs again
Draft, score it, revise based on the score, score again
Check system state, nudge it toward target, check again

Not loops

Running the same prompt five times in parallel and picking the best one
Retrying an identical API call after a timeout
A pipeline that runs the same steps every night

The right column isn't wrong to build. Parallel sampling and retries are useful patterns. They just aren't loops, and calling them loops leads people to design the wrong stop conditions for them.

Speaking of stop conditions. When you read a story about an agent that "wouldn't stop" and burned a pile of money overnight, pull on the thread and you almost always find the same thing: the stop condition was a sentence in a prompt, and nothing in the system ever actually checked it. I call that a named exit versus a wired exit. A named exit is a comment. A wired exit is a check that runs every round and actually halts execution. Every loop needs at least one wired exit that does not depend on the model's own judgment being right, usually a plain number: max rounds, max dollars, max time. If your safety net is "the model will know when to stop," you don't have a net.

Graph: it's a flowchart

When one worker isn't enough, you wire several together: this runs first, then this, branch here based on that, retry there, page a human if it all falls apart. Every engineer has drawn this on a whiteboard to explain a system to somebody. The AI crowd calls it a graph now, and "orchestration" when they want budget for it.

One support ticket, all four words in one picture. The dashed border is the graph. One of its boxes is an agent, because it owns a real decision. Inside the agent is its loop. The loop calls a skill for the one job it shouldn't reinvent each round. They were never four rungs of a ladder. They're four different sized questions about the same flow.

Look at where each word lives in that picture. Three of the four describe things nested inside one box of the fourth. That's the thing the maturity-ladder framing gets wrong. You don't graduate from skills to graphs. Any real system asks all four questions at once, about the same fifty lines of behavior.

And the failure modes of a graph are not new either. They are the same failure modes as any distributed system, because that's what a multi-agent graph is. Something claims ownership of a task and doesn't finish it, and nobody notices until a person goes hunting for the ticket that vanished. A handoff gets dropped between two workers and each one assumes the other has it. A retry cycle spans three boxes and nobody put a number on how many times it can go around. If you've carried a pager, you have already debugged every one of these. The boxes just have different names now.

Where the hype actually is

I'm not writing this to dunk on the vocabulary. Shared words are useful, and these four are fine words. The problem is a few specific claims that get repeated way past what they can support. Naming them so you can spot them:

"Agentic" as a magic adjective

A script that calls a model once and prints the answer doesn't become an agent because the landing page says agentic. The line was never the word. It's whether the thing owns a goal across multiple steps and can decide on its own to continue, stop, or ask for help.

More agents = more intelligence

A ten-box graph doesn't reason better than a two-box one. It has eight more handoffs that can silently drop. Add a box when a step genuinely needs different authority or context, not because the diagram looks more impressive in the deck.

The runaway agent as emergent behavior

Almost never emergent. Almost always a stop condition that was written in a prompt and never wired to an actual check. That's not the machine developing a will. That's a missing if statement, same as it ever was.

Orchestration as a new discipline

Nodes, edges, branches, retries, and timeouts all existed long before anyone applied the word agent to software. The genuinely new part is that one box can now hold judgment instead of a fixed rule. That is a real change. It's a smaller change than the vocabulary implies.

What you already know that transfers

If you've shipped a retry policy, written a runbook, drawn a system diagram, or defined an approval matrix, you already have the instincts these four words are trying to name. The hard parts were always the same hard parts, and they did not change when the words did:

Wire the exits. A stop condition only counts if something checks it every round and can actually halt. Everything else is a comment mistaken for a safeguard.
One owner per decision. Five agents sharing a goal fails the same way a meeting with five owners fails. Everyone assumed someone else had it.
A budget that doesn't trust the thing it's guarding. Max rounds, max dollars, max time. A number that fires whether or not the model's judgment was right that day.
Say what it may not do. The difference between a useful agent and an incident report is usually one missing sentence about what it wasn't allowed to touch.

That's the whole map. Skill is the runbook. Agent is the job description with a leash. Loop is the while loop with judgment inside it. Graph is the flowchart connecting them.

Learn where each word sits, keep the discipline you already have, and the vocabulary stops being intimidating. It was never the hard part. Knowing when to stop, who owns what, and what happens when a step fails: that was always the hard part, and it still is. When you're ready to build any of them, start from everythingAI.