Skip to content
BC Consulting

BlogClinical Research posts

Loops, Graphs, and Verification in Regulated GxP Workflows

By Bryan Clayton14 min read

Originally published on LinkedIn.

  • ai
  • agents
  • gxp
  • governance
  • claude

The creator of Claude Code said something recently that stuck with me: he does not prompt Claude anymore, his job is to write loops. A month later the same corner of the internet had moved on and declared loops old news, replaced by graphs. I have built both inside my own company, running actual work rather than demos, and the "which one is better" argument the tech world is having misses the point for GxP implementations. They are the same idea at two different sizes. What decides whether either one works is the verifier: whether something that cannot argue back is checking the output before anyone acts on it. If the work sits under GxP, the structure you pick is not academic; it decides where your audit trail entries land, which agent is holding an irreversible tool, and whether you can show that this run took the same path as the last hundred. Underneath all of it is the same line I keep coming back to: deterministic versus stochastic.

Let me lay both out the way I actually use them.

What a loop is

A loop is the simplest agent you can build. A normal prompt runs once and stops. A loop is a prompt that runs again and again until a goal is met: try, check, adjust, go again. Claude Code against a failing test suite is a loop. It edits a file, runs the tests, reads the output, edits again, and stops when the suite is green. That is the whole shape, and it will grind away for hours without you. Each pass is cheap. The total is bounded by nothing except the stop condition you wrote.

Before I build one, I run the same four-question test the loop engineers use. Does the task actually repeat, or is it a one-off better served by a single prompt? Is there a clear definition of done, and a way to verify it? Can I afford to be wasteful with tokens, since a loop will keep prompting itself until it is satisfied? And does the agent have the tools it needs not just to do the work but to check it? If any answer is no, a loop is the wrong tool.

What a graph is

A graph is what you build when one loop is no longer enough. Instead of a single agent grinding on everything, you wire up several specialized ones and let them hand work to each other. A researcher that only reads and searches. A writer that only drafts. A checker that only tries to poke holes. Each specialized agent is a node, one job with a defined input and a defined output. The arrows between them are edges, and an edge is real only when one job actually needs what another produced. Nodes do the thinking, edges carry the results, and that is the entire vocabulary.

Claude Code builds these natively now. Describe the task and ask for a workflow, or use the ultracode keyword, and Claude writes a short JavaScript orchestration script, then a background runtime spawns a coordinated fleet to run it. The coordination happens in code rather than in a running chat, so the loop, the branching, and the intermediate results live in script variables and only the final answer lands back in your context window. That single property is what lets one person run a whole fleet without drowning the session.

Now before anyone accuses me of framing this as a July 2026 invention, let's be clear in saying this pattern isn't novel unto itself. Harrison Chase, who built LangGraph, said publicly that he did not know what graph engineering was and suspected it described what his framework had been doing all along. David Khourshid, who created XState, pointed out that directed graphs of states and transitions are decades-old computer science. Jeremiah Lowin at Prefect, whose company has built orchestration on graphs for years, put the proportions at roughly ninety-five percent things the workflow world has done for a long time and five percent genuinely new handling, because the nodes are now non-deterministic. The vocabulary is new, the structure is not, so if you have been rolling your eyes at all this, you have found a friend.

A loop is the smallest possible graph

At its most basic form, a loop is one node, with an arrow pointing back at itself. That is the first reason the argument really isn't about "loops against graphs." The real question is how many specialized nodes a given job actually needs, and everything follows from that.

There is a test that answers it, and if you have ten minutes, give this a try. Take any business process or workflow you run today and walk through it step by step; old fashioned paper and pencil is your tool of choice here. Draw a box, or a node, for each step that does "something," then draw a line that represents the output that comes from the box. Now ask yourself: did this box actually need the result of the step before it? If yes, the line that connects it, the edge, is real, and you should keep the order. If no, there is no edge, and the wait time for that node to run is wasted. Maybe those two jobs can run at the same time.

For example: pull the data, check stock levels, check label inventory, write the summary. That reads like a sequence, but the label check never looks at what the stock check returned. The two only run one after another because that is the order you wrote them in. Run them side by side and the job finishes in the time of the slower check instead of the sum of both. You will find two or three of these fake edges in almost any workflow you draw, and every one of them is speed you could reclaim.

When several jobs are genuinely independent, the pattern is almost always the same shape: the work fans out to run in parallel, plain code compresses the results, and one final agent writes the answer. That is the pattern to start thinking about in your next skill or process design.

The verifier is what makes either one work

Now the part both camps quietly agree on, and the part that is easy to skip if you aren't concerned about 21 CFR Part 11 or similar constraints. How you wire the agents together is not what makes the output trustworthy. Every serious test of AI self-review lands in the same place: a model grading its own output is far too easy on itself. So you never let the agent that did the work be the one that checks it, and this holds whether you are running a single loop or a hundred-node graph.

In a loop, the definition of done has to be a real signal, not the agent announcing it is finished. The graph version of the same rule is that the checker has to be a separate node with a clean context. If you give that checker the same chat history the worker had, you can see how it is not really checking anything; rather, it is nodding along to itself in a different font. If we start the checker fresh, hand it only the finding, and ask it to try to kill the claim before the work moves on, we create a separation of concerns pattern. If the claim survives the checker, it passes.

Three checkers all asking "is this right?" will mostly agree with each other, and with the worker. Give each one a narrower question instead. One asks whether the finding matches the system of record, perhaps meaning the actual randomization and inventory data rather than the worker's summary of it. One asks whether the data is still current, because site stock, shipment status, and enrollment move daily and an answer built on last Thursday's extract can be correct and useless at the same time. One asks whether the protocol version cited, or the specification document, is the effective version and actually says what the worker claims. A superseded protocol amendment or a retired pharmacy manual will support a conclusion that no longer holds true. Three different questions catch more than three copies of the same question.

Structure does not buy truth

This part is critical, so put your AI skeptic hat on and stay with me. You can build the full graph, checkers watching workers, audit nodes watching checkers, everything consistent with everything else, and still be confidently wrong. We've all seen AI give us confident information that we know to be incorrect. Then we call the AI chat out on the error, and it politely apologizes as if it wasn't a big deal. This happens because the audit checked the numbers against the same system the numbers came from. In this instance a graph fails exactly the same way a single loop fails. The difference is in the failure happening later, more expensively in terms of tokens and compute, and with far more green lights on the way down.

What keeps either one honest is anchors: deterministic checks on a stochastic process, facts that cannot argue back. A test that actually ran is objectively more valuable than a test script that the AI assumes will pass based on its context. A reconciled count from source data is objectively better than a summary of a count in the session context. Judge the work against a number that the AI cannot talk or reason its way out of, and the work stays grounded. Let the system grade its own reports and it will drift, politely, all the way to the wrong conclusion.

In clinical work those anchors are usually sitting right there, and they are better than what most software teams have to work with: reconciled inventory counts at the depot, randomization records in the system of record, temperature logs pulled from the datalogger, actual enrollment against the plan. An agent reasoning about supply risk should be measured against the count that came off the shelf, not against its own summary of last week's report. When you cannot name the anchor for a piece of work, stop designing architecture and start defining the verified truth.

Where the node edge earns its keep

There is a second reason to split a loop into nodes, and it's much more important than speed. It is capability control, and it matters most when your automation touches something you cannot undo.

The best practice is to write a skill listing the ten things to verify before an action, then hand the agent the tool that performs that action. What you have actually built is an agent with the standing capability to perform it, plus a polite note describing how you would prefer it be done. If it reads the instructions, and follows them in order, and reasons correctly, and targets the right record, and nothing in its context confused it, everything works. If any one of those fails, including the agent simply skipping a step, you get a problem that is genuinely hard to diagnose, because the agent will report back that the task completed successfully.

Now split it. The first node does the diligence: it checks the shipment against the blinding state, the site's inventory position, the expiry window, and the temperature excursion history. That node needs an agent, because the judgment is not fully programmatic. That node cannot release anything. Its only job is to produce a decision. Control then returns to the orchestrator, and only on the path where the decision is "release" does a second node come into existence holding the release tool, scoped to one shipment, usable once. The judgment is made by an agent that cannot act on it. The action is taken by a node that does no judging.

The same structure fixes human approval, which most of us have bolted on awkwardly at least once. A sign-off does not have to be a tool-level interrupt or a line in a prompt you hope the agent honors. It is a node. The agent finishes its work, the workflow moves to an approval node where a qualified person makes the call, and the next agentic node runs conditional on that decision. A node can also be plain code, a database write, or a wait for an external event. Not everything in the graph has to be an agent.

Separating the deterministic parts from the stochastic ones is the point we've been circling, so let's get into the details. The agent inside a node is stochastic; it reasons, and by its nature it will not reason identically twice. Everything the graph puts around that node is deterministic: the plain code, the conditional edge, the capability scope, the approval gate, the audit entry. A single loop blends the two, so when you go back to reconstruct a run you cannot separate the judgment from the procedure. A better practice is to split them across a node boundary so you can point at each one: here is what the agent decided, here is what the system enforced regardless of what the agent decided.

Anyone who has written a validation plan will recognize the shape. The edge between two nodes, the line between two boxes, is where an audit trail entry belongs, because that is the moment the work changes hands. An edge that is followed only under a certain condition is a decision point written down in advance, rather than one made inside a model's reasoning where nobody can inspect it. Giving each node only the tools its own job requires is least privilege applied to something that can act on its own. And reproducibility, which a loop gives you almost none of by construction, is what makes an evaluation protocol meaningful, because you cannot pragmatically test a system whose execution path changes every run.

The bill in tokens and dollars

Proof of concepts and demos leave out the cost to run a fleet of agents at scale. Jarred Sumner used exactly this fleet approach to port the Bun runtime from Zig to Rust, translating 535,496 lines into over a million lines of Rust in eleven days, work he estimated would have taken a team with full context on the codebase a year. It ran roughly fifty dynamic workflows with about sixty-four Claude instances going at peak, it cost around $165,000 at API pricing, and it needed one engineer designing and monitoring the whole thing throughout.

Two details about that run matter more than the price. It used a pre-release model, and it had an unusually strong deterministic oracle underneath it: a compiler that refuses invalid states, and a test suite with over a million assertions that passed on every supported platform without a single test skipped or deleted. The fleet worked because something that could not be argued with was checking it.

So a graph can chew through a job no single context could hold. It can also spend real money in the background if you point it at the wrong task or skip the anchors. The heavy version is for work that is genuinely wide and worth the spend. Most work is neither, and a single well-scoped loop with a real definition of done is faster, cheaper, and easier to trust.

How I decide

I ask whether the job is one task or several genuinely separable ones. If it is one, I build a tight loop with a hard stop condition and a way to verify the result, and I move on. If it is several, I split it into specialized nodes, but only after I know what the anchor is that keeps the whole thing honest, and only after I have put a fresh checker between the work and the answer.

For anything in a GxP environment I add one step at the front. Before deciding anything about architecture, list every irreversible action in the process: the shipment that cannot be recalled, the record that cannot be quietly amended, the unblinding that cannot be undone. Each one of those belongs behind its own node boundary, with its own capability scope and its own audit entry. That list is what should size your system, not the vocabulary on your feed this week. Remember and beware, the talking tech heads treat novelty as their working capital on social media platforms, not quality, cost, and scalability.

If you take one thing from this, make it the fake-edge test. Get the paper out tonight, draw the boxes for the workflow you already run, then find the lines that carry nothing from one box to the next and cross them out. That one move will make you faster than most people before you touch a single new tool. And when a job finally is wide enough to need a fleet, you will know it, because you will have found more than one real edge worth keeping.

My thanks to Anatoli Kopadze, whose article "Graph Engineering explained: what it is, when to use it and when not to" served as the foundation for this one, and to Austin Marchese, whose video "Stop Prompt Engineering. Start Loop Engineering." prompted me to start writing. If you found this useful, both feeds are worth following.

References

Working on something like this?

We run AI Bootcamps and build custom tools for sponsors and service providers in clinical research. A short call is the fastest way to find out whether your problem fits.

Talk About Your TeamBrowse the Catalogue