Boxes and Arrows Are Not a Contract
Explore how to transform a linear agent loop into a branching graph with clear contracts for nodes, edges, shared state, and joins. Understand managing ownership of state, merge rules for concurrent writes, and routing decisions to ensure reliable verification. Learn to prevent coordination errors from parallel checks and define explicit contracts that improve multi-agent or multi-check systems. Apply these concepts to design robust harnesses that maintain reliability when verification tasks run concurrently or sequentially with complex dependencies.
We'll cover the following...
- When has a loop earned a graph?
- What changes when the loop becomes a graph?
- What should each node be allowed to do?
- How should parallel nodes share state?
- What makes an edge legal?
- What must happen at a join?
- Can you repair Wrenfold’s graph?
- What can you add to your own harness today?
- How do you test the graph itself?
- What’s next?
Wrenfold’s CLIN-547 loop worked, so the team tried to shorten its verification stage. After each repair, it started two checks at once: one proved that a canceled appointment promoted the first eligible patient, and the other proved that retrying the cancellation did not send a second notification.
At 2:06:18 PM, the promotion check passed. The shared field verification.status became PASS, an edge opened to the persistence step, and the Feature Ledger marked CLIN-547 passing.
At 2:06:31 PM, the retry check failed at event:e14 with a duplicate notification. Its result overwrote the same shared field after the success receipt had already been recorded. The graph finished with a passing ledger, a failing trace, and two answers for the same revision.
The team had drawn parallel boxes and arrows. It had not defined who owned shared state or what evidence had to meet at the join.
When has a loop earned a graph?
A loop has one main return path: read, act, verify, persist, route, then retry or stop. Keep that shape while every failure returns to the same owner and each step depends on the previous step.
A graph becomes useful when the harness must express at least one of these relationships:
Different failure classes return to different owners.
Independent checks can run concurrently.
A human decision can pause and resume one route.
Several results must agree before work continues.
One branch can retry without repeating every completed step.
The number of agents does not decide the shape. A graph can contain one agent node, several deterministic commands, and a node that waits for a person. A long sequence with no branch is still a sequence. ...