Wie viel Agent-Framework braucht eine KI-Anwendung wirklich?

Posted on Oct 22 • Originally published at shekharbhardwaj.com • AI-assisted

I came across a slide showing AI agent frameworks on a spectrum. Direct calls to a model sat at one end. At the other were tools with much more of the machinery already built in. In between: LangGraph, Strands, OpenAI Agents SDK, CrewAI, and plenty of others.

My first thought was that it was a useful way to organize a crowded space.

My second thought was that you could probably spend a week debating that slide without getting any closer to solving a customer’s problem.

That’s the part that interests me. Not which framework wins, but how quickly choosing a framework can become the work.

There’s an easy mistake to make when looking at a diagram like this: assume that moving toward the more fully loaded end means you’re building something more advanced.

It doesn’t. You’re mostly changing how much you build yourself and how many decisions the tool has already made for you.

LangGraph, for example, is a low-level orchestration framework for stateful workflows and agents. It gives you considerable control. But “low-level” doesn’t necessarily mean less work for the person building the application.

OpenAI’s Agents SDK takes a different approach, offering a small set of building blocks along with capabilities such as tool execution and tracing. Lightweight doesn’t have to mean bare-bones.

Claude Agent SDK comes with the agent loop, tools, and context management behind Claude Code. For an application that needs those capabilities, starting with them already available could be the simpler choice.

So I wouldn’t read that spectrum as “simple on the left, unnecessarily complicated on the right.” The useful question is how well each tool fits the work.

A framework that makes decisions you agree with can save you a lot of effort. One that makes decisions you keep fighting may become another problem to maintain.

Imagine a document-processing application. It receives a document, extracts a few details, checks them against business rules, and sends anything uncertain to a person.

There’s a sensible role for AI here. Reading messy, inconsistent documents is very different from comparing a validated number against a fixed limit.

Suppose the rule says anything above $5,000 needs approval. Once the amount has been extracted and checked, I’d rather let ordinary code enforce that rule. I don’t need the model to have an opinion about it.

This is a useful distinction between a workflow and an agent: a workflow follows predefined paths, whereas an agent can let the model decide how to proceed. Neither approach is automatically better. They give the model different amounts of control.

Now imagine turning that same application into a document-reading agent, a validation agent, a routing agent, and a supervisor agent.

Maybe there’s a good reason. But before approving the design, I’d ask what each handoff improves. Accuracy? Speed? A clearer separation of responsibilities?

“Because that’s how the framework’s example does it” wouldn’t be enough.

Otherwise, we might have taken a fairly ordinary workflow and given it middle management.

There’s an equally unhelpful response to all this: “Just use the API.”

That sounds wonderfully simple until your application needs to pause for approval, preserve its progress, recover from failures, and show someone what happened. Frameworks such as LangGraph provide infrastructure for persistence and human intervention precisely because those needs are real.

Refusing a framework on principle can leave you building your own version of one, except now your team owns every awkward corner of it.

I’d compare the whole job, not just the first working demo. How much code will we maintain? How will we investigate a wrong answer? Can another engineer understand the execution without needing the original author beside them?

A small application with a pile of homemade infrastructure isn’t necessarily simpler than one using a well-chosen framework.

Likewise, adding more agents can trade extra time and cost for better results. That trade might be worthwhile, but it deserves to be tested rather than assumed.

The question I’d ask is: does the more elaborate version perform well enough to justify what it adds?

Picture two proposals in a design review.

One describes an autonomous multi-agent platform with specialist roles and a supervisor. The other describes a controlled workflow with two model calls and a human approval step.

Before seeing either one work, which sounds more innovative?

I’d worry if the first proposal got an easier hearing simply because its vocabulary sounded more ambitious. That’s a leadership problem as much as an engineering one.

The less glamorous questions are the ones I’d want answered. What happens when the model gets it wrong? Who can stop an action? What will the team be maintaining six months from now? What evidence would convince us to remove a component?

None of those questions rules out a sophisticated agent system. They just ask it to earn its place.

I’m happy to use a framework that saves the team work. I’m also happy to build a small workflow that never needs one. I don’t see either choice as a statement about how serious we are about AI.

But I do think we should notice when someone makes a system smaller without making it less useful.

If an engineer removes three agents and the application becomes easier to understand, test, and operate, that should count as progress.

Even if the architecture diagram looks less impressive afterward.