Peter Steinberger (@steipete) asked a deceptively small question: are we still talking loops, or did we shift to graphs yet. If you build with AI coding agents, that sentence is your whole roadmap for AI agent architecture. The agentic loop is what made agents feel alive. It is also what makes them wander, over-build, and produce work you have to babysit. The shift to graphs is not a framework fad. It is how an agent stops being a clever demo and starts being something you can trust with real work. Here is what the loop is, why it drifts, and what graph thinking, now serious enough to be called graph engineering, actually changes.
What the agentic loop actually is
Strip away the branding and almost every AI agent is one while-loop. The model looks at the goal and the current state, decides on a single action, takes it, reads the result, and goes back to the top. Think, act, observe, repeat. It keeps going until it judges the task done or hits a limit. This is the ReAct pattern, and it is genuinely why agents work at all: the loop is what lets a model chain twenty steps together instead of answering once and stopping.
That autonomy was the breakthrough. You stopped writing the steps and started writing the goal, and the loop filled in the rest. Every agent framework of the last two years is, at heart, a nicer wrapper around that one loop.
Why the loop wanders
The loop has one structural flaw, and it is the same trait that makes it powerful: the agent controls its own exits. Nothing outside the loop decides when to stop exploring, when to ask, or when a plan is good enough to act on. So a vague prompt like fix this bug sends the agent on a fifteen-file reading tour before it writes a line. A large task becomes a thirty-tool-call detour that quietly bloats the context until the session crawls. The agent builds three things you never asked for, because nothing in the loop told it to check first.
None of this is the model being dumb. It is the loop being unbounded. A process that decides its own stopping condition will sometimes decide wrong, confidently, and you find out only after it has made a mess. That is the tax of pure autonomy, and once you are shipping real work instead of demos, it is a tax you feel every single day.
What graph thinking buys you
A graph is the loop with the control put back in. Instead of one blob that runs until it feels done, you draw the work as nodes and edges: distinct steps, with explicit transitions between them. Some of those edges are gates. The agent cannot cross a gate until a condition is met, a check passes, or a person says yes. This is what people mean by moving from loops to graphs, and it is serious enough now that graph engineering is becoming its own discipline, with tools like LangGraph built entirely around it.
The payoff is not prettier diagrams. It is determinism where you want it and freedom where you do not. You keep the model's judgment inside a node and put your rules on the edges between nodes. Now the same run has checkpoints: a place to confirm scope before building, a place to refuse a dangerous action, a place to hand control back to you. The agent is still smart. It is simply no longer the only thing deciding what happens next.
You do not need a rewrite to think in graphs
Here is the part the framework debates miss. Thinking in graphs does not require you to throw out your agent and adopt a graph runtime. Most people reading this are not building an orchestration platform. They are running a coding agent like Claude Code or Codex and they want it to stop wandering. You do not need LangGraph for that. You need edges: a few control points bolted onto the loop you already have. The graph is a way of thinking first, and a framework only if you actually need one.
Your hooks are graph edges
This is the part most people have not noticed. A hook is code that runs at a fixed point in the agent's lifecycle and can change what happens next. That is an edge with a gate on it. So kitstarter's entire design is graph engineering applied to a coding agent, with zero graph framework. Three hooks, three gates:
UserPromptSubmit and can deny. It holds the agent at the first edge until you confirm what you actually want, so it plans before it builds instead of guessing.PreToolUse and returns allow, deny, or ask before a risky action. It is a gate on the edge into every tool call, the checkpoint the bare loop never had.Task boundary into every subagent, so spawning five agents does not spawn five unbounded loops.The loop gave agents autonomy. The graph gives them accountability. You want both.
The whole argument, in one line.
So, loops or graphs?
Both, and the framing is the answer. The loop is the engine: it is what lets the agent do multi-step work at all, and you are not removing it. The graph is the steering: the nodes and gates that decide where that engine is allowed to go. An agent with no loop cannot act. An agent with no graph cannot be trusted. So the honest answer to Steinberger's question is that the good setups already shifted. They just do not always call the edges graphs. Sometimes they call them hooks.
If you want that shift without building an orchestration layer, that is what kitstarter is: an ask-first clarity gate, a safety guard on every tool call, and rules that survive into subagents, installed as native lifecycle hooks for Claude Code and Codex. You keep the loop. You get the graph. And the agent stops being something you supervise and starts being something you can hand real work.
Common questions
What is an agentic loop? An agentic loop is the core pattern behind most AI agents. The model reads the goal and the current state, chooses one action, takes it, reads the result, and repeats, continuing until it decides the task is done. It is what lets an agent chain many steps together instead of answering once. It is also unbounded: the agent controls its own stopping point, which is why loops tend to wander.
What is the difference between an agent loop and an agent graph? A loop is one process that runs until the agent judges it finished, with no outside control points. A graph breaks the same work into explicit nodes and edges, where some edges are gates the agent cannot cross without a check passing or a person approving. The loop gives autonomy, the graph adds control, and the most reliable agents combine them: a loop for the work, a graph for the guardrails.
What is graph engineering? Graph engineering is the practice of designing an agent as a graph of steps and controlled transitions rather than one open-ended loop. Instead of letting the model run freely, you place explicit decision points, gates, and human-in-the-loop checkpoints on the edges between steps. Frameworks like LangGraph are built for it, but the same idea applies to a coding agent through lifecycle hooks, with no framework at all.
Do I need LangGraph to use graphs? No. LangGraph helps if you are building a complex orchestration system, but the core idea, adding control points to an otherwise free-running loop, does not require it. For a coding agent like Claude Code or Codex, native hooks give you the same thing: gates on the agent's lifecycle that confirm scope, block risky actions, and hand control back to you.
Give your agent edges, not just a loop
kitstarter installs the gates that turn a free-running loop into a control graph: ask-first clarity, a safety guard on every tool call, and rules that survive into subagents. For Claude Code, Codex, and Antigravity.