Graph Engineering explained in 8min..

0:00When we ask Claudecode to do a deep

0:01research about a specific topic, behind

0:03the scenes, it's not just one agent that

0:06handles the entire research, but many

0:08agents are spawned to handle our

0:10research needs. Claudecode actually

0:12generates a dynamic workflow that looks

0:14something like this, where you have over

0:16100 agents broken into various phases.

0:19And this entire workflow is generated on

0:22the fly by Claudecode in JavaScript

0:24code, like you can see here. That's 427

0:27lines of code, and this very code acts

0:30as a runtime environment that will spawn

0:32over 100 agents. And every new request

0:34that I send, Claudecode will generate a

0:37fresh new workflow, and each workflow

0:39will spawn different numbers of agents.

0:41So, given our example here of JavaScript

0:44file, where Claudecode essentially

0:46converted my research plan into a

0:48workflow as a runtime, Claudecode will

0:50then start launching many agents in five

0:52different phases. And each phase of the

0:54workflow will more or less work in

0:56parallel, and each agent has its own

0:59context window and its own system

1:00prompt. Pretty neat, right? Now,

1:02building on this workflow that you can

1:04see here, the concept for graphs has

1:07been resurfacing lately, as if it's a

1:09next natural progression in our agentic

1:12engineering. So, we asked the natural

1:13question, what exactly is graph

1:16engineering? The idea of graphs dates

1:18all the way back to 1736, when a Swiss

1:20polymath, Leonhard Euler, was

1:22considering solving the strange question

1:25in a city called Königsberg. They have

1:26two mainlands and two islands and seven

1:29bridges connecting them. And the

1:30question was simple, is there a route

1:32through the city that crosses every

1:35single bridge, but only exactly once?

1:37Now, you might try and hypothesize a way

1:39by process of elimination. Maybe you can

1:41start here and try to cross the bridge

1:44this way, or maybe you just start on the

1:46island instead and start out and see if

1:48there's another way possible, and you'll

1:50soon realize that this is not possible.

1:53Euler agreed, but it's not just that

1:55this wasn't possible, but how Euler

1:58simplified the problem into a simple

2:00concept shown in this diagram. Circles

2:03are nodes, which in this case were land,

2:05and the black lines are edges, which are

2:07bridges in this case, and these two

2:09constitute a graph. So, this middle

2:11island here has five edges, or bridges

2:14in this case, connecting to other areas,

2:16and so on. And given this

2:18representation, Euler concluded with a

2:20proof that this kind of route in

2:22Königsberg is impossible. Now, the exact

2:25proof that Euler proposed is sort of

2:27irrelevant to this video, but Euler's

2:29graph theory is now applied to agents

2:31and graph engineering today. Here's

2:33another way to visualize the workflow

2:35that Claude code generated for my deep

2:37research from earlier. This consists of

2:39five phases. One agent for scoping the

2:42requirement, five agents to gather

2:44credible websites to research for each

2:46subtopics, 25 agents to then actually

2:49fetch the information and pass it to the

2:51next, and 75 agents to verify the facts

2:55and vote on the credibility, and

2:57finally, one agent that generates the

2:59full report in the end. And this

3:01workflow you're seeing here is a form of

3:03a graph. In this case, because execution

3:06only flows from left to right, with no

3:08node going backwards, which would form a

3:10loop, this is called DAG, or directed

3:13acyclic graph. Now, we could technically

3:15do this with a single agent instead of

3:17hundreds of agents in a graph like we

3:19just saw earlier. But this would be a

3:21bit silly because using a dynamic

3:23workflow for this kind of work is better

3:25for many reasons. The most obvious one

3:27being time. By parallelizing task into

3:30sub-agents that have their own small

3:32objective, this helps save a large

3:34amount of time by the simple fact that

3:36multiple agents are working at the same

3:38time. Another benefit is separation of

3:41concerns. The fact that each agent has

3:43its own context window helps focus its

3:45own context window towards its goal.

3:47Whereas a single agent might need to

3:49keep reusing its own context to store

3:52some of it for the goal, some of it for

3:54the current task and keep summarizing

3:56back and forth. But graphs aren't

3:57without its drawbacks either. Anthropic

3:59made a post that talked about their

4:01multi-agent research system that said a

4:03single agent tends to use four times

4:05more tokens than a regular chat and a

4:07multi-agent system tends to use 15 times

4:10more tokens in comparison. So going back

4:12to our example, each agent ran on Opus 5

4:16with their own system prompt and each

4:17agent used about 20,000 tokens by

4:20default to start. So by the time you

4:21extrapolate this to 108 agents that it

4:24eventually used, the input cost alone

4:27would be closer to $10 given Opus 5's

4:30pricing. But since we have prompt

4:32caching, realistically, this number will

4:34look closer to a dollar which helps

4:36scale our agent from a single agent to a

4:38parallel agents like you can see here.

4:40So given the benefits and the drawbacks

4:42when it comes to graphs, why are

4:43everyone talking about graph and graph

4:45engineering as if it's the next

4:47evolution when it comes to agentic

4:48engineering? But first, a quick word

4:50from Zoe sponsoring this video. It's

4:52pretty obvious that more and more parts

4:53of our lives are being integrated with

4:55AI and often our interactions are

4:57scattered across Claude, ChatGPT, Codex

5:00and Menace. So how can we have more

5:02ownership while having a 24/7 agent? Zoe

5:05gives you a dedicated computer on the

5:07cloud that's yours, meaning your agent

5:09is on standby for anything that you

5:11give. And part of being 24/7 is the

5:13ability to message your agent through

5:15text. You can directly message Zoe to

5:17have normal conversations through

5:19iMessage or ask about files that you

5:21have stored on your computer in the

5:22cloud and better yet, build an

5:24e-commerce website for vintage watches

5:27and host directly on Zoe using their AI

5:29agent natively through text. What's cool

5:32about Zoe is that you can write code and

5:33launch sites that are actually useful

5:35because you can integrate all your

5:37contacts into Zoe and run automations.

5:39Custom domains are also included at paid

5:41plan and all your sites are hosted on

5:43your Zoe's cloud computer. Plus they got

5:45some neat tricks like the selector tool

5:47to edit exact areas to improve things or

5:50even add automations that plug into your

5:52website, like a text anytime someone

5:54fills out a form. Try Zo today. I'll

5:56have the link in the description below.

5:57The concept behind agent communicating

6:00with another agent is not anything new.

6:02We can look back to open-source ideas

6:03like AutoGen in 2023 from Microsoft

6:06talking about agents communicating with

6:08another agent. Companies like LangChain

6:10also started messing with cyclic graph

6:12in 2023, which led to LangGraph, which

6:15became a framework for orchestrating

6:17agents. Anthropic also released various

6:19ways that agents can work together

6:21around the same time, like prompt

6:23chaining where LLMs are chained

6:25sequentially one after another, routing,

6:27which is similar to sub-agents, but from

6:29the perspective of the main agent,

6:31parallelization, which is similar to our

6:33deep research workflow, orchestrator,

6:35also similar to what we saw earlier, and

6:37evaluator optimizer, where two LLMs

6:40adversarially go at each other until a

6:42condition is met. But, none of these

6:44were materially useful back then because

6:47the problem wasn't so much in the graph

6:49itself, but what the node inside of the

6:52graph can actually do. In LangChain's

6:54blog post talking about graph

6:55engineering, they said that what changed

6:58wasn't the graph, but more in what the

7:00node can do. Back then, it was just an

7:02LLM call, nothing close to a full agent

7:05that we interact with every day like

7:07Claude Code or CodeX CLI. These agents

7:09are immensely better given their myriads

7:12of tools and harness environment. So,

7:14with the emergence of coding like

7:16Cursor, Kline, Rue, and Winster, which

7:19were one of the few early players back

7:21then when it comes to agents, they focus

7:23more on single agents in improving that

7:26very agent instead of extending them to

7:29various edges that form a graph of

7:31agents actually working together. And

7:33over time, these agents individually

7:35started to incorporate better

7:37methodologies, going from prompt

7:39engineering to context engineering,

7:41better harnessing, and now the

7:42bottleneck started to shift away from

7:45what the node can do, but into a graph

7:48and the edges that connect the nodes

7:49together. And now, no pun intended,

7:51we're coming full circle back to graphs.

7:54Because the nodes are reliable and more

7:56capable, we can now scale our agents

7:59from a single agent to a workflow or a

8:01graph to target a much wider set of

8:04problems like we saw in deep research,

8:06which would have been really difficult

8:08for a single agent to solve. So, going

8:10back to Euler's case, his challenge was

8:12to determine the feasibility of crossing

8:14all seven bridges exactly once, which

8:17led to the birth of graph theory. In our

8:19case, our adaptation of graph theory

8:21into agents is determining how a task

8:24can be divided in a way that a highly

8:27capable node now should structurally be

8:29configured to solve a much more

8:31complicated task that we give our agents

8:33to solve.