In today’s newsletter:

• Glean: Cut Agent Cost per Task 4x With Model Routing

• Loop vs Graph Engineering Clearly Explained

Reading time: 5 minutes.

Cut Agent Cost per Task 4x With Model Routing

When an agent task costs too much, the first instinct is to swap in a cheaper model.

But a task's cost has two parts. How many tokens it burned, and what you paid per million on average. Multiply those and you get the bill.

Swapping to a cheaper model only lowers the price per million. It usually raises the token count instead, because a weaker model retries more, wanders more, and takes more turns to land the same answer.

Glean recently benchmarked its own agent against Claude Cowork on the same tasks. Glean averaged $0.45 per task against $1.84, which is 4x.

Where the 4x Came From

Glean attributes it to three things:

• Model family routing. Work gets routed between open and closed models. Luna handled a large share, and Luna runs about 10x cheaper than Claude Sonnet while staying widely capable.

• Model tier routing. Opus was used 10x more often in Glean than in Claude Cowork, 29% of calls against 2.8%, but surgically and balanced by other models.

• Better context. Glean's harness and indexing meant fewer tokens consumed per query. Claude Cowork used 88.8M tokens against Glean's 29.8M, about 3x per query.

The first two set the blended rate. The third sets the volume.

Routing Beats Picking

Glean used Opus ten times more often than Claude Cowork and still came out cheaper.

That's only possible when the other models are carrying the routine work. Once they are, sending the hard steps to a stronger model costs you very little, because those steps are a small fraction of the total.

A single-model setup can't do that. One model handles everything, which makes it overpowered for the easy steps and underpowered for the hard ones.

An agent that has to search before it can answer pays for the searching. Reading files it doesn't need, running queries that come back with near-misses, and reasoning about the gaps are all billed. Better retrieval means never spending those tokens.

See the Full Results →

Loop vs Graph Engineering Clearly Explained

In July 2026, OpenClaw creator Peter Steinberger posted one line on X. "Are we still talking loops or did we shift to graphs yet?"

Within hours, AI researcher Hamel Husain posted a blunter version. "Loop Engineering Is Dead. Enter Graph Engineering."

A few days later, there were courses, roadmaps, and tool stacks around graph engineering. Underneath the noise, there's a real decision you have to make when you build something. Most people treat it as picking a side, and that's the wrong instinct.

So let's define both properly and work out how you'd actually choose between them.

What a Loop Is

A loop is an autonomous cycle where an agent plans, acts, and verifies repeatedly, without a human re-prompting it at every step.

That was a real change. Before loops, the human was the loop, manually reviewing each output and deciding what came next. Loops handed that cycle to the agent.

Linear's Loops feature is the clearest recent example. Recurring autonomous workflows for bug triage and doc updates, running on schedules or triggers, with nobody typing another prompt.

What a Graph Is

A graph takes that idea one layer up. Instead of one agent running one cycle, a graph wires multiple loops together, with nodes representing individual tasks and edges representing the flow between them.

If loops made individual agent behaviour programmable, graphs made the organization of agents programmable.

LangGraph, Microsoft AutoGen, and Google ADK were all shipping this pattern before graph engineering became a trending term.

The relationship between the two is the part the debate kept missing. A loop is not the opposite of a graph. A loop is one node in a graph.

Think of it like one person doing a job end to end versus a team where each person owns a step. The team is not a replacement for the person. It's several of them, with defined handoffs.

So you don't graduate from one to the other. You start with a loop, and you reach for a graph when one loop is no longer enough to hold the work together.

Choosing Between Them in Practice

The decision doesn't happen upfront. Nobody designs a system by choosing between loops and graphs as competing philosophies, since the choice reveals itself as the work grows.

A loop is the right starting point for almost everything. If your problem is a single coherent task with one agent, a clear goal, a way to verify its output, and a condition for stopping, a loop handles it cleanly.

Adding a graph at that stage is complexity you pay for twice. Harder to debug, and no more capable.

A graph becomes the right call when:

• The work splits into parallel tracks that need to run simultaneously rather than sequentially.

• Different agents need different contexts, memory, or permissions to do their part.

• You need explicit auditable control flow where every decision point is visible and traceable.

Klarna runs LangGraph in production across 85 million active users, cutting customer query resolution time by 80%. Uber used the same architecture to save roughly 21,000 developer hours through automated test generation and code validation.

Both were building this way before graph engineering had a name.

The Case That It's Just a Rebrand

Every time a term goes viral, the same question follows. The skeptics here have a point worth taking seriously.

LangGraph shipped in January 2024, with Microsoft AutoGen and Google ADK following. Wiring multiple agents together with explicit state and control flow was available and documented well over a year before anyone called it graph engineering.

Reaching for a graph when your loop is broken doesn't fix the loop. It gives you a more complex system with the same underlying problem.

The naming pattern is hard to ignore. Prompt engineering became context engineering, then harness engineering, then loop engineering, and now graph engineering. Mostly the same job, described from a different distance each time.

Is there a Real Change?

Graph engineering did not replace loop engineering. It was already being built quietly by teams whose problems had outgrown a single loop, long before the term existed.

So picking a side was never the point. Start with one loop, push it until you find where it breaks, and let that failure tell you which node to split out next.

To get practical with these concepts, we maintain a hands-on AI engineering repo with working implementations of loops, graphs, and the patterns around them.

Hands-On AI Engineering →

That’s all for today. Thank you for reading today’s edition. See you in the next issue with more AI Engineering insights.

PS: We curate this AI Engineering content for free, and your support means everything. If you find value in what you read, consider sharing it with a friend or two.

Your feedback is valuable: If there’s a topic you’re stuck on or curious about, reply to this email. We’re building this for you, and your feedback helps shape what we send.

WORK WITH US

Looking to promote your company, product, or service to 200K+ AI developers? Get in touch today by replying to this email.