Agentic engineering: harness, loop and graph
Agentic engineering is the practice of building the system around a model rather than the prompt inside it: harness engineering, loop engineering and graph engineering, and how to choose between them.
What agentic engineering is
Agentic engineering is the practice of building the system around a language model rather than the prompt inside it. The model is the one component you buy rather than build, and it is not usually the reason a system fails. Three named disciplines sit under the term. Harness engineering designs everything outside the model — the tools it can call, the sandbox it runs in, the permissions it holds, the memory it reads, and the verification that runs before its output takes effect. Loop engineering designs the cycle the harness runs within a single turn: how context is compacted, what the budget on calls and tokens is, what happens when that budget is spent, and how a run tells finished apart from stuck. Graph engineering designs the topology the work moves through — which nodes exist, which transitions are permitted, and which branches may run at the same time. It has nothing to do with knowledge graphs, and the collision of names is unfortunate.
- Without the graphControl flow becomes conditional sprawl. Nobody can draw the system, so nobody can say which states are reachable.
- Without the loopA run spends without converging. There is no ceiling, so there is no defined behaviour at the ceiling either.
- Without the harnessThe model's decisions land on production unchecked. Every tool call is trusted because nothing is positioned to distrust it.
Why the vocabulary changed
The names arrived in the order the failures did. Prompt engineering was the whole discipline while a system was one call and one answer, and it stopped being sufficient the moment a second call depended on the first. Context engineering followed, because what you put in front of the model turned out to matter more than how you phrased the request — retrieval, memory, compaction, the order of the evidence.
Harness, loop and graph engineering are what came next, and they arrived together because they answer three questions that a single call never raises. What is this thing allowed to touch. When does it stop. What runs after what. None of those are properties of a prompt. All three are properties of code you write, which is why the new names are engineering disciplines rather than writing techniques — and why a team that is still tuning prompts to fix a runaway agent is working on the wrong layer.
Harness engineering
The harness is everything that is not the model: the tool definitions, the execution environment, the permission checks, the memory layer, the redaction, the logging, and the verification that decides whether a result is allowed to count. A useful test for whether something belongs in the harness is whether you need it to be true every time. A model can be asked not to touch a file and will usually comply. A harness refuses. That difference — a preference against a guarantee — is the whole of the discipline.
In the delivery system I run, the parts that earn the most are the unglamorous ones. A set of guarded paths halts a run for explicit human approval whenever a change touches an enumerated file, regardless of how urgent the work claims to be — configuration is guarded alongside code, because the configuration decides how the machinery behaves. A hook watches for the cheapest possible route to a passing test, which is loosening the assertion that failed, and any candidate fix that took it is disqualified rather than reported. Redaction runs at the point work enters the system and again at the point a person composes it by hand, through one shared implementation, because two redactors are two chances to be inconsistent.
None of that is model work. All of it is the difference between a system you can leave running and one somebody has to watch. The build this corresponds to is evals, tracing and guardrails, with the tool surface itself covered by Model Context Protocol servers.
Loop engineering
The loop is the cycle a harness runs inside one turn: assemble context, call the model, act on what it decided, and go again until something ends the run. Loop engineering is the design of that cycle, and most agents that fail in production fail here rather than at the model. Context grows until the instructions fall out of attention. No budget was ever set on tool calls or tokens. The stop condition fires on success but has nothing to say about a run that is merely not finished. A retry feeds the same poisoned context back in and produces the same failure more expensively.
Two details are worth stealing. The first is that a wall-clock limit has to be enforced on every state write rather than checked at gates, because a run can sit inside a single model call for hours and a gate that is never reached never checks anything. The second is that halted time should be discounted from it, so the number means minutes of work rather than minutes since the work was filed — otherwise every run that waits overnight for an approval looks like a runaway.
The third is less obvious and has been the most useful. When a budget is exhausted, an arbiter decides what happens next and returns one of three answers: one more targeted round, a narrowed scope, or a terminal stop. Handing that decision to something that can read the run is strictly better than a fixed policy, because “we are one assertion away” and “we have been going in circles for six attempts” both present as a spent budget and deserve opposite responses. This is the agent loop engineering build in full.
Graph engineering
Graph engineering treats a multi-step system as an explicit state machine rather than a pile of conditionals: the nodes are declared, the permitted transitions between them are declared, and anything not declared cannot happen. The payoff is not elegance. It is that you can draw the system, and once you can draw it you can ask which states are reachable, which branches are independent, and where a loop is allowed to exist. A system assembled from nested conditions answers none of those questions, and the person who wrote it cannot answer them either after a month away.
The name is a collision and it costs the discipline a lot of confusion, so it is worth saying plainly: this has nothing to do with knowledge graphs, graph databases, or retrieval over a graph. Those are a context engineering concern and a different problem entirely. Graph engineering is about control flow. The corresponding build is agentic workflows and orchestration.
Choosing between a loop and a graph
The decision is narrower than the debate around it suggests, and it turns on one question: are the steps knowable before the run starts? If you can name the stages and the transitions in advance, build the graph. It is cheaper to run, far easier to debug, and it lets independent branches execute at the same time. If the next step is only knowable from the last result, you need a loop, and no amount of upfront diagramming will produce one that works.
Almost every real system is both, and the useful framing is a graph whose nodes contain loops. The graph carries the parts you are willing to commit to — intake, routing, review, release — and the loops carry the parts you are not, which is usually the actual work inside a node. Teams get this wrong in a consistent direction: they reach for a multi-agent topology before a single agent can reliably finish one task, and end up debugging coordination on top of a component that was never trustworthy.
What this looks like running
The system behind the examples above is a set of agentic delivery workflows: one ticket in, one reviewed pull request out, running unattended between two points a person owns. Four flows, twenty-six role agents, and exactly one human stop per run, placed after the work is built and before anything irreversible happens. Ambiguity never interrupts — a flow agent has no question tool at all, so an unclear decision is recorded as a question, given a default, rated for impact, and carried forward. Every accumulated question surfaces together at that one stop. Interruptions become a review.
The part that changed my mind about review is below. Six reviewers, each with a predicate deciding whether it runs at all, and the whole panel re-runs after every repair rather than only the reviewer who complained.
| Reviewer | Round 1 | Round 2 | Round 3 | Round 4 |
|---|---|---|---|---|
| Code reviewalways | Passed | Passed | Passed | Passed |
| Testsalways | Failed | Passed | Passed | Passed |
| Acceptancefeature · bug | Passed | Failed | Passed | Passed |
| Securityauth · secrets · outbound | Passed | Passed | Failed | Passed |
| Documentationpublic surface changed | Skipped — not applicable to this change | Skipped — not applicable to this change | Skipped — not applicable to this change | Skipped — not applicable to this change |
| Driven interfaceuser-facing changed | Passed | Passed | Passed | Passed |
The other decision worth copying is what counts as done. It is machine-checked rather than declared: every gate passed, a pull request exists, commits are recorded, the knowledge base was written back, assumptions were reviewed, and no sandbox was left behind. Anything less is blocked or failed. There is no quiet partial success, because a quiet partial success is the state that costs the most to discover later.
Rules that survived contact
These are not house style. Each was written after a specific defect shipped, which is the only reason any of them are worth the words.
- Absent, empty and failed are three different facts. “We have not looked yet”, “there is nothing there” and “we could not ask” each get their own wording. A zero drawn from a list nobody read renders an outage as a measured, healthy, empty system — the confident kind of wrong.
- A dash is not a zero. Where nothing measured a figure it renders as an em dash, never as 0. A panel of confident zeroes over unmeasured runs is the same failure in a different costume.
- Every figure names its provenance. Recorded, joined by heuristic, and derived are labelled differently on the same panel. A guess presented beside a measurement reads as a measurement.
- An honest skip beats a fabricated pass. When a project has no interface or no driver configured, the verdict is SKIPPED. A skipped check is a useful signal; an invented one trains people to ignore the gate.
- A failing visual baseline is never resolved by accepting the new screenshot. That is the same move as weakening a failing test. It is a finding for a person to review, and flaky checks report their ratio rather than hiding it.
- Only human signal is allowed to teach the system. A gate rejection and its stated reason, the difference between what an agent produced and what actually merged, an overridden assumption. A system that learns from its own unreviewed output reinforces its mistakes with rising confidence.
Questions
What is agentic engineering?
Agentic engineering is the practice of building the system around a model rather than the prompt inside it. It has three sub-disciplines that people now name separately: harness engineering, which decides what the model can reach and what checks its output; loop engineering, which decides when a run repeats and when it stops; and graph engineering, which decides the topology the work moves through. The model is bought. The other three are built, and they are where a working demo becomes a system that survives a month.
Is loop engineering just prompt engineering with more steps?
No, and the difference shows up on the invoice. Prompt engineering changes what one call says. Loop engineering changes what happens across calls: how context is compacted so the instructions do not fall out of attention, what the ceiling on tool calls and tokens is, what happens when that ceiling is reached, and how a run distinguishes finished from stuck. A prompt change cannot fix a loop with no stop condition, because the loop was never reading the prompt for one.
When should a workflow be a graph instead of a loop?
When the steps are known before the run starts. If you can name the stages and the transitions between them in advance, a fixed graph is cheaper to run, far easier to debug, and lets independent branches execute at once. Reach for a loop when the next step is only knowable from the last result. Most real systems are both: a graph whose nodes contain loops, with the graph carrying the parts you can commit to and the loops carrying the parts you cannot.
What belongs in the harness and what belongs in the model?
Anything you need to be true every time belongs in the harness. A model can be asked not to touch a file and will usually comply; a harness refuses. Budgets, permissions, tool definitions, sandboxing, redaction, retries and verification are all harness concerns precisely because they are guarantees rather than preferences. What is left for the model is judgement: reading the situation, choosing a tool, and assessing its own result.
How do you test an agent's control flow without paying for model calls?
By separating transport from judgement. If the flow — which node runs next, which gate is reachable, what a retry budget does when it is spent — is a script rather than something the model improvises, it can be executed against a named scenario with every model call stubbed. That runs in seconds, costs nothing, and catches the failures that are actually common: an unreachable gate, a loop with no exit, a repair budget that never decrements.
Does any of this apply to a team of five?
The loop and the harness do, immediately — they are what stop a single agent from spending forty dollars to return nothing, and they are a few days of work rather than a platform. Graph engineering earns its keep later, once more than one agent is involved or the same work runs often enough that its shape matters. The failure mode for a small team is not building too little of this; it is building a multi-agent topology before a single agent reliably finishes one task.
Who runs this
Gagan Deep Singh builds agentic systems end to end — the harness, the loops, the topology and the evaluation around them. Everything on this page is described from operating it rather than from reading about it, which is also why the examples name mechanisms and failures instead of principles. The nine builds this work is sold as are on the builds page, and there is more about me if the question is whether the person and the problem match.
Next: the whole delivery machine, end to end, testing an agent's control flow without a model, what a bounded loop actually costs, or the build-along from an empty file to a working loop.