Loop, Graph, and Context Engineering — Three Disciplines Every Production Agent Needs

The vocabulary is finally catching up to the work. The teams shipping production agents are not arguing about prompts versus chains anymore. They are arguing about three concrete things: how the agent cycles through decisions, how its state topology is shaped, and what context the model actually sees on every turn. Anthropic popularized the labels and the discipline is real. A TPM who cannot tell loop engineering from graph engineering from context engineering cannot tell whether their release is safe.

The number that matters

The number is three. If you can name what each of the three disciplines owns in your agent, you have a release gate. If you cannot, you have a demo. Production work happens when loop, graph, and context engineering are owned by different people, with different artifacts, and with different failure modes that show up in your postmortems.

The framework

"Loop engineering is the contract. Graph engineering is the topology. Context engineering is the budget. Get any one of them wrong and the agent fails in a way nobody wants to debug at 2am."

1. Loop engineering — the contract that decides when to stop

Loop engineering is the discipline of the agent's run cycle. Every agent has one: model decides, takes an action, observes the result, repeats. The loop is the part most teams get the most wrong, because the failure mode is almost finishing.

The TPM acceptance criteria for loop engineering are five things you should be able to read on a release plan:

• A termination condition. Not "when the model thinks it is done" — a real predicate, like a max-steps bound, a goal-state match, a confidence threshold, or an external signal. If your termination is implicit, your agent will run forever in the failure case.
• A retry policy with a budget. How many times does the loop retry on transient failure? On permanent failure? What is the max wall-clock? What is the max spend? Without a budget, a transient outage becomes an outage of your own wallet.
• An idempotency story. If the loop dies and the cron restarts it, can the same action fire twice? If yes, what is your defense? Idempotency keys, action logs, or just a tighter retry window.
• A side-effect log. Every tool call has to land somewhere a human can audit. Not just telemetry — a per-step log that a TPM can read when a customer asks "why did the agent do that."
• A stuck-loop detector. A loop that calls the same tool with the same arguments five times in a row is not thinking. It is broken. The release gate has to catch this before the customer does.

A clean loop is boring. It starts, it makes progress, it terminates, and the audit trail is one straight line. A bad loop has retries stacked on retries, has a "retry on any error" catch-all that hides the real failure, and has a max-steps bound that is set to "1000 because it seemed safe."

2. Graph engineering — the topology that decides who owns what

Graph engineering is the discipline of how the agent's state is shaped. Every agent has one too: nodes are units of work, edges are control flow, and shared state is the channel through which nodes hand off. The graph is what makes a non-trivial agent different from a chain of prompts. A single-call prompt has no graph. An agent that calls a tool has a one-node, one-edge graph. An agent that decides which tool to call, calls it, evaluates the result, and decides whether to call another tool has a real graph with branching and conditional flow.

The TPM acceptance criteria for graph engineering are about who owns state:

• Shared state has an owner. If every node writes to a shared dict and nobody is responsible for its shape, your release will fail the first time two nodes disagree about what a field means.
• Edges have predicates. Conditional routing is not magic. The condition that says "if the confidence score is above 0.8, go to node A; else go to node B" has to be in a place where a TPM can review it. If the predicate is buried inside a model's prompt, the graph is not engineered — it is hallucinated.
• Cycles are explicit. If a node can loop back to itself or to a predecessor, that loop is a graph feature, not a bug. It has a name, a max iteration count, and an owner.
• The graph has a diagram. A TPM should be able to open the repo and find a `.png` or `.mmd` that shows every node and every edge. If the graph only exists as code, the release review will turn into a code review, and the TPM will not catch the topology bugs.
• Failure modes are part of the graph. What happens when a node throws? When a node times out? When a node returns malformed data? The failure path is part of the graph — it is not optional, and it is not "the model's problem."

A clean graph is one where you can draw it on a whiteboard and a TPM who has never seen the codebase can identify which node owns which risk. A bad graph is one where the diagram only exists in the prompt, where the failure paths are "we'll handle it in the catch block," and where a new engineer cannot tell which node is the bottleneck without running the system.

3. Context engineering — the budget that decides what the model actually sees

Context engineering is the discipline of curating what sits in the model's working window on every turn. It is the most over-discussed and the least well-owned of the three. The reason is simple: the loop and the graph are visible in code, but context engineering is invisible — it is the system prompt, the tool definitions, the retrieved documents, the prior turns, the scratchpad, the summary of the scratchpad, and the meta-prompt that says "be concise."

The TPM acceptance criteria for context engineering are about what gets paid for:

• Token budgets per layer. The system prompt has a budget. Tool definitions have a budget. Retrieved documents have a budget. Prior turns have a budget. The model has a window. If the sum of the layer budgets exceeds the window, you are not engineering context — you are praying.
• Prompt caching awareness. Every Anthropic model and most OpenAI models cache stable prefixes. If you are not putting the system prompt and tool definitions in the cached prefix, you are paying full price for them on every call. The release plan should say where the cache boundary is.
• A retrieval contract. If context engineering depends on retrieval, the retriever has a contract: what it returns, in what format, with what freshness, and what the fallback is when retrieval fails. "We just embed and stuff the top-k" is not a contract.
• A compaction strategy. Long-running agents fill their window. The release plan has to say what happens at 80% full, at 95% full, and at 100% full. If the answer is "the model will figure it out," the release is not engineered.
• **What is not in context.** This is the one most teams miss. The discipline is not just about what the model sees. It is about what the model does not see. Secrets, PII, large irrelevant blobs, and prior failed attempts all have to be excluded by construction, not by hope.

A clean context engineering story is one where you can answer "what does the model see on turn 1, turn 10, and turn 100?" with three specific token counts and three specific lists of content. A bad story is one where the answer is "it depends on what the agent has done so far."

How the three disciplines meet at the release gate

The three disciplines are not parallel. They meet at the release gate in a specific order:

1. Graph engineering first. You cannot engineer the loop or the context until you know what nodes exist and what state they share. The graph is the architecture.
2. Loop engineering second. Once the graph exists, you can write the termination conditions, the retry policies, and the side-effect logs. The loop is the contract on top of the graph.
3. Context engineering third. Once the loop is fixed, you can budget the context the loop actually needs. The context is the fuel for the loop on top of the graph.

The mistake most teams make is doing these in the wrong order. They start with the prompt — context engineering first — and try to bolt the loop on later, then try to bolt the graph on later. The result is an agent that demos well and fails in production, because the prompt hid the topology and the loop hid the budget.

The TPM checklist

Before you ship an agent to a real workflow, the release plan should answer five questions, one for each discipline:

1. Loop: What is the maximum number of steps, the maximum wall-clock, and the maximum spend before the agent is force-terminated?
2. Graph: Where is the diagram, and which node owns the failure path when a tool throws?
3. Context: What is the token budget per layer, and what is excluded by construction?
4. Audit: Where does a TPM read the per-step side-effect log when a customer asks why the agent did something?
5. Recovery: If the agent dies mid-loop, what state survives, and what is the manual rollback path?

If any of these is answered with "we'll figure it out in production," the agent is not ready. The three disciplines are not a feature list. They are the structure that lets you recover when the agent does the wrong thing — and it will do the wrong thing, because production is where the model's training data runs out.

The takeaway

Loop engineering, graph engineering, and context engineering are not three names for the same thing. They are three distinct disciplines with three distinct owners, three distinct artifacts, and three distinct failure modes. A TPM who can name them, draw the boundaries between them, and review each one separately has a release gate. A TPM who treats them as one undifferentiated mass has a demo.

The next time someone on your team says "we built an agent," the question to ask is not "what can it do?" The question is: "who owns the loop, who owns the graph, and who owns the context?" If the answer is "the same person" or "we'll figure it out," the agent is not engineered. It is shipped.

This is the TPM Content Research lane at doronkatz.com — release gates, recovery paths, and the discipline that makes agents safe to ship.