A harness is the environment around agentic work: the models, instructions, skills, tools, and files that let agents do the job. A graph describes how work moves through that environment. Anatoli Kopadze, writing an article on X, starts with two familiar parts:

A graph is just a plan for your AI work, drawn out so you can see it. It answers two questions: which jobs need to happen, and which job has to wait for which.

There are only two parts, and getting them straight fixes most of the confusion.

A box is called a node. It’s one job: one agent doing one task, with one thing going in and one thing coming out. Researching a competitor. Writing a draft. Checking a claim.

An arrow is called an edge. It just means one job needs what another job produced, so it has to wait for it. And the arrow only counts when something real actually passes along it.

That last condition changes how you design the workflow. A list written as “do A, then B” looks sequential even when B never uses A’s result. Kopadze’s test is to remove those false dependencies so independent jobs can run at the same time:

Look at the AI workflow you run today and walk it step by step. At each step, ask one thing: does this step actually need the result of the one before it?

If yes, the edge is real. Keep the order. If no, there is no edge, and the wait is wasted. Those two jobs can run at the same time.

Take a simple one: “review file A for bugs, then review file B for bugs.” It reads like a sequence, but the check on file B never looks at what file A returned. They only run one after another because that is the order you typed them in. Run them side by side and the whole thing finishes in the time of the slower single file, not the two added together.

This resembles building an automation in n8n: each node has a job, and the connections determine what data it receives and when it can run. AI adds another requirement, though. The agent checking a result should not inherit the worker’s reasoning and simply agree with it:

So you never let the agent that did the work check the work.

You put a separate node on the edge. Its only job is to try to kill the finding before it moves on. If it survives, it passes. If not, it dies right there.

Here is the catch nobody names: that checker needs a clean context.

Give it the same chat the worker had and it is not checking anything, it is nodding along to itself in a different font. A graph of agents sharing one context is just a single loop in a costume, and it breaks the same way, only later and pricier.

So make the verifier fresh. Own context. Checking a real signal, not “did the agent say it is done” but “does the test actually pass.”