shippers.

field notes · agents · 01 aug 26

graph engineering

loop engineering had its season. the conversation has moved one layer up: not how the work improves on each pass, but what is allowed to happen next at all. three ideas keep getting mixed together around the same model, and the mix-up is where most agent builds quietly go wrong.

three layers, not one thing

once an agent touches files, apis, documents, customers or production code, you are not prompting a model anymore. you are designing a system, and that system has three layers people keep treating as one:

note. harness is possible. loop is better. graph is allowed.

they all sit around the same model. they all affect reliability. they can all contain loops. and they are not interchangeable, which is why the fix for one never cures the other two.

the graph answers "what next"

a loop can make every pass measurably better and still walk the wrong path. better research, better draft, better summary, straight into the wrong customer's inbox. the loop optimises the step; the graph decides the steps. scoping, research, screening, synthesis, drafting, review, publication, with a human gate before anything leaves the building.

graph engineering is making that structure explicit instead of letting it live inside a prompt. the question stops being "what should the agent do?" and becomes "what is allowed to happen next?" the first question has infinite answers. the second has a small, reviewable list, and that is the entire point.

diagnose the failure before you pick the fix

the practical rule: if the agent cannot operate, fix the harness. if the output is mediocre, fix the loop. if the process is chaotic, steps skipped, gates jumped, work appearing where it should not, fix the graph. most teams respond to all three the same way, by buying a smarter model. it is the most expensive wrong fix on the menu, because all three failures survive a model upgrade untouched.

note. the model upgrade is the most expensive wrong fix.

self-review is not a gate

letting the same model write and grade without safeguards is not a review step, it is a shared blind spot. the graph deserves better gates: deterministic checks wherever a check can be deterministic, a separate reviewer context where it cannot, external evaluators for the judgments that matter, and a human approval for the actions that cost money or reputation. one honest condition at each edge beats a paragraph of please-be-careful in the system prompt.

note. same weights, same blind spots.

and a warning that belongs in every layer: "keep trying" is not a loop design. it is an uncontrolled cost leak wearing a loop's clothes. every loop, wherever it lives, needs a measurable goal and a stop condition, or what you have built is a furnace.

what this looks like from inside a studio

our own fleet runs this way. agents write, gates decide, and a single console shows what each agent last did and what it is allowed to do next. when one of them goes quiet or drifts, the console says so and says what to do about it. none of that is the model. the model is rented, and every competitor rents the same one. the harness, the loop and the graph are the parts you own, and they are the product.

if your agent can do fifty things and nobody wrote down what it may do next, that's a graph problem, not a model problem.