Latest / AI Fire Daily / #555 Neil: AI Workflow Fixes Errors Faster With Graph Engineering

Transcript

#555 Neil: AI Workflow Fixes Errors Faster With Graph Engineering · AI Fire Daily

• 0:00
  You know, it's genuinely wild to think about
• 0:03
  how fast AI is evolving right now. We used to
• 0:07
  just type simple instructions. Yeah, just beg
• 0:09
  in a text box for good answers. Right. And now
• 0:12
  we are building entire virtual organizations.
• 0:15
  Welcome to the deep dive. Today, we are exploring
• 0:19
  the evolution of talking to AI. Is such a master
• 0:22
  shift. It really is. Think about the natural
• 0:25
  progression we've seen. First, we started with
• 0:28
  basic prompt engineering. You just tried to type
• 0:30
  the perfect question. Then we realized the AI
• 0:34
  needed background material. Right, which led
• 0:36
  straight to context engineering. We started stuffing
• 0:38
  huge documents into the prompt window. Exactly.
• 0:41
  And from there, we moved to loop engineering.
• 0:43
  We made the AI repeat and refine its own work.
• 0:45
  Over and over. Yeah. But today, we are heading
• 0:48
  somewhere entirely new. We're unpacking something
• 0:51
  called graph engineering. Which I am so excited
• 0:54
  about. I know. It sounds like overly technical
• 0:56
  jargon, but it's actually a natural, highly practical
• 0:58
  evolution. It fundamentally changes how we delegate
• 1:01
  work. It totally demystifies the black box. Graph
• 1:05
  engineering divides one massive workflow. It
• 1:07
  breaks it into smaller connected parts. So instead
• 1:10
  of one AI agent handling a whole process. Right.
• 1:13
  From start to finish, you deploy several specialized
• 1:15
  agents instead. And we should probably define
• 1:18
  that. A specialized AI program designed to do
• 1:21
  one specific job. That is the perfect way to
• 1:23
  phrase it. And unlike loop engineering, where
• 1:26
  one agent repeats a cycle, graph engineering
• 1:30
  uses several specialized agents. I like to picture
• 1:32
  this like an assembly line or, you know, stacking
• 1:35
  Lego blocks of data. You wouldn't ask one person
• 1:38
  to build an entire car from scratch. Exactly.
• 1:41
  And every single part in this graph. has four
• 1:44
  strict requirements. First, it needs an input.
• 1:47
  Second, it needs a task. Third, an output. Fourth,
• 1:50
  this is huge. It needs success criteria. Checking
• 1:53
  the result before moving it forward. Yes. If
• 1:55
  a result fails, it loops back. But it only loops
• 1:58
  back within that specific part. So does this
• 2:00
  mean we're just micromanaging the AI? Oh, no.
• 2:03
  It's not micromanaging at all. It's about providing
• 2:06
  necessary boundaries. So the AI doesn't get confused
• 2:09
  by massive multi -step tasks. Right. So less
• 2:14
  micromanagement, more giving the AI a clear single
• 2:17
  -lane highway. Precisely. But giving an AI a
• 2:19
  single -lane highway requires good traffic control.
• 2:22
  Oh yeah, serious traffic control. So let's look
• 2:25
  at a concrete map of how this actually runs daily,
• 2:28
  like that AI news report workflow from our sources.
• 2:31
  Yeah, that is a great example to take this from
• 2:33
  theory to practice. It's a parallel workflow
• 2:36
  triggered daily. It builds a news report. And
• 2:39
  it uses four research agents working at the exact
• 2:42
  same Right. First up is the YouTube agent. It
• 2:45
  finds three to five videos under 24 hours old,
• 2:48
  it requires working links, and it completely
• 2:51
  excludes low -value topics. And then there's
• 2:53
  a retry rule. Right. Exactly. If it finds fewer
• 2:55
  than three videos, it broadens its keywords automatically.
• 2:58
  Meanwhile, you have the ex -agent running beside
• 3:00
  it. It finds announcements under 24 hours old.
• 3:03
  It prioritizes official company accounts or researchers.
• 3:06
  And it separates facts from opinions, which is
• 3:09
  critical. Then there's the Reddit agent, finding
• 3:12
  three to five practical user feedback threads.
• 3:15
  No speculation allowed. It requires real technical
• 3:18
  context. And finally, the email agent. It checks
• 3:21
  newsletters, ignores peer promotions, and preserves
• 3:25
  original links. So you have these four specialized
• 3:27
  agents gathering data simultaneously. Then they
• 3:32
  hit a bottleneck node. the report agent. Which
• 3:35
  is basically acting as a middle manager. Exactly
• 3:38
  like a middle manager. Yeah. It waits for all
• 3:40
  four. It groups the updates and removes the repeats.
• 3:43
  Then it drafts an 800 to 1200 word report, structured
• 3:47
  logically. Like top updates or new models. Yeah.
• 3:51
  And then it goes to the final checkpoint. The
• 3:53
  review agent. The ruthless editor. Right. It
• 3:56
  checks links, links, and source accuracy. And
• 3:58
  if it finds a broken YouTube link, it isolates
• 4:00
  the failure. It only sends that section back
• 4:02
  to the YouTube agent. The rest of the draft stays
• 4:04
  untouched. Exactly. You know, I have to make
• 4:06
  a vulnerable admission here. Oh. I still wrestle
• 4:09
  with prompt drift myself when I ask a model to
• 4:11
  do too much at once. It happens to all of us.
• 4:13
  Prompt drift is when an AI slowly forgets your
• 4:16
  original instructions over time. Yeah. And graph
• 4:19
  engineering prevents that entirely. So if one
• 4:22
  agent fails completely, does the whole report
• 4:24
  just crash? No, that's the beauty of graph routing.
• 4:27
  The workflow just pauses that one node. It requests
• 4:30
  a retry based on the rules, but it keeps the
• 4:33
  completed work safely stored. OK, got it. Only
• 4:35
  the broken piece restarts. The approved sections
• 4:38
  stay completely untouched. Exactly. So now that
• 4:41
  we see how the pieces move, why is this intricate
• 4:45
  setup vastly superior? you know, compared to
• 4:48
  just writing one really long prompt. Well, there
• 4:51
  are a few massive benefits. First is better quality
• 4:53
  by strictly separating the creator from the reviewer.
• 4:57
  Right. When an agent isn't judging its own work,
• 4:59
  mistakes are caught before they pollute the final
• 5:02
  answer. Exactly. A model is naturally biased
• 5:04
  toward its own outputs. A separate reviewer breaks
• 5:07
  that bias. The second benefit is faster execution,
• 5:11
  the diamond pattern. Let's explain that pattern.
• 5:13
  Sure. One note at the top splits the task. Then,
• 5:17
  workers do it in parallel. That's the wide middle
• 5:19
  of the diamond. And another node merges it at
• 5:22
  the bottom. It saves massive amounts of time.
• 5:25
  Whoa. I mean, imagine scaling that up to a billion
• 5:28
  queries across a thousand parallel agents. It's
• 5:32
  genuinely mind -bending to think about. And that
• 5:34
  massive scale leads to the third benefit, easier
• 5:38
  error tracking. Because every output belongs
• 5:40
  to a specific agent. Yes. You know exactly where
• 5:44
  a hallucination started. You can trace it in
• 5:46
  the logs and you can set a fixed retry limit.
• 5:49
  If it keeps failing you send it to a human. Does
• 5:51
  having a separate review agent really stop the
• 5:53
  AI from hallucinating facts? Well, it doesn't
• 5:56
  eliminate hallucinations entirely. But by giving
• 5:59
  the review agent only one job, verifying claims
• 6:02
  against sources, it catches the vast majority
• 6:05
  of them. That makes perfect sense. Separating
• 6:07
  the writer from the editor adds the friction
• 6:09
  needed to catch lies. Perfectly said. We are
• 6:11
  going to take a quick pause right here. We'll
• 6:13
  be right back. And we're back. So before the
• 6:15
  break, we were looking at these AI assembly lines.
• 6:18
  These massive, perfectly tuned system. Right,
• 6:22
  but just because we can build them doesn't mean
• 6:23
  we should use them for everything. Oh, definitely
• 6:25
  not. I feel like tech culture often over -engineers
• 6:28
  things, you know, just because a concept is trendy.
• 6:31
  It happens all the time. You have to know when
• 6:33
  to actually use it. So when should we use graph
• 6:35
  workflows? You use graph engineering when an
• 6:38
  AI has too much context to hold, when you absolutely
• 6:42
  need an independent reviewer. or when tasks can
• 6:45
  run at the same time. Parallel execution. Right,
• 6:48
  and when processing speed is critical. Okay,
• 6:51
  but when should we absolutely avoid it? If one
• 6:53
  single agent can already do the task with high
• 6:56
  quality, stop right there. Do not use graph engineering.
• 7:00
  Just keep it simple. Yes. Adding more agents
• 7:03
  to a simple workflow just adds unnecessary fragility.
• 7:07
  It adds extra steps and costs for no real reason.
• 7:10
  So if I'm just asking an AI to summarize a single
• 7:12
  meeting transcript, This is overkill. Absolutely
• 7:15
  overkill. A single prompt or loop is perfect
• 7:18
  for that. Graph engineering is for building systems,
• 7:22
  not doing your quick daily chores. Right. Keep
• 7:24
  it simple. Don't build a factory when you just
• 7:26
  need a hammer. So let's distill all of this into
• 7:29
  one overarching takeaway for you listening. The
• 7:31
  core philosophy here is it about making AI more
• 7:34
  intelligent. Right. It's about giving AI a vastly
• 7:37
  better structure. By dividing labor. By defining
• 7:41
  strict success criteria. and allowing parallel
• 7:43
  work, we gain ultimate control over complex workflows.
• 7:47
  We really do. Thank you so much for joining us
• 7:49
  on this deep dive. It was a fun one. Before we
• 7:52
  wrap up, I want to leave you with a final thought.
• 7:54
  We are currently creating highly complex workflows
• 7:57
  where AI agents manage, review, and correct other
• 8:00
  AI agents. Yeah, that's wild. So as these systems
• 8:03
  become more autonomous, at what point does the
• 8:05
  human's role shift entirely from being the creator
• 8:08
  to merely a manager of virtual managers? Something
• 8:12
  to mull over. Take care.