Graph Engineering: Dependencies Before Agent Count

TL;DR

Graph engineering here describes dependencies between tasks, data and checks. A bilingual article provides a concrete example of useful parallelism and why recovery needs more than saved results. Agent count is not a quality metric.

Graph engineering is often explained through impressive agent counts. I am interested in a smaller question: which step needs to wait for what?

If two agents improve the same article at the same time, I initially have two versions. Not necessarily a better result. If one checks sources while another inspects the rendered page, they can work independently. Before publication, I need both results. A workflow has to express those differences.

For me, graph engineering means designing dependencies so that execution, verification and recovery fit together. It starts with the handoffs between tasks, not with launching more agents.

What Boris Cherny actually describes

This article began with posts about Boris Cherny, the creator of Claude Code. In his conversation with Diana Hu at Y Combinator, starting around 24:42 in the video, he describes dynamic workflows: divide work, check the results, then bring in further agents when needed. He distinguishes these from recurring loops and routines.

I could not find either the phrase “graph engineering” or the circulating 85-percent figure in the published transcript. I therefore use the term as a technical interpretation, not as a Cherny quotation or an official Anthropic method. The more useful point is that an agent needs a way to verify its work. Runtime alone tells us little.

Graph engineering starts before the first agent

An execution graph describes tasks and the relationships between them. A node might be a model call, but it could equally be a compiler, a database read or a person making a decision. An edge explains why one step must happen before another.

This is different from a knowledge graph. We are modelling execution, not a body of knowledge.

A simple chain is also a graph. It is not automatically a bad one. If I need to create a file before checking that same file, the order is correct. The question is whether every wait has a reason.

Data dependencies are one reason. An English version needs the agreed substance of an article. Other reasons matter too: two steps may write to the same file, share a limited API quota or change the same release state. The absence of a direct data handoff does not make them independent.

For each step, I record its input, result, write scope and completion condition. That can look like administrative overhead. In practice, it saves the later argument about what an agent meant by “done”.

An example: a bilingual technical article

Consider a workflow like this article. Sources and existing content are collected first. They produce a shared set of supported claims. Only then are the two language versions developed.

Sources + existing articles
             |
      supported claims
        /          \
   DE version    EN version
        \          /
      meaning check
        /          \
   link check   browser check
        \          /
     publication package
             |
     verify publication

This is a design example, not a log of a parallel production run. Both language versions can start from the same agreed substance. Before publication, they need a meaning check: does the translation introduce a guarantee that the German text never made? Has a proposed improvement become a supposedly shipped feature?

Link checks and browser checks answer different questions. An HTTP 200 response does not prove that a link points to the right content. A readable screenshot does not prove that the English canonical URL is correct. I do not want those findings compressed into a single “looks good”.

A handoff needs more than prose

An agent should not simply return “everything checked”. For this workflow, a result containing the article ID, language, source revision, identified problems and verification status would be more useful. It also needs a reference to the artifact that was actually checked.

A schema helps detect missing fields and invalid types. It does not establish truth. A perfectly formatted object can contain invented sources or false results just as easily as a paragraph. A deterministic check validates the shape; a substantive check compares claims with evidence.

The dynamic workflows documentation provides one concrete implementation: coordination lives in an executable script instead of only in conversation history. The architectural principle does not depend on which tool runs that script.

A local failure should stay local

If one English paragraph is unsupported, the entire research process should not have to run again. That section goes back with a specific finding. The German version can provisionally remain in place.

Provisionally matters. If the correction changes a shared claim, dependent results become stale too. The meaning check then needs to run again. A useful graph tracks not only what comes next, but which earlier approvals a change invalidates.

The same applies after an interruption. A saved result is a checkpoint, not a guarantee that every external effect happened exactly once. If publication was triggered but its response was lost, recovery must not blindly publish again. It needs to read the actual state. LangGraph’s persistence documentation makes the distinction between stored execution state and resuming work concrete.

The important part of an agent graph is often the edge that an unverified result cannot cross.

More parallel work has to earn its cost

I do not measure only how quickly the workers finish. Total time includes integration, verification and rework. Total cost includes every model call, including discarded attempts.

The useful unit of comparison is an accepted result. How long does it take from request to verified artifact? What does it cost? How often does it need correction? How much of my attention does it consume?

A graph with many concurrent nodes can perform worse on those questions than a short chain. Anthropic already argues in Building effective agents that extra complexity should be justified by actual benefit. Measuring one small case is more useful than copying somebody else’s agent count.

Where this fits into my work

My article on harness design describes an agent’s working environment: context, tools and checks. The graph adds the relationships between tasks. A bounded verification loop can live inside one node. These are different views of the same system, not a league table of new job titles.

In session-orchestrator, the wave structure is one concrete way to organise this. On Agentic Builders, my learning platform, the material covers separate write scopes and checks between waves. You can apply the principle without using my tool.

I would start with an existing workflow and mark its waiting points. Then parallelise one bounded part, verify its outputs separately and compare the complete run with the simple version. If the result does not improve, keep the simple version.

That is also the standard behind how I work. If you want to discuss a particular workflow, you can contact me. The most useful first sketch often has only a few nodes.

Common questions

What does graph engineering mean for AI agents?

Here it means designing the tasks, dependencies and verification boundaries of an agentic workflow. The important questions are what each step needs and what must be true before the next step can start.

Is graph engineering the same as a knowledge graph?

No. A knowledge graph describes knowledge and relationships between entities. This article concerns an execution graph of tasks, data flows and state transitions.

Do I need many agents or a new framework?

No. A short workflow combining one model with ordinary functions can be a useful graph. Additional agents should deliver a measured benefit over the simpler version.