Context Engineering Was Never the Final Layer. Graph Engineering Is.

The Loop That Would Not Stop Retrying

A client's support agent got stuck in a loop last quarter. Not a crash — a loop. Every time a customer asked a slightly ambiguous question, the agent called the same lookup tool, got the same unhelpful result, rephrased its own question, and called the tool again. Twelve times, in one case, before a human noticed the ticket had been open for six minutes with no real progress and no resolution in sight.

The prompt was good. The context was good — we had already applied everything I wrote about in context engineering: the right documents, the right conversation history, the right tool schemas, all five layers doing their job. None of it mattered. The system had exactly one path forward — call the tool, read the result, decide again — and no way to say "this is not working, try something else" or "stop and bring in a person." It could only spin faster.

That is the moment I stopped thinking about agent design as prompts, or even as context, and started thinking about it as a graph.

Prompt and Context Engineering Earned Their Place

I am not walking any of this back. Prompt engineering taught a generation of builders that wording, structure, and examples change model behaviour more than most people expect — that is not a small thing, and it is still worth doing well. Context engineering went further and proved something more uncomfortable: most failures were never the model being careless, they were the model missing information it needed and never had a chance to see.

Both are still true. Both are still necessary in every system we build at Will of Dawn Labs. But both operate inside a single call, or at best a single turn. Neither one has an opinion about what happens across ten calls, when the fifth one fails and the sixth one needs to do something structurally different from the first five.

Loop Engineering Was the Honest Next Step

The agent loop — plan, act, observe, repeat — was the correct response to that gap, and it is why the ReAct pattern spread as fast as it did. Almost every agent framework built in the last two years defaults to some version of it. A loop lets the model react to what actually happened instead of guessing blind. I have built dozens of these loops, and for a huge class of problems they are exactly right and nothing more elaborate is needed.

The failure mode shows up once the task stops being a straight line, and I wrote about the shape of that failure in our post on why most agents never make it to production: small errors compound, and a loop has no native way to say "if this fails twice, do something different" instead of just trying again with slightly different wording. A loop is a single road. It has no exits.

What a Graph Actually Changes

A graph replaces the single loop with nodes and edges. Each node is a discrete unit of work — a model call, a tool call, a human review step, a dedicated retry handler. Each edge is a condition: go here if the result looks like X, go there if it looks like Y, loop back to the start if a retry counter has not been exhausted, stop and page a human if it has. State persists across the entire run instead of living inside one prompt or one turn.

The practical difference shows up the first time something goes wrong. In a loop, "wrong" usually means retrying the same step with slightly different wording and hoping the model gets lucky. In a graph, wrong is a state transition — it routes to a node built specifically to handle that failure, whether that is a simpler fallback prompt, a different tool entirely, or a "hand this to a person" node that does not discard the work already done. This year alone I have rebuilt three production agents into graphs, and in every case the fix was not a smarter model or a better prompt — it was giving the system somewhere else to go.

The Three Signs You Have Outgrown the Loop

Not every agent needs a graph. Most simple, single-purpose tools are genuinely better off as a clean loop — adding graph structure too early is its own kind of over-engineering. These are the three signals I look for at Will of Dawn Labs before recommending the switch.

If none of these apply, a loop is not a limitation — it is the right amount of engineering for the job. Graphs cost more to design and more to debug, and that cost should buy something real.

What This Means for How We Write Code

The pattern across all four layers is the same one software engineering has seen before, just applied to a probabilistic component instead of a deterministic one. First you learn to phrase the request well. Then you learn that the request was never the whole problem — the surrounding information was. Then you learn that a single exchange was never the whole problem either — the system needed to react over time. And now the reaction itself needs structure, because reacting in a straight line breaks the moment real branching enters the picture.

That is where coding is heading. Less time spent hand-tuning individual prompts, more time spent designing the state machine around them — deciding what counts as a node, what counts as a failure, and where the system is allowed to go next. The model still does the language-native work inside each node. The engineer's job is the graph itself: the guardrails, the retry logic, the exits. That is a more familiar kind of engineering than prompting ever was, and it is exactly what the kind of production AI systems we build at Will of Dawn Labs require by default now, not as an afterthought.

If you are building an AI system that needs to survive its own failure cases — not just impress in a demo — that is exactly the problem we solve at Will of Dawn Labs. You can also book a 30-minute strategy call directly.

— Kaushal Malhotra
Founder, Will of Dawn Labs
willodawn.com/contact