Solutions for
Please select
Try the Web App
ki-konzepte

Building AI Agents — From Tool Use to Multi-Agent Systems

Redaktion ·

When is it actually an agent — and not just a loop with an LLM

In 2026, “agent” is the buzzword pinned on everything: a chatbot with two tools, a pipeline of three LLM calls, a Cursor-style IDE plugin, an autonomous research system. A useful definition: an agent decides at runtime which tools to call, when to call them, how often to loop, and when it is finished. A workflow, by contrast, runs along predefined paths — your code calls the LLM in a planned sequence, and the model makes no control decisions.

This split is not academic. Anthropic draws it deliberately in “Building Effective Agents” because most production systems do not need agents — a deterministic workflow is cheaper, faster and easier to debug. The agent loop is only worth it when the task is unpredictable enough that the steps can’t be listed up front. This article walks from a single tool call to a multi-agent setup and points out, along the way, where added complexity is still worth it — and where it isn’t.

The agent loop — what happens inside

Strip an agent down to its minimum and what’s left is a loop with four phases: observe → plan → act → evaluate. The model receives a state (system prompt, conversation history, tool results), picks an action (typically a tool call with arguments), the tool executes, the result flows back into the context, and the model decides whether the task is done or the loop runs another iteration.

Out of this fall three building blocks no agent works without: a mechanism for the model to call tools (Function Calling), a mechanism for tools to return machine-readable answers (Structured Output), and a stop condition that exits the loop when an agreed-upon signal arrives (typically: the model emits no further tool call, just a plain text answer).

Tool use as a contract between model and code

Function calling has been a standard feature of every relevant LLM API since 2023. You describe tools as JSON schemas (name, description, parameters with types); when the model wants to use a tool, it returns a tool_call block with the tool name and arguments. Your code runs the tool, writes the result back as a tool_result in the message list, and sends the extended list to the model again. The model now has the same mechanism a human has when reading API docs: it knows what a tool does because the description tells it — not because it was trained on this specific tool.

In practice, the quality of an agent largely rides on tool descriptions. Anthropic recommends treating tool definitions like carefully documented functions: concrete examples, clear conditions for when not to use a tool, precise error messages. When tools are poorly described, the model hallucinates arguments or calls the wrong tool — that’s not a model bug, it’s an interface bug.

Structured output and the response schema

As soon as a tool needs to return data in a specific shape — not just “do something” — you need structured output. Three approaches are common: forcing the model into JSON via the tool-calling schema or a JSON mode, validating with Pydantic/Zod at the boundary, or using constrained decoding (vLLM, llama.cpp) that enforces valid JSON tokens at the token level. The latter is robust but tied to the inference engine.

Stop conditions — the most common bug

Endless loops are the classic failure mode. Three guards are non-negotiable: a hard iteration cap (e.g. “max. 25 tool calls per request”), a per-request token budget, and a stop signal the model emits explicitly (an answer with no tool call, or a dedicated finish tool). Without all three, an agent can drift into a repair loop where it issues a slightly varied version of the same broken tool call twenty times — and token costs grow with every iteration.

MCP — from tool call to tool platform

Function calling is vendor-specific: the JSON schema looks almost identical across OpenAI, Anthropic and Google, but you have to integrate the tools themselves once per vendor. The Model Context Protocol (MCP) changes that dynamic. It defines a standard protocol by which an MCP server (an application exposing tools, resources or prompts) plugs into an MCP client (an AI assistant or agent). Anthropic announced MCP in late 2024; through 2025, OpenAI, Microsoft, Google and AWS added support to their own stacks; in December 2025 Anthropic donated MCP to the Agentic AI Foundation as neutral infrastructure. The current spec is dated 25 November 2025.

In practice that means: an MCP server you write once for your internal APIs can plug into Claude, ChatGPT, Cursor, Microsoft 365 Copilot and LangGraph, with no per-client adaptation. That was an exotic case in 2024; in 2026 it’s the default. According to MCP adoption tracking, the protocol clears roughly 97 million SDK downloads per month in early 2026, with more than 5,800 published servers.

Code execution with MCP — the token lever

A noteworthy 2026 development: instead of routing every tool call through the model individually, the agent can write code that orchestrates several tool calls and returns only the final result to the model. Anthropic describes this in an engineering post with a concrete example: mirroring a two-hour meeting transcript from Google Drive to Salesforce costs around 150,000 tokens with direct tool orchestration, because the transcript flows through context multiple times. With code execution the same workflow drops to roughly 2,000 tokens — a 98.7 percent reduction. The pattern doesn’t pay off for every task, but for data-heavy workflows with many intermediate steps it’s the lever of the year.

Five workflow patterns before the first real agent

Before you build an autonomous agent loop, check whether one of the five workflow patterns from Anthropic’s playbook is enough. These patterns use deterministic control — you control the path, not the model — which makes them cheaper, faster and easier to debug.

Prompt chaining

A task is split into fixed sub-steps; each step is its own LLM call whose output flows into the next. Classic example: draft → edit → publish. Use it when the steps are stable and accuracy beats latency.

Routing

A first LLM call classifies the input (support ticket: billing / technical / sales?) and routes it to a specialised follow-up prompt. Benefit: one tight prompt per category instead of one mega-prompt for everything.

Parallelization

Several LLM calls run in parallel — either as “sectioning” (one task split into independent parts: translate three paragraphs simultaneously) or as “voting” (three parallel calls answer the same question, a fourth consolidates). Saves latency or boosts robustness.

Orchestrator-workers

A central orchestrator LLM splits an unclear task into sub-tasks on the fly and delegates them to worker LLMs. Example: “Find every competitor in the DACH market with ARR > €10M” — the orchestrator decides which queries to run, a worker handles each, the orchestrator consolidates. Becomes an actual agent the moment the worker count is no longer fixed up front.

Evaluator-optimizer

A first model produces an answer, a second evaluates against clear criteria, the first revises. Loop until the evaluator says “ok” or an iteration cap kicks in. Works whenever the evaluation criterion can be stated cleanly (code compiles, tests pass, format valid).

Frameworks — when to use one, when to skip

You can build an agent on the bare Anthropic or OpenAI API in 200 lines of Python. That’s often the right answer. Frameworks pay off once state gets complex — persistence between runs, human-in-the-loop, time-travel debugging.

LangGraph is the most widely used framework for stateful agents in 2026. It models the agent as a directed graph: nodes are functions or LLM calls, edges define transitions, a typed state object flows through the graph. The advantage over hand-rolled code isn’t the graph itself — you’d get that with a switch-case — but the built-in checkpointing: every state transition is persisted. That enables time-travel debugging, human-in-the-loop (pause graph, wait for human approval, continue) and mid-run failure recovery. LangGraph 1.x has been stable since early 2026; the repo passes around 30,000 GitHub stars in spring 2026.

Also in the picture: CrewAI for role-based multi-agent setups, AutoGen (Microsoft) for research and conversational agents, OpenAI Agents SDK for the OpenAI platform integration. Rule of thumb: if your agent has fewer than five steps and no persistent state, hand-rolling is faster. As soon as you want checkpointing or multi-agent coordination, the framework’s value kicks in.

Multi-agent setups — when they pay off

Multi-agent sounds tempting (“several specialised agents working together”), but it brings real overhead: token usage grows super-linearly because each agent carries its own context; coordination bugs become the dominant failure class; latency stacks up. Rule of thumb: only escalate to multi-agent when a single agent clearly fails to keep tasks separated — i.e. when the one prompt grows too long, tool lists balloon past 30–40, or different sub-tasks demand prompt styles so different that a shared prompt is just a compromise.

When you do reach for multi-agent, the orchestrator-worker pattern from Anthropic’s playbook is the pragmatic entry point: one supervising agent owns the task and delegates; several workers each specialise in one task type. It’s manageable because the hierarchy is explicit. Fully emergent multi-agent swarms are a 2026 research and demo staple, but rare in production — debuggability isn’t worth it.

Pitfalls — four classics

Endless loop without a stop condition. Already mentioned, but common enough to repeat. Max iterations, max token budget, explicit stop signal — all three.

Token accumulation per tool call. Every tool result stays in context and is sent again on the next model call. A 20-iteration loop with 5k-token tool answers grows your input to 100k+ tokens before you finish. Mitigation: summarise or drop tool results once they’re no longer needed. Code execution with MCP (above) is the more radical fix.

Tool hallucination. The model calls a tool that isn’t in the schema, or invents arguments not in the schema. Gets worse with long tool lists. Defense: strict tool whitelisting on the server side — not “please don’t hallucinate” in the prompt, but reject the call outside the schema and return the error message (“Tool ‘X’ does not exist. Available: …”). The model self-corrects from the error context faster than from any prompt trick.

Implicit stop condition in multi-agent setups. In orchestrator-worker setups, builders often forget that the orchestrator itself needs an iteration cap — otherwise it can re-dispatch workers indefinitely, because no worker result ever feels “good enough”. Symptom: the task seems done, but the system asks one more worker. Cure: a hard delegation cap per task type.

A short cost example — single-agent vs. multi-agent

Picture a research task that needs five parallel web searches and two internal API calls. With early-2026 pricing and Claude Sonnet as the model:

| Setup | Iterations | Avg input per call | Avg output | Tool calls | Estimated cost | |---|---|---|---|---|---| | Single-agent, naive | 9 | 8,000 | 800 | 7 | ~$0.28 | | Single-agent with tool-result trimming | 9 | 4,000 | 800 | 7 | ~$0.15 | | Multi-agent (orchestrator + 5 workers) | 18 (total) | 6,000 | 600 | 7 | ~$0.40 |

Numbers are illustrative; the point is the direction. Multi-agent isn’t cheaper, it’s more expensive — you pay the surcharge for specialisation, not for savings. Adopting multi-agent on cost grounds is the wrong argument; adopting it for task separation, with the surcharge in the budget, is the right one.

Conclusion

AI agents in 2026 aren’t magic; they’re a disciplined loop with three required building blocks (Function Calling, Structured Output, stop condition) and four pitfalls everyone trips on once. The most important step happens before the agent: would a workflow do? If yes — build, ship, done. If no, the overhead is justified, and from day one it’s worth thinking about iteration caps, token tracking and an eval path.

MCP has turned the tool landscape of 2026 into a real ecosystem — write an MCP server for your domain and you’ve connected Claude, ChatGPT and half a dozen other clients in one go. Frameworks like LangGraph absorb the state-management boilerplate as soon as your agents need persistence or human-in-the-loop. And multi-agent is the last escalation step, not the default — as long as a single agent solves the task, let it work.

If you want to dig deeper: the specifics of tool use and structured output live in their respective glossary entries — and for the pricing layer below (what does an agent request actually cost in tokens) there’s the AI pricing lexicon.

Themenuebersicht

KI-KonzepteAgenten