From prompts to loops to graphs
Dennis Zaiser, technical founder
The way people work with coding agents has changed shape twice. First it was a prompt and an answer. Then it was a loop, with the agent acting, checking and acting again until it was done. Now the work is taking the shape of a graph, where steps, checks and decisions are arranged on purpose.
The prompt
The first pattern was simple. You described what you wanted, the model wrote code, and you pasted it into your project and ran it. The quality of the result depended on the quality of the prompt, and the context was whatever fit into the message.
Everything around the code was yours: finding where it went, running it, reading the error, writing the next prompt. You were the loop. That worked for snippets and small functions. It didn't scale to features, because the person doing the integration became the bottleneck.
The prompt also had no memory. Each request started from nothing but the text you sent, so every lesson had to be repeated in the next message, and nothing learned about the codebase carried over into the next day's work.
The loop
Agents that can read files, run commands and see the results changed that. The agent runs the loop itself: plan a step, act, look at what happened, decide the next step, and repeat until it judges the task complete. The person moved from typist to supervisor, and most coding agents work this way today.
The loop has limits that show once tasks grow. The agent decides when it is done, and its judgement of done is not the same as a passing test. It works in one context that fills up as it goes, so late steps carry the residue of earlier ones. There is no built-in place to stop for a person, so it either asks too often or not at all. And when a large task goes wrong, it tends to go wrong late, after much of the work is spent.
None of this makes the loop wrong. It makes it the right shape for a task one agent can finish in one sitting, and the wrong shape for work that spans planning, building, review and release, with people involved at some of those steps.
The graph
The next shape splits the work into nodes with clear jobs and arranges them on purpose. A graph is still made of loops: each agent node is an agent working in its own loop. What changes is that the structure around those loops is written down rather than improvised in every session.
Four kinds of node cover most of the work. An agent node performs a task. An approval waits for a person. A condition picks one branch or another based on the results so far. A loop repeats its body until its checks pass, or until a limit you set is reached. Edges give the order, and each node declares what it reads and what it must produce.
The idea itself isn't new. Build systems, release pipelines and business process tools have described work as graphs for a long time. What is new is that the nodes can now do work that needs judgement, and that makes the shape around them matter more, not less.
What the graph adds
Fresh context for each step. Each node starts with what it needs, not with everything the previous step happened to read. The build starts from the approved plan rather than from the whole planning conversation.
Done becomes a fact. A node can't close until the outputs it declared exist, and a loop ends when the checks pass, not when the agent believes they would. Each run ends in a named outcome, such as shipped or sent back, so outcomes can be counted and compared.
People stop the work where it matters. An approval before the build and another before the work ships put a person exactly where judgement is needed, and nowhere else. And each node can use a different agent or model: a strong one to plan, another to build, a third to review.
A graph also survives interruption. Because each node's outputs are written down, a run that waits overnight for an approval resumes exactly where it stopped, with the same inputs, instead of rebuilding its state from a conversation.
Graphs, not pipelines
Many tools that arrange agent work draw a straight line: step one, step two, step three. Real work doesn't run in a straight line. It branches when a check fails, repeats until tests pass, waits for a person and sometimes ends early because the idea was wrong. A pipeline treats all of that as an exception. A graph makes it part of the design.
That doesn't mean more structure is better. Start with the few steps you know, keep graphs small, and add a node when a step keeps going wrong in the same way. A node earns its place by catching something the loop alone would have missed.
Graphs also make work comparable. When every feature passes through the same nodes, you can see which node fails most often, where runs wait longest and which workflow sends the most work back. A loop that improvises its own path every time leaves nothing to compare.
Where ctxflows fits
In ctxflows, a workflow is a graph of agent, approval, condition and loop nodes. Each node declares what it reads and what it must produce, and a context step before each node hands it the rules and records that apply. A trigger starts a run: a board column, a schedule, a webhook, an event from the engine or a finished milestone.
Your own agent can start a workflow and follow it from its own session, or the free engine runs it unattended on your machine with Claude Code, Codex, Cursor, Gemini CLI or Grok, a different one per node if you like. Runs & actions shows each run's live position on the graph, with everything waiting on you in one place.