AI Agents – Definition, Function, and Practical Application

AI agents handle tasks for which the solution path is not predetermined. For example, competitive research, anomaly detection in machine data, or cross-system inquiries.

The current understanding was established around 2023, when Large Language Models (LLMs) entered such systems as controlling components.

The theoretical foundation dates back to Russell & Norvig (1995)An agent is therefore an entity that perceives its environment and acts upon it.

An agent is used in business processes where a task requires multiple steps with decisions in between, and the path is not deterministic.

A common misunderstanding concerns the term Agentic AI: This is not a synonym variant of AI agent, but rather denotes the characteristic of autonomous, goal-directed action. The AI agent is the artifact, Agentic AI is the characteristic that it realizes. The LLM is also not the agent, but rather its cognitive core. This is arbitrarily interchangeable.

The term is currently being used in an inflationary way, primarily in product and marketing communication. Gartner calls the phenomenon „agent washing“: renaming existing chatbots, RPA bots, and assistants without actual agentic capabilities.

How to recognize a real AI agent

The most robust divider against agent-washing is a four-step criterion:

1. A true agent plans the next step,
2. runs it via a tool,
3. observes the result
4. and corrects course if necessary based on observation.

If one of these steps is missing, it's usually a chatbot with an API connection or a pre-wired workflow (automation).

The scale shows the vendor landscape: Gartner identified around 130 vendors positioning themselves as an agentic AI solution. However, Gartner considers most of these offerings to be relabeled assistants or chatbots without multi-step autonomy.

Those who want to be sure that it is a real AI agent can orient themselves by these three visible indicators:

• Dynamic Tool Selection The system decides at runtime which tool or data source it calls. There is no pre-configured path. If every step is visible in the Flow Editor, it is a workflow.
• Intermediate observation influences the next step: With the same input, but different intermediate results, the system performs different subsequent steps. Anyone who cannot reproduce this does not have an agent in front of them.
• Persistent memory across sessions: The agent can access previous interactions or intermediate states. A stateless single-turn bot cannot do that.

How do I build an AI agent?

An agent doesn't arise from a single tool, but from multiple layers working together:

1. as the language model's cognitive core,
2. a framework that controls the loop,
3. an integration with the tools the agent works with,
4. and a layer that records every step.

Those who distinguish these layers will find their way around the tool landscape more quickly than by using provider lists.

The first decision only concerns one of these layers, namely the framework (2.): Do you write the agent yourself in code, or do you assemble it on a visual interface (Low/No Code)? The two main paths diverge at this fork.

Coding yourself

Those who follow the code path work with an orchestration framework. Its task is to control the agent loop. It coordinates planning, tool calls, state, and resuming after an interruption.

Which framework is right depends on the project's focus.

LangGraph gilt 2026 as the most widespread choice for productive, multi-step agents because it models the process as a graph with state persistence and rollback, thus remaining reliable even if a step aborts mid-execution.

Is it more about quickly setting up a role-based prototype with multiple agents, is CrewAI the more direct way.

the agent predominantly searches in large knowledge bases, plays LlamaIndex its strength because retrieval is at the center there.

And anyone working in a Python team with strict types can rely on Pydantic AI resort to.

In addition, the major model providers offer their own SDKs. For example, the OpenAI Agents SDK, the Claude Agent SDK from Anthropic or Google ADK. These are especially worthwhile if you are already at home in one of these ecosystems.

Code solutions offer maximum flexibility, but currently also require a high level of technical skill.

No-/Low-Code

With no-code or low-code solutions, AI agents can be implemented on web interfaces with less complex programming work. Which toolkit is suitable often depends on the task itself.

If the agent is just one step in a larger process automation — for example, it's supposed to read an email, extract data from it, update a database, and finally send a notification — then n8n as the obvious choice for a Workflow Automation Platform.

N8n has built-in loops and error handling, and the agent integrates seamlessly into the rest of the workflow.

Flowise and Langflow are against open workshops specifically for LLM pipelines.

Langflow directly integrates the aforementioned LangGraph and is therefore also suitable for stateful loops.

Dify goes one step further and bundles builder, knowledge base, API layer, and logging into a single product.

For those who have to connect many different services, it is best to Make or Zapier Well served, because the connector cover is widest there.

Meanwhile, the major providers have also entered this area, such as OpenAI with the OpenAI Agent Builder.

Two layers on top

Two more layers lie perpendicular to this decision: they are added regardless of whether one has chosen code or no-code.

The first is the connection between the agent and the tool. For an agent to be able to use a tool at all, it needs a standardized connection, and that's exactly what the Model Context Protocol (MCP) provides.

Anthropic presented it in 2024 and handed it over to the Linux Foundation at the end of 2025; meanwhile, all major vendors support it, and leading frameworks have made it the standard for tool calls.

MCP handles the connection from the agent to the tool, while the related A2A protocol (Google, 2025) handles agent-to-agent connections in multi-agent systems. In practice, this primarily means one thing: Before writing your own integration, check if an existing MCP server is available for the desired tool.

The second layer, which is relevant in both cases, is observability. This means observing what the agent is actually doing. It is necessary because agents fail silently: a hallucinated answer is returned without an error message, and classic monitoring of latency and error rates notices nothing of it.

Specialized tools bridge this gap by recording every single step: every LLM call, every tool call, every planning decision.

Which of these fits depends on the environment again: LangSmith is tightly integrated with LangChain and LangGraph, Langfuse is the open-source and framework-independent variant, and Arize Phoenix offers the greatest depth in evaluation.

This layer is not an afterthought, but rather the practical answer to two problems that arise later in the post: failure modes, such as when token consumption is not measured during the testing phase, and the EU AI Act's logging requirement, which mandates that every tool call and every planning step must be traceable.

How an AI agent works

The architecture is fundamentally different from a chatbot that accepts a prompt and returns a response.

An agent runs in a loop where the LLM is not the executor, but the controller: It generates structured instructions that other components interpret — database queries, API calls, code execution. From this separation follows: Agents must be calculated differently than chat applications. The LLM is called multiple times per task, often dozens of times.

The Agent Loop

A typical agent goes through five stages, each with a characteristic failure mode:

1. Perception — Inputs and context are read. Error mode: incomplete or noisy context that distorts later decisions.
2. Planning — The LLM breaks down the goal into sub-steps. Failure mode: hallucinated steps or infinite loops without a termination criterion.
3. Execution — Tools are being called (API, database, code). Error mode: faulty tool signatures or unhandled API errors.
4. Reflection — The result will be checked against the target. Failure mode: Overwriting, where the agent discards working intermediate results.
5. Memory — Intermediate results are saved. Error mode: Context Red — the context becomes too long, causing relevant information to be lost.

The ReAct Pattern

The current de facto standard for aligning thinking and acting is ReAct (Reasoning + Acting). Shunyu Yao and co-authors presented the pattern in 2022 at Princeton and Google Research.

The agent thinks one step, calls a tool, observes the result, and thinks again. It continues this process until a final state is reached.

In the ALFWorld and WebShop benchmarks, ReAct outperformed previous imitation and reinforcement learning methods by an absolute 34 and 10 percentage points success rate, respectively, with only one to two in-context examples.

ReAct is worthwhile if the environment is unsafe or noisy. For tasks without tools, ReAct only adds overhead. In this case, a pure Chain-of-Thought prompt is lighter.

For deterministic workflows, where each step is known in advance, a plan-and-execute approach is more favorable. It plans once and then executes, instead of reasoning anew between each action.

Agent Types and When to Use Each

The academic taxonomy according to Russell & Norvig distinguishes four basic types, sorted by increasing generality. It is suitable as a selection matrix:

• Simple Reflex Agents react exclusively to the current input. Especially suitable when the task is stateless and the next step can be directly derived from the input.
• Model-based Reflex Agents maintain an internal state of the environment. These are necessary as soon as previous observations influence the next decision.
• Goal-based Agents Evaluate actions based on whether they bring you closer to a defined goal. These are the standard for most current LLM-based agents in business processes.
• Utility-based Agents Weighing multiple goals with different importance. Especially relevant for trade-offs, such as cost versus speed versus accuracy.

Each of these types can be extended as a learning agent that learns from results and adapts its behavior.

Next to that lies the question of single-agent or multi-agent systems (MAS).

A single agent is sufficient as long as the task can be solved as a coherent sequence. Only when it breaks down into clearly separable subtasks with their own specialized domains—such as research, analysis, reporting—does an orchestrator agent become useful, coordinating specialized worker agents. MAS costs many times more in tokens (see below).

As a heuristic, it is considered: Only split when subtasks require different domains, toolsets, or contexts—not because a single agent occasionally makes mistakes.

AI Agent or Chatbot, RPA, Workflow? What to use when

The choice of the right tool depends on the task structure, not on the available tool stack.

• RPA / Classic Workflow The path is deterministic and known in advance. Each step can be defined as a rule or a click path. Example: Transferring invoice data from PDF to SAP.
• Chatbot: One question leads to one answer. No multi-step execution, no external actions. Example: Answer FAQs about the product portal.
• AI Agent: The task requires multiple steps, the order of which depends on the intermediate result. Example: Identify ten competitors, analyze their pricing pages, create a comparison report. This is done weekly, with changing competitors.
• Assistant / Copilot: Reactive support, without autonomous multi-step execution. Humans remain in the loop and approve after each step. Gartner explicitly ranks assistants below agents.

When an AI agent is worthwhile

The deployment threshold can be determined by three criteria:

1. The task has high path diversity (deterministic tasks belong in RPA).,
2. it's recurring (one-off tasks don't justify development costs),
3. And it has a clearly verifiable outcome (otherwise it's impossible to measure if the agent is working).

The cost scales, which are missing from many glossaries, are the second part of the "worth it" decision. Agentic systems consume 5 to 30 times more tokens per task than a single chat interaction:

• Simple Tool-Calling Agents: 5,000–15,000 Tokens per task.
• Complex Multi-Agent Systems: 200,000 to over 1,000,000 tokens per task.
• Unlimited Software Engineering Agent: According to a study by the Stevens Institute of Technology, approximately $5–8 per solved issue. This value applies to an agent without budget or step limitations; it is lower with set limits.
• Inference costs at the company level: Laut ICONIQ Capital (State of AI, Januar 2026, Befragung von rund 300 Software-Executives) entfallen bei Scaling-Stage-AI-Unternehmen rund 23 Prozent des Umsatzes auf Inferenz — pro 1 Mio. USD Produktumsatz also etwa 230.000 USD reine Modellkosten.

Eine architektonische Stellschraube für Multi-Agent-Systeme ist die hierarchische Verteilung der Modellklassen: Frontier-Modelle nur für den Orchestrator, Budget-Modelle für die Worker.

In einer Benchmark zur Verarbeitung von Finanzdokumenten (SEC-Filings) wurden so rund 97,7 Prozent der Vollkosten-Genauigkeit bei rund 60,9 Prozent der Kosten erreicht. Ob sich diese Werte auf andere Domänen übertragen lassen, ist nicht belegt. Der Hebel selbst (kleine Modelle für Routine-Subaufgaben) gilt allgemeiner.

Beispielhafte Einsatzfelder

• Predictive Maintenance: Ein Agent liest Sensordaten, korreliert mit Wartungshistorien, schlägt einen Eingriffszeitpunkt vor. Lippert nutzt nach Angabe von Databricks agent-gestützte Analytik, um Wartungsbedarf in Fertigung und Logistik zu antizipieren.
• Wettbewerbsmonitoring: Ein Agent recherchiert wöchentlich definierte Wettbewerber, analysiert Preisseiten, erstellt einen Vergleichsreport. Klassischer Fall hoher Pfadvielfalt — jede Woche andere Auffälligkeiten.
• Dokumenten-Review: Ein Orchestrator-Agent verteilt die Prüfung eines Vertrags oder Berichts auf spezialisierte Worker. Ein Worker extrahiert relevante Klauseln, einer prüft gegen interne Vorgaben, einer fasst zusammen. Hier zerfällt die Aufgabe in spezialisierte Subaufgaben. Ein typischer Kandidat für ein Multi-Agent-System.

Wann KI-Agenten in der Realität scheitern

Gartner prognostiziert, dass bis Ende 2027 über 40 Prozent der agentischen KI-Projekte abgebrochen werde. Vornehmlich wegen eskalierender Kosten, unklarem Geschäftswert oder unzureichender Risikokontrollen.

Die wiederkehrenden Scheiternsmuster lassen sich vorab erkennen:

• Context Rot: Der Agent zieht in langen Loops immer mehr Kontext mit; relevante Informationen verschwinden im Rauschen. Vorab-Indikator: Steigende Latenz und sinkende Trefferqualität bei zunehmender Loop-Länge in der Testphase.
• Quadratisches Token-Wachstum: Jeder neue Loop-Schritt verarbeitet den gesamten bisherigen Kontext. Dadurch wachsen Kosten und Latenz nicht linear. Vorab-Indikator: Token-Verbrauch pro Aufgabe in Test-Runs nicht mitgemessen.
• Fehlendes Checkpointing: Bricht ein Schritt ab, muss man von vorn beginnen. Vorab-Indikator: Architekturdiagramm zeigt keinen Persistenzlayer für Zwischenstände.
• Governance-Lücken: Agenten dürfen Aktionen ausführen, ohne dass Berechtigungen, Audit-Logs und Eskalationspfade definiert sind. Vorab-Indikator: Niemand kann benennen, was der Agent darf und was nicht — und wer haftet, wenn er es trotzdem tut.

Was der EU AI Act für KI-Agenten verlangt

Der EU AI Act trat am 1. August 2024 in Kraft und wird stufenweise anwendbar. Die letzte große Stufe, ursprünglich für den 2. August 2026 vorgesehen, betrifft die volle Durchsetzbarkeit der Anforderungen für Hochrisiko-KI-Systeme nach Anhang III. Eine politische Einigung im Mai 2026 (Digital-Omnibus-Paket) sieht eine Verschiebung um rund 16 Monate für Annex-III-Systeme vor; der formale Beschluss stand zum Redaktionsstand noch aus. Bußgelder bei Verstößen erreichen bis zu 35 Mio. € oder 7 Prozent des weltweiten Jahresumsatzes.

Hochrisiko nach Anhang III umfasst unter anderem KI-Systeme im Personalwesen (Bewerberauswahl, Beurteilungen), in der Kreditwürdigkeitsprüfung und in kritischer Infrastruktur. Ein KI-Agent, der etwa eingehende Bewerbungen vorsortiert oder Kreditanträge vorprüft, fällt damit in die Hochrisiko-Kategorie — unabhängig davon, ob die Entscheidung am Ende ein Mensch trifft.

Für solche Systeme gelten konkrete Pflichten, die in der Agentenarchitektur vorgesehen sein müssen:

• Risikomanagementsystem: Dokumentierte Identifikation, Bewertung und Minderung von Risiken über den gesamten Lebenszyklus.
• Daten-Governance: Anforderungen an Trainings- und Eingabedaten (Relevanz, Repräsentativität, Fehlerfreiheit, Vollständigkeit).
• Technische Dokumentation: Vollständige Beschreibung von Design, Funktionsweise, Leistungskennzahlen, Einschränkungen und Verwendungszweck — vor Inverkehrbringen.
• Protokollierung: Automatische Aufzeichnung von Eingaben, Ausgaben und Entscheidungen. Für Agenten heißt das: Jeder Tool-Call, jeder Planungsschritt, jede Reflexion muss auditierbar sein.

Wer einen Agenten plant, der in eine Hochrisiko-Kategorie fallen kann, muss Logging, Konformitätsbewertung und Dokumentation von Anfang an als Architekturanforderung behandeln — nicht als nachträglichen Compliance-Layer.

FAQ