Chains, Graphs, or Code: Picking the Right Agent Harness

InfoQ describes a progression from linear prompt chains to graph-based workflows and then code-executing harnesses. It characterizes chains as simple but fragile, graphs as adding branching, retries, and validation, and code harnesses as verifying outputs through execution. It recommends validating model outputs and choosing the least complex design that meets reliability, speed, and cost needs ¹.

That progression is useful as a map of mechanisms, not necessarily as a ranking. One way to interpret it is that each structure offers a different kind of control: chains organize sequence, graphs represent branches and recovery, and execution-based harnesses check outputs against executable tests. The practical question for agent harness architecture is which mechanism addresses a failure you actually need to handle.

What each agent harness model controls

The source describes chains as linear, graphs as adding branching, retries, and validation, and code harnesses as verifying outputs through execution ¹. A useful design lens is:

• Chain → order. What happens next?
• Graph → paths and recovery. When should the workflow branch, retry, validate, or stop?
• Code execution → verification. Does a candidate output pass a specified test?

This framing is an architectural interpretation, not a claim that teams should progress through these designs in order. Identify the failure you want to address, then choose a mechanism that fits it.

When a chain may be enough for LLM agent workflows

A chain is a natural fit for a workflow that proceeds linearly, with each step consuming the previous step's result. For example:

classify input → extract fields → draft response → format result

InfoQ describes chains as simple but fragile ¹. A design risk to consider is that a weak or malformed result early in a sequence may affect later steps unless the workflow checks it. Before introducing graph control, consider whether a validation check at a handoff would address the specific risk. For example, a team might validate required fields before passing an extracted record to a drafting step. That is a design suggestion, not a result reported by InfoQ.

A chain may be a poor fit when the workflow needs meaningful alternative routes, recovery from particular errors, or escalation of uncertain results. Those are reasons to make control flow explicit; whether a graph is the right implementation depends on the workflow.

When graph-based AI agents may be useful

InfoQ says graphs add branching, retries, and validation ¹. Those capabilities can represent distinct handling paths, retries for recoverable failures, or a validation result that routes work for revision.

As an implementation consideration, a team adopting a graph will need to define responsibilities for its nodes, the conditions for transitions, retry boundaries, terminal states, and the data passed between steps. Those are design questions, not findings stated in the source. A retry policy, for instance, should specify what triggers another attempt and what happens if the issue remains.

A graph is worth considering when the workflow has real alternatives or recovery paths to represent. If it does not, graph structure may add implementation work without addressing a defined need. That is a practical judgment, rather than a source-reported comparison. For a related question about when a plain workflow is sufficient, see When AI Agents Need Actors—and When a Workflow Is Enough.

When code execution agents and verification may help

InfoQ describes code harnesses as verifying outputs through execution ¹. This approach may be relevant when an output can be checked by running it or applying a formal test, rather than relying only on another model's assessment. Possible applications to evaluate include checking structured data against a schema, running a query against a controlled fixture, testing a transformation against expected invariants, or evaluating a proposed action in a sandbox. These are examples for consideration, not applications or results reported in the source.

In this design, the model produces a candidate and an executable check evaluates it. The check can only assess the properties it was designed to test. A passing result therefore should not be treated as proof that every requirement has been met. Teams considering this approach also need to decide how to bound execution, maintain tests or fixtures, and handle failed checks. These are implementation considerations, not claims that InfoQ reports execution is superior to other approaches.

Where complexity may land

The following is an architectural interpretation of the mechanisms InfoQ describes, not a set of measurements from the source ¹:

Harness	Design considerations
Chain	A linear structure is simple, but teams may need to consider how errors at handoffs are detected.
Graph	Branching and recovery can be explicit, while transitions and retry behavior need definition.
Code execution	Checks can make selected properties testable, while test design and execution boundaries need attention.

Before adding a mechanism, consider questions such as:

Design question	What to examine
What paths must be represented?	Is the workflow linear, or are there meaningful alternatives?
Where can a step fail?	Which failures should be detected, retried, or rerouted?
How will a result be checked?	Is the check prompt-based, rule-based, or executable?
What should be monitored?	Errors, retries, latency, cost, or human corrections?

These questions are practical guidance, not findings from the source. InfoQ's stated recommendation is to choose the least complex design that meets reliability, speed, and cost needs ¹. A useful design practice is to document the failure mode each graph node or execution check is intended to address.

AI agent validation: what to measure before adding execution

Treat execution-based verification as a hypothesis to evaluate for your workflow. InfoQ recommends validating model outputs, but the excerpt does not provide a universal result showing that execution-based checks outperform other approaches ¹.

A team could compare its current workflow with a version that adds execution checks, keeping the task set, model configuration, input mix, and acceptance criteria consistent. If the comparison spans several models, a governed model catalog can help keep the configuration explicit. Possible measures include:

• Valid outputs — results that meet the team's acceptance criteria
• Escaped errors — invalid results that pass the checks in use
• Failed checks — results rejected by an executable test
• Human corrections — edits needed before a result is usable
• Retries, latency, and cost — operational measures to consider when evaluating checks and recovery paths

These are suggested evaluation measures, not benchmarks reported by InfoQ. Consider false positives and false negatives separately: a check can reject acceptable work or pass work that should have failed. For each failure, investigate whether the test, the output, or the workflow's handling of the result needs attention. For agents that talk to users, Tool-Using Agents Need Tests for Users Who Leave Things Unsaid covers a complementary testing concern.

Use evaluation results to decide whether the improvement meets the business requirement and justifies the additional engineering and runtime effort. That applies InfoQ's recommendation to choose the least complex design that meets reliability, speed, and cost needs ¹.

What to put in the decision record

Document the workflow's shape, including its sequence, alternative paths, retry conditions, and which output properties can be checked. Then record:

• why you chose a chain, graph, or code-executing harness
• which failure modes the choice is intended to address
• which failure modes remain unhandled
• how outputs are validated
• what evaluation results would prompt a redesign

InfoQ's overview describes chains as linear, graphs as adding branching, retries, and validation, and code harnesses as verifying outputs through execution ¹. It recommends validating outputs and selecting the least complex design that meets reliability, speed, and cost needs ¹. Use that as a set of design considerations, not as proof that one harness is best for every workflow. Before adding another layer of control, specify the failure it is meant to catch and evaluate whether it does so.