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.

He was not alone in reading it that way. If you've been following AI engineering content lately, you've seen these four words stacked 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.

I know because I did the same thing a month ago. I wrote that prompting was obsolete and the leverage was in the loop. I still believe that about loops. What I would add now: the loop itself was not a discovery. Control loops, runbooks, approval matrices, and flowcharts were already how we ran production. We gave them AI-shaped names because the industry needed shared words. AI did not invent four new primitives. We renamed existing disciplines, and the work is still the same: knowing when to stop, who owns what, and what happens when a step fails.

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 clear boundaries.
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 an enforced 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.

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

A skill is a runbook with a trigger line. 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. Two engineers following the same runbook get the same result. That's the point.

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 boundaries

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.

Designing an agent means answering the same questions you'd put in a job description and approval matrix:

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 boundaries, and the boundaries are the design. An agent whose scope fits 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

At core, a loop is: do something, look at what happened, let that change what you do next, repeat. The pattern is familiar. 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've debugged every one of these before. The boxes just have different names now.

Where the hype actually is

Shared words are useful. These four are fine. A few claims get repeated past what they can support:

"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, nothing new under the hood.

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 transfers from ops work

If you've shipped a retry policy, written a runbook, drawn a system diagram, or defined an approval matrix, you've done versions of all four. The difficult parts did not change when the vocabulary 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.

Skill is the runbook. Agent is the job description with boundaries. Loop is the while loop with judgment inside it. Graph is the flowchart connecting them.

Know where each word sits in a real flow, and the vocabulary stops being intimidating. When to stop, who owns what, and what happens when a step fails: that is still where systems break. When you're ready to build any of them, start from everythingAI.