Transcript
00:00:00There's a new term going around called graph engineering, and everyone on X is talking about it.
00:00:04Before graphs, it was all loop engineering, where you hand the agent a goal and it works toward it
00:00:09on its own. But with graphs, the work gets done faster and covers way more ground at once than
00:00:14a loop ever could. There's a huge problem with them though. One error in a small part of the
00:00:18graph disturbs the entire output that comes back, and it's hard to track down because all you get
00:00:23at the end is the finished result. So Anthropic just released something that solves that exact
00:00:27problem and keeps your graphs working without failing. If you're new here, we're a software
00:00:32company, and this is our channel AI Labs, where we show you how to optimize your business with AI,
00:00:37and if you don't have your own, you can use these skills to get paid by optimizing it for someone
00:00:42else. And in this video, we're going to go over graph engineering for anyone who doesn't know it
00:00:46and give you the exact fix Anthropic suggested. Before we explain graph engineering to you, you
00:00:52need to understand what loop engineering actually is. If you already know, you can skip this section.
00:00:56A loop is basically a working cycle you hand over to the agent. Instead of you prompting it through
00:01:02every single step yourself, you tell it the end goal it needs to reach, and it gets there on its own,
00:01:07adjusting as it goes. We've been using them heavily in our own workflows. We've already got a full video
00:01:12on loop engineering too, where we went deeper into the different ways you can set them up, but loops
00:01:17are now turning into something called graphs. The problem with loops comes down to the way they're built.
00:01:22A loop does a piece of work, then a verification step kicks in to see if it's actually the way it should
00:01:27be. Once it passes, the next step starts. Everything runs in a straight line, so every step sits there
00:01:32waiting on the step before it, even when the two have nothing to do with each other. Graph engineering
00:01:37fixes exactly that. Instead of running in a straight line, a graph splits the main task into smaller
00:01:42parts, and each part gets its own agent. The first thing you get out of that is speed, because several
00:01:47agents cover the work at once, instead of one agent grinding through the whole thing. And splitting the
00:01:52work out like that brings the cost somewhat down too, because you get to pick which model each one
00:01:56runs on. So you stop burning your most expensive model on the parts that never needed that much
00:02:01intelligence in the first place. But that's the cost per agent, not the cost overall. A graph burns way more
00:02:07tokens than a single agent ever will, because you've got a whole set of them going at once instead of one.
00:02:12If you are using graphs, expect your limits to hit way sooner than you're used to, so you can't
00:02:17really set this up with the $20 plans of ClaudeCode and Codex. Now if you've been using ClaudeCode,
00:02:22this probably isn't entirely new to you, because you've already seen a graph which is the dynamic
00:02:27workflow. A dynamic workflow takes the task you hand over and fans it out across a set of sub-agents,
00:02:33which is basically what a graph does. Now before we get into the shapes a graph can take, you need to
00:02:38know what actually makes one up. Every graph is built out of two things: nodes and edges. A node is
00:02:44basically a single job out of the bigger task you handed over, and it runs on its own. It is an agent
00:02:49that does a task in its own isolated context window and reports back. What ties all those separate jobs
00:02:55together is the edge. An edge controls how the data moves from one node to the next, so one agent's output
00:03:01lands with the right agent at the right point. So every node's got to be tied into the rest of the graph
00:03:06somehow. You can see that in a set of agents all reviewing the same piece of work. None of them
00:03:10ever wait on each other. But they all started from the same work, and every one of their reports feeds
00:03:15into the same place at the end, so that's what a graph is made of. Now here are the shapes those pieces
00:03:20get arranged into. The first one's a shape we've already shown you on this channel, and we got the name
00:03:25wrong at the time. We called it a loop, because this was before graph engineering was even a thing. But
00:03:30what we actually had was a graph that we were looping, and the shape of it was a diamond. One task at the
00:03:35top splits out into several sub-agents running side by side, then they all narrow back down into a single
00:03:41agent that pulls everything they found into one answer. Then there's the fan in at a barrier graph,
00:03:46and that's the shape you want when one thing has to be judged from several angles at once. The fan out
00:03:51part sends the same problem out to a set of agents, and each one looks at it through a different lens.
00:03:56Nothing moves forward until every one of those agents has reported back, and only then does it
00:04:00go and run their fixes. There are plenty of other shapes too. But every one of these shapes rests on
00:04:05the same thing, and that's verification. If you don't set those checks up properly, every agent that comes
00:04:10after is just building on top of a mistake. But before we talk about verification, it would be great if you
00:04:15subscribe to the channel and hit the hype button. This small gesture of support goes a long way for us.
00:04:20Once you're running a whole fleet of agents, things go wrong in ways they never do with a single one.
00:04:25The biggest problem is just the amount of work. They're all going at the same time, so a huge pile
00:04:30of it comes back at once, and that's really hard to review at the end. The other problem is that
00:04:34you can't see what happened. When something goes wrong, you've got no way of telling what caused it.
00:04:39Now all agents verify whatever they write, whether you ask them to or not. If you're working with code,
00:04:44that just means the agent runs your tests and catches the errors that come back. But that only catches major
00:04:49errors. It still doesn't check how the code is written, and that's important because if Claude
00:04:53keeps writing it like this, it's going to cause problems in the future. There are a few built-in
00:04:58tools for this in Claude code as well. The first is the verify skill, which takes the code from start
00:05:03to finish and confirms it actually behaves the way it's supposed to. The second is tool chaining, which
00:05:08is basically the agent running different tools to verify. Claude already knows to run the tools that
00:05:13check your work, so it reads the errors that come back and fixes them itself. It can work out your
00:05:18project's exact commands on its own too. But writing them into your Claude.md file saves it the trouble
00:05:24of figuring them out every single time. And the third is a code review skill, which checks the code
00:05:29against a set of standards. Not every agent ships with one, but you can just ask your agent to build
00:05:33you one if yours doesn't. But the verification that actually works best is the one you set up yourself,
00:05:38instead of leaning entirely on the built-in stuff. So the fastest way to build a skill that verifies
00:05:44your work is the skill creator plugin in Claude code. You can also use this Claude code skill in
00:05:49Codex as well. You run the plugin command, search for skill creator and install it. From there,
00:05:54you've got two options. You can install it at the user scope, which means it's there no matter which
00:05:58folder you're working in. Or you can install it just for the project you're working in right now.
00:06:03Since this is a skill you'll be using constantly, we went with the user scope. After that,
00:06:07you reload the plugins with the slash command and skill creators ready to be used. Now you tell it
00:06:12what you want built and this is the part where you describe the kind of verification you're actually
00:06:17after. We mostly use a review skill for checking the finished work against what we asked for in the
00:06:22first place. And that matters way more in a graph because each agent only ever sees its own piece.
00:06:28This is what gives it a way to check that piece against the original requirements. But a skill is
00:06:32only ever as good as the model you run it on. When we were building the verification system for our
00:06:37community website's UI, we ran the reviewer on Haiku because it's cheap and the job looked simple
00:06:43enough. It came back with a long list of issues. Going off the number of findings alone, it looked
00:06:47like it had done a great job. Then we ran the exact same on Opus and it flagged way fewer things.
00:06:53That looked like the worst result, right up until we read the reasoning. A lot of what Haiku had reported
00:06:58was stuff we'd left there on purpose. So most of the findings it made were completely unnecessary.
00:07:03Opus had worked that out from the code around it, which Haiku had missed it completely. So the cheap
00:07:08review hadn't saved us anything because now the review itself needed reviewing. Now put that inside
00:07:13a graph where a whole set of nodes are all checking their own work with that same skill. You'd have
00:07:18agents burning time and tokens fixing things that were never broken. And because it's happening across
00:07:23separate agents all at once, you'd have no way of telling which one started it.
00:07:27So the model you pick doesn't just decide the quality of the review, it decides the quality
00:07:31of the whole graph. The node that does the judging is the one place where saving tokens costs you
00:07:37everything. The other thing you've got to decide is how and when that skill gets invoked. And that
00:07:41splits them into three kinds. But before we go deep into the types, let's have a word by our sponsor.
00:07:46If you've ever pulled live data off the web, you know scraping is a genuine pain, where you end up
00:07:51fighting captures and rate limits, wrestling with proxies, and patching layouts that break the
00:07:56moment you ship. So we reach for SERP API, which solves all these problems so you can focus on building.
00:08:01It's one API call, you send a request and get back a clean JSON object with exactly the data you need
00:08:07with over 99.9% uptime and around a 1.2 second response. When you're building AI agents, you can
00:08:14point the Google search API at an agent that needs current information or use the Google Scholar API for
00:08:20peer reviewed papers with full metadata, which is why so many production agents rely on it. Get started with
00:08:25250 free credits using the link in the description or scan the QR code on screen. Thanks to SERP API for
00:08:32sponsoring this video. The first kind is standalone, and that's the sort of skill that only runs when you
00:08:37actually do it yourself. A standalone skill is built to go deep on something that already exists, so it can
00:08:42properly go back over a finished output. That's why you don't want it firing after every single run. You'd be
00:08:48burning tokens on a heavy review of work that isn't even finished yet. One we've used before is the
00:08:53thermonuclear code review by Cursor. It fans out a set of agents and sends each one through the code from
00:08:59a different security angle. Every finding comes back in one place, so it can work through the fixes
00:09:04together, and that's exactly the kind of review you only run once the app's done. To build one of these, you're better off using
00:09:10skill creator than just prompting it to do it, because what comes back is tested, and that makes it easier
00:09:15to trust. You tell it in the prompt which area you want reviewed, and make sure you mention that the
00:09:20review should be comprehensive so it knows you're after a deep pass and not a quick one. But a standalone
00:09:26skill is no use to a node that's still working, because you have to run it yourself. That's what embedded
00:09:31skills are for. An embedded skill fires as part of the workflow you're already running without you asking for
00:09:36it. You could build one that kicks in whenever somebody asks for a new feature. It checks that
00:09:41every component being created follows the rules you laid out in the skill, and it won't let the
00:09:45implementation finish until it's been checked against those rules. You can build embedded skills
00:09:50yourself, but you can't take a pre-installed one and have them be invoked automatically, like the
00:09:54verify skill we talked about earlier. The instructions those skills run on sit inside the product, and you
00:10:00don't get to touch them. To build your own, give skill creator a prompt telling it to run verification
00:10:05steps after every feature implementation, so you tell it to test the feature from start to finish so it
00:10:10catches whether the new work broke anything that was already working. Claude then creates the skill for
00:10:16you, and because skill creator generated it, it comes with references and scripts that skill creator
00:10:21structured and tested as part of the process. Now to verify a feature, Claude uses browser testing by
00:10:26default where it checks the interface by opening a full chrome browser, loading the page, and taking
00:10:31screenshots of it. And if you've wired up puppeteer or playwright, which are basically the tools most
00:10:36people use to drive a browser automatically, they do the same thing. But chrome's famous for eating memory
00:10:41and running heavy, and for checking a page over and over inside a workflow, it's slow enough that it
00:10:46starts costing you real time. So there's a lighter way to do it, called chrome headless shell. It's basically
00:10:52a stripped down version of the browser with all the extra parts ripped out. The agent still goes to
00:10:57the page and takes its screenshots the same way. It just gets through all of it way faster than a full
00:11:02chrome does. You can build that straight into the verification skill you create. Then every feature
00:11:07the agent builds gets checked visually without you setting anything up each time. Asides from that,
00:11:12the skill we use the most in our own workflow is one called second opinion, and the reason is simple.
00:11:17The agent that built the thing is the worst possible one to review it. It's judging its own work off the
00:11:23same context it used to build it, so it just reviews based on that. A fresh Claude session hasn't seen
00:11:28any of that. It gives an unbiased review and gives you a straight answer. Now Claude does have a built-in
00:11:33advisor that does something along these lines, but it reads the chat you're currently in so it inherits
00:11:38all that same context. Second opinion is for when you want the review without it. It works by starting
00:11:43another Claude session from inside the one you're already running, using the -p flag. That's the
00:11:48flag that fires off a whole separate Claude code session in the background by handing it a prompt to
00:11:53work on. There are a couple of things you need to know if you're going to use this though. Since it's
00:11:57launching an entirely separate session, it takes a really long time to come back with an answer,
00:12:02and the model matters here more than anywhere else, because the whole point is a smarter second read.
00:12:07So it's worth telling Claude explicitly to start that session on Opus. That gives every node in your
00:12:12graph a way to get its work checked by something that had no hand in doing it. But one skill can't
00:12:18cover everything though. Once you're reviewing something properly, you're reviewing it from several
00:12:22different angles, and every angle has its own way of measuring. You can't stuff all review types into
00:12:27one skill, because that way agent will have too many directions to review and will end up getting worse
00:12:33instead of better. So you build a separate skill for each angle and chain them together. Anthropic's own
00:12:38team works this way too. They chain the code review skill together with the simplify skill and the verify
00:12:43skill, and all three of those now ship with Claude code. On top of that, they run their own design skill,
00:12:49which checks the interface against the design.md file, which is basically the file that holds every
00:12:54design decision for the product. So that's a review coming from four directions instead of one. You'll
00:12:59end up in the same place, with a stack of skills that each cover a different angle. But you can't just
00:13:04tell the agent to run all of them at once. What you need is one more skill sitting above the rest,
00:13:09which is basically an orchestrator skill whose only job is to run other skills. It spins up an agent for
00:13:15every review skill you've got and hands each one its skill. They all review at the same time in their
00:13:20own separate context windows. Then it pulls every finding back into one report that the fixing agents
00:13:25can work from. Then when you're building a graph, the only thing you have to say in the prompt is that
00:13:30it should use that one skill. Every node it spins up loads that single skill and the whole review fans
00:13:35out underneath it on its own. Now we have curated a document containing all the ways you can set up
00:13:40verifications for graphs in detail. That doc along with all the skills shown in this video are available
00:13:45in AI Labs Pro, which is our community. So if you've found value in what we do and want to support the
00:13:50channel, this is the best way to do it. The link's in the description. That brings us to the end of this
00:13:55video. If you'd like to support the channel and help us keep making videos like this, you can do so by
00:14:00using the super thanks button below. As always, thank you for watching and I'll see you in the next one.