Agentic AI: Zehn Konzepte, die KI-Agenten 2027 zuverlässig machenAgentic AI: ten concepts that make AI agents reliable in 2027

Die meisten KI-Agenten scheitern nicht am Modell. Sie scheitern an dem, was um das Modell herum fehlt. Eine Schleife ohne Abbruch läuft die ganze Nacht, ein Werkzeug mit Schreibrechten ändert Daten, die es nur lesen sollte. Ich betreibe seit Monaten ein eigenes Agenten-Setup für Webseiten, Server und Texte. Fast jeder Fehler, den ich dort gesehen habe, war ein Systemfehler. Die Antwort des Modells war in der Regel plausibel.

Dieser Beitrag ordnet die zehn Konzepte, die aus einem Sprachmodell einen verlässlichen Agenten machen. Zu jedem Konzept gibt es eine Erklärung, eine Grafik, eine Prüffrage für dein eigenes Vorhaben und ein Beispiel aus meinem Setup. Die Reihenfolge folgt dem Weg einer Aufgabe durch das System. Am Ende steht ein 90-Tage-Plan, mit dem ein mittelständisches Unternehmen den ersten Agenten sauber an den Start bringt. Die Inhalte gibt es zusätzlich als Präsentation mit 31 Folien.

Was Agentic AI von einem Chatbot unterscheidet

Agentic AI bezeichnet KI-Systeme, die ein Ziel in mehreren Schritten selbst verfolgen. Ein Chatbot bekommt eine Frage und gibt eine Antwort. Ein Agent bekommt eine Aufgabe, plant Schritte, ruft Werkzeuge auf, liest das Ergebnis und entscheidet, was als Nächstes passiert. Er arbeitet in einer Schleife, bis die Aufgabe erledigt ist oder eine Grenze greift.

Anthropic beschreibt in seinem Leitfaden Building effective agents den Unterschied so: Workflows folgen vorgegebenen Pfaden, Agenten steuern ihren Weg selbst. Der Leitfaden empfiehlt, mit dem einfachsten System anzufangen, das die Aufgabe löst, und Komplexität erst dann hinzuzufügen, wenn sie messbar hilft.

Die folgende Grafik zeigt den Aufbau als System. In der Mitte arbeitet das Modell in seiner Schleife. Die zehn Konzepte liegen als Ringe darum. Wähle einen Ring, um zu sehen, wofür er zuständig ist.

Warum Systemdenken bei KI-Agenten jetzt zählt

Gartner erwartet, dass bis Ende 2027 mehr als 40 Prozent aller Agentic-AI-Projekte abgebrochen werden. Als Gründe nennt das Analysehaus steigende Kosten, unklaren Nutzen und unzureichende Risikokontrollen. Alle drei Gründe liegen im System, keiner im Modell. In derselben Prognose schätzt Gartner, dass von tausenden Anbietern nur etwa 130 echte agentische Fähigkeiten liefern. Der Rest benennt vorhandene Chatbots und Automatisierungen um.

Gleichzeitig wächst, was Agenten leisten können. Das Forschungsinstitut METR misst, wie lange Aufgaben dauern dürfen, die ein Modell mit 50 Prozent Erfolgsquote erledigt. Diese Spanne hat sich seit 2019 etwa alle sieben Monate verdoppelt. Längere Aufgaben bedeuten mehr Schritte, mehr Werkzeugaufrufe und mehr Gelegenheiten für Fehler. Je länger ein Agent arbeitet, desto mehr entscheidet das System über das Ergebnis.

In Deutschland ist KI im Alltag der Unternehmen angekommen. Laut Bitkom setzen 57 Prozent der Unternehmen ab 20 Beschäftigten KI ein, befragt wurden 603 Unternehmen im Sommer 2026. Neun von zehn sehen sich dabei noch am Anfang. Der nächste Schritt vom Assistenten zum Agenten ist für viele genau jetzt die Frage.

1. Harness Engineering: das Gerüst um das Modell

Harness Engineering ist die Arbeit an allem, was zwischen der Entscheidung des Modells und ihrer Ausführung liegt. Das Modell sagt „lies diese Datei“ oder „sende diese Mail“. Das Harness entscheidet, ob, wie oft und unter welchen Bedingungen das passiert. Anthropic hat im November 2025 beschrieben, wie ein gutes Harness lange Aufgaben über viele Kontextfenster trägt: Ein erster Agent richtet die Umgebung ein, jeder weitere Lauf hinterlässt eine Fortschrittsdatei und saubere Commits für den nächsten.

Vier Bausteine gehören in jedes Harness:

• Wiederholung und Ersatzweg: Ein Werkzeug schlägt fehl, das Harness versucht es nach einer Pause erneut. Bleibt der Fehler, greift ein Ersatzweg oder der Lauf endet mit einer klaren Meldung.
• Abgeschottete Ausführung: Code und Befehle laufen in einer Sandbox, mit Zugriff nur auf die Verzeichnisse und Netzadressen, die der Auftrag braucht.
• Raten- und Kostenlimits: Ein Budget je Lauf, je Tag und je Werkzeug. Ohne Budget kann ein Agent in einer Nacht ausgeben, was das Team im Monat einplant.
• Geordneter Rückfall: Fällt ein Dienst aus, liefert der Agent ein Teilergebnis mit Hinweis. Ein stilles Weiterlaufen ohne Hinweis ist der schlechteste Fall.

Aus meinem Setup: Mein Review-Agent lief eine Zeit lang gegen ein Modell, das es nicht mehr gab. Jede Anfrage endete mit HTTP 404, alle Reviews scheiterten still. Ein leeres Ergebnis sah aus wie ein sauberes. Seitdem gilt im Harness die Regel, dass eine leere Antwort nie als Befund zählt. Sie ist ein Fehler, bis das Gegenteil belegt ist.

Prüffrage: Was passiert, wenn das wichtigste Werkzeug deines Agenten eine Stunde lang nicht erreichbar ist?

2. Loop Engineering: wann der Agent aufhört

Loop Engineering gestaltet die Schleife aus Handeln, Prüfen und erneutem Handeln. Jede Runde kostet Zeit und Rechenleistung. Eine Schleife ohne Abbruchbedingung ist der häufigste Grund für Agenten, die stundenlang laufen und am Ende nichts liefern.

Eine gute Schleife hat drei Ausgänge. Das Ziel ist erreicht und durch einen Test belegt. Das Budget an Runden, Zeit oder Kosten ist verbraucht. Oder die letzten Runden haben keinen Fortschritt gebracht. Dazu kommt ein klares Rückmeldesignal je Runde: ein Testergebnis, eine Fehlermeldung, eine Zahl. Ohne Signal rät der Agent, ob er näher am Ziel ist.

Aus meinem Setup: Jeder Bauschritt hat bei mir eine harte Grenze von drei Runden, je Schritt und je Ziel. Nach der dritten erfolglosen Runde stoppt der Agent und meldet in drei Zeilen Stand, Befund und beste Option. Vorher formuliert er das Erfolgskriterium als Prüfbefehl. Ohne diesen Befehl startet keine Schleife. Die Grenze hat mehr Zeit gespart als jede Prompt-Verbesserung.

Prüffrage: Kannst du in einem Satz sagen, woran dein Agent erkennt, dass er fertig ist?

3. Context Engineering: was das Modell bei jedem Schritt sieht

Context Engineering entscheidet, welche Informationen bei jedem Schritt im Kontextfenster stehen. Anthropic nennt den Kontext eine endliche Ressource mit abnehmendem Grenznutzen und rät zur kleinsten Menge an Informationen mit hoher Aussagekraft. Das klingt selbstverständlich, wird aber bei Agenten schnell verletzt. Jeder Werkzeugaufruf hängt Ergebnisse an, jede Runde verlängert den Verlauf.

Wie stark das wirkt, hat das Datenbank-Unternehmen Chroma im Juli 2025 gemessen. In der Studie Context Rot wurden 18 Sprachmodelle mit wachsender Eingabelänge getestet. Bei allen sank die Leistung, auch bei einfachen Aufgaben. Ein längerer Kontext ist also nicht automatisch ein besserer Kontext.

Drei Techniken helfen. Verdichten: Alte Runden werden zu einer Zusammenfassung, die nur Entscheidungen und offene Punkte behält. Nachladen statt vorladen: Der Agent bekommt Dateipfade und Suchwerkzeuge und holt Inhalte erst, wenn er sie braucht. Gewichten: Aktuelle Informationen haben Vorrang, außer eine ältere Regel ist ausdrücklich dauerhaft gültig.

Aus meinem Setup: Meine Agenten lesen Dateien über ein Werkzeug, das unveränderte Inhalte beim zweiten Lesen auf wenige Zeichen kürzt. Große Ausgaben, etwa Browser-Protokolle über 50 KB, laufen in einer eigenen Sitzung. Die Hauptsitzung bekommt nur das Ergebnis.

Prüffrage: Welcher Teil deines Kontexts ist nach zehn Runden noch nötig, und wer räumt den Rest weg?

4. Tool Design: Werkzeuge, die ein Agent richtig benutzt

Tool Design ist die Gestaltung der Werkzeuge, die ein Agent aufrufen darf. Für ein Modell ist ein Werkzeug nur ein Name, eine Beschreibung und ein Schema. Ist eines davon unklar, ruft der Agent das falsche Werkzeug auf oder füllt die Parameter falsch.

Anthropic empfiehlt im Beitrag Writing effective tools for agents vier Dinge. Jedes Werkzeug hat einen klaren, eigenen Zweck. Namen tragen ein Präfix, das den Bereich zeigt, etwa crm_kontakt_suchen statt suchen. Antworten sind knapp und enthalten nur, was der Agent für den nächsten Schritt braucht. Fehlermeldungen sagen, was zu tun ist, statt nur einen Code zu nennen. Im selben Leitfaden steht ein Beispiel aus der Praxis: Erst als ein Werkzeug absolute Dateipfade verlangte, machte das Modell keine Pfadfehler mehr.

Bei der Anzahl gilt: Zwanzig ähnliche Werkzeuge verwirren ein Modell stärker als fünf gut getrennte. Das Model Context Protocol, kurz MCP, hat Werkzeuge austauschbar gemacht. Anthropic hat das Protokoll im Dezember 2025 an die Agentic AI Foundation unter dem Dach der Linux Foundation übergeben. Die Auswahl der richtigen Werkzeuge bleibt trotzdem Handarbeit.

Prüffrage: Würde ein neuer Kollege anhand von Name und Beschreibung allein verstehen, was das Werkzeug tut?

5. Memory Architecture: was ein Agent behält

Memory Architecture regelt, was ein Agent über eine Sitzung hinaus behält und wie er es wiederfindet. Das Kontextfenster ist das Arbeitsgedächtnis. Es endet mit der Sitzung. Alles, was länger halten soll, braucht einen eigenen Speicher.

Drei Ebenen haben sich bewährt. Das Arbeitsgedächtnis hält die laufende Aufgabe. Strukturierte Notizen halten Fortschritt und offene Punkte über mehrere Läufe, etwa als Fortschrittsdatei. Das Langzeitgedächtnis hält Regeln, Entscheidungen und Fakten, die auch in Wochen noch gelten. Die schwierigste Frage ist dabei, was nicht gespeichert wird. Ein Gedächtnis voller Zwischenstände wird zum Kontextproblem der nächsten Sitzung.

Aus meinem Setup: Jede Erinnerung ist bei mir eine eigene Datei mit genau einer Tatsache, einem Grund und einer Anwendungsregel. Ein Index mit einer Zeile je Eintrag wird bei jeder Sitzung geladen, die Dateien selbst erst bei Bedarf. Erinnerungen, die sich als falsch herausstellen, werden gelöscht statt ergänzt. Eine Regel, die ich nur mit ausdrücklicher Freigabe ändern darf, trägt eine eigene Markierung.

Prüffrage: Wer entscheidet in deinem System, dass eine gespeicherte Information veraltet ist?

6. Orchestration Patterns: ein Agent oder mehrere

Orchestrierung beschreibt, wie mehrere Agenten oder Arbeitsschritte zusammenarbeiten. Anthropic unterscheidet fünf Muster: Ketten, die Schritte nacheinander abarbeiten, Weichen, die Anfragen an Spezialisten verteilen, parallele Läufe, ein Orchestrator mit Arbeitern und ein Paar aus Erzeuger und Prüfer.

Mehrere Agenten können viel leisten. Anthropic berichtet, dass ein Recherche-System aus einem leitenden Agenten und mehreren Unteragenten einen einzelnen Agenten in einer internen Bewertung um 90,2 Prozent übertraf. Derselbe Bericht nennt den Preis: Agenten verbrauchen etwa viermal so viele Tokens wie ein Chat, Systeme aus mehreren Agenten etwa fünfzehnmal so viele. Mehr Agenten lohnen sich also nur, wenn die Aufgabe wirklich in unabhängige Teile zerfällt.

Aus meinem Setup: Bei mir schreibt genau ein Agent, ein zweiter prüft nur lesend. Für jeden Bereich gibt es eine Sperrdatei mit Bereich, Agent, Zeit und Grund. Diese Regel entstand nach einem Vorfall: Zwei Sitzungen arbeiteten im selben Verzeichnis und spielten innerhalb von 70 Sekunden zwei verschiedene Stände auf meine eigene Webseite. Seitdem gilt ein Schreiber je Bereich, ohne Ausnahme.

Prüffrage: Welche Teilaufgabe deines Agenten könnte wirklich parallel laufen, ohne auf ein anderes Ergebnis zu warten?

7. Guardrails und Berechtigungen: der Schadensradius

Guardrails begrenzen, was ein Agent tun darf und was er sehen darf. Die OWASP-Liste der zehn größten Risiken für Sprachmodell-Anwendungen führt dafür seit 2025 den Punkt Excessive Agency: zu viele Funktionen, zu viele Rechte, zu viel Autonomie. Die Empfehlung ist eindeutig. Rechte werden im Zielsystem durchgesetzt, nicht im Prompt. Ein Satz wie „lösche niemals Dateien“ ist eine Bitte, keine Sperre.

Hilfreich ist der Gedanke des Schadensradius. Für jede Aktion fragst du, was im schlimmsten Fall passiert und ob es sich rückgängig machen lässt. Lesen hat einen kleinen Radius. Schreiben in einem Entwurf auch. Schreiben in einem Live-System, Geld bewegen oder eine Mail an Kunden senden haben einen großen Radius und brauchen eine Freigabe oder eine technische Sperre. Eingaben von außen, etwa Webseiten oder Mails, behandelt der Agent als Daten, nie als Anweisung.

Aus meinem Setup: Ein Hook sperrt jedes Deploy-Skript und jeden Neustart eines Dienstes, solange in der Sitzung keine Freigabeprüfung gelaufen ist. Der prüfende Agent hat keine Schreibrechte. Ein Synchronisationsbefehl mit Löschoption ist auf Live-Verzeichnissen per Regel verboten, seit ein Agent damit einen Live-Stand zurückgedreht hat.

Prüffrage: Welche Aktion deines Agenten lässt sich nicht rückgängig machen, und wer gibt sie frei?

8. Evals für Agenten: testen, bevor du vertraust

Evals sind wiederholbare Tests, die zeigen, ob ein Agent eine Aufgabe zuverlässig löst. Anthropic unterscheidet zwei Blickwinkel: den Verlauf eines Laufs mit allen Werkzeugaufrufen und das Ergebnis, also den Zustand am Ende. Die Empfehlung lautet, eher das Ergebnis zu bewerten als den Weg. Ein Agent darf einen anderen Pfad nehmen als erwartet, wenn das Ergebnis stimmt.

Für den Start braucht es keine hunderte Aufgaben. Anthropic nennt 20 bis 50 einfache Aufgaben, die aus echten Fehlern stammen, als guten Anfang. Wird ein Sprachmodell als Bewerter eingesetzt, muss es eng an menschlichen Fachleuten kalibriert sein, mit einer eigenen Bewertungsregel je Dimension.

Zwei Kennzahlen zeigen, warum Zuverlässigkeit bei Agenten anders zu messen ist. pass@k ist die Wahrscheinlichkeit, dass mindestens einer von k Versuchen gelingt. pass^k ist die Wahrscheinlichkeit, dass alle k Versuche gelingen. Für einen Agenten, der jeden Tag dieselbe Aufgabe erledigt, zählt die zweite Zahl. Die Grafik rechnet das für einen Agenten durch, der einen einzelnen Versuch zu 80 Prozent besteht.

Aus meinem Setup: Zwei meiner Prüfberichte meldeten einmal „0 gegen 0: bestanden“. Die Prüfung hatte keine Daten bekommen und deshalb nichts gefunden. Seitdem nennt jede Prüfung zuerst ihre Grundmenge. Ist sie leer, lautet das Ergebnis „nicht prüfbar“. Und jede Prüfung muss einmal absichtlich rot werden, bevor ich ihr glaube.

Prüffrage: Welche zehn Aufgaben aus den letzten Fehlern deines Teams würdest du als erste Testsammlung nehmen?

9. Human in the Loop: wo der Mensch entscheidet

Human in the Loop heißt, dass ein Mensch an festgelegten Stellen prüft, freigibt oder übernimmt. Das ist kein Misstrauensvotum gegen den Agenten, es verteilt Verantwortung nach Risiko. Die Gefahr liegt woanders: Muss der Mensch jede Kleinigkeit abnicken, wird er zum Engpass und gibt irgendwann ungeprüft frei.

Eine einfache Regel hilft: Je größer der mögliche Schaden und je schwerer er umzukehren ist, desto früher kommt der Mensch ins Spiel. Bei kleinen, umkehrbaren Aktionen reicht eine Stichprobe. Bei großen, endgültigen Aktionen entscheidet der Mensch, der Agent bereitet vor. Für die Übergabe braucht der Mensch eine Zusammenfassung mit Entscheidungsvorlage, keinen Verlauf mit 200 Zeilen.

Rechtlich bekommt das Thema ein Datum. Der EU AI Act verlangt in Artikel 14 für Hochrisiko-Systeme eine wirksame menschliche Aufsicht, inklusive der Möglichkeit, das System anzuhalten. Mit dem AI Omnibus, in Kraft seit 27.07.2026, gelten die Pflichten für eigenständige Hochrisiko-Systeme ab 02.12.2027. Ein Agent in der Bewerberauswahl oder bei der Kreditprüfung fällt darunter, ein Agent für Blogtexte nicht.

Prüffrage: Bei welchen Entscheidungen deines Agenten musst du heute schon einen Menschen benennen können, der sie verantwortet?

10. Observability und Tracing: sehen, was der Agent tut

Observability bedeutet, dass jeder Schritt eines Agenten nachvollziehbar aufgezeichnet wird. Ein Trace zeigt die Kette aus Modellaufrufen, Werkzeugaufrufen und Ergebnissen mit Dauer, Tokens und Kosten. Wer keinen Trace hat, rät bei jedem Fehler. Mit Trace suchst du eine Zeile und findest sie.

Das Projekt OpenTelemetry arbeitet an einheitlichen Begriffen für solche Aufzeichnungen, etwa invoke_agent für den Agentenlauf und execute_tool für einen Werkzeugaufruf. Die Konventionen sind noch im Status „Development“, also nicht endgültig. Für den Start reichen vier Kennzahlen: Erfolgsquote, Dauer je Aufgabe, Kosten je Aufgabe und Anteil der Läufe, die ein Mensch korrigieren musste. Dazu kommen Warnungen, wenn eine Zahl aus ihrem üblichen Band läuft.

Aus meinem Setup: Eine Deploy-Prüfung meldete einmal grün, weil die Seite mit HTTP 200 antwortete. Ausgeliefert wurde aber eine Fehlerseite, nur eben mit Status 200. Seitdem prüft jede Abnahme einen Inhaltsmarker je Route: einen Satz, der nur auf der richtigen Seite steht. Der Status allein beweist nichts.

Prüffrage: Findest du in fünf Minuten heraus, welcher Werkzeugaufruf gestern einen falschen Wert geliefert hat?

Wie die zehn Konzepte zusammenspielen

Keines der Konzepte wirkt allein. Eine Schleife ohne Evals weiß nicht, wann sie fertig ist. Guardrails ohne Tracing lassen sich nicht prüfen. Ein Gedächtnis ohne Context Engineering füllt das Kontextfenster mit Altlasten. Die folgende Karte zeigt den Weg einer Anfrage durch das System. Wähle ein Element, um seine Verbindungen zu sehen.

Ein 90-Tage-Plan für den ersten Agenten im Mittelstand

Für ein mittelständisches Unternehmen ist der beste erste Agent einer mit kleinem Schadensradius und messbarem Nutzen. Gute Kandidaten sind das Vorsortieren eingehender Anfragen, das Vorbereiten von Angeboten aus vorhandenen Vorlagen oder das Prüfen von Rechnungen gegen Bestellungen. Der Plan unten ordnet die zehn Konzepte in die Reihenfolge, in der sie gebraucht werden.

Der wichtigste Punkt steht am Anfang: Bevor ein Agent gebaut wird, steht die Testsammlung. Wer zuerst baut und dann testet, misst am Ende nur, was der Agent ohnehin kann. Wenn du diesen Weg begleitet gehen willst, findest du die Schritte auch in meinem Ansatz zur KI-Beratung vom Geschäftsziel zum Pilot. Wie eine Agenten-Schleife im Detail läuft, beschreibt der Beitrag Die Agent-Schleife.

Häufige Fragen

Quellen und Stand

Stand: 16.10.2026, alle Quellen an diesem Tag abgerufen.

• Anthropic: Building effective agents, 19.12.2024.
• Anthropic: Effective harnesses for long-running agents, 26.11.2025.
• Anthropic: Effective context engineering for AI agents, 29.09.2025.
• Anthropic: Writing effective tools for agents, 11.09.2025.
• Anthropic: How we built our multi-agent research system, 13.06.2025 (90,2 Prozent, Faktor 4 und 15 bei den Tokens).
• Anthropic: Demystifying evals for AI agents, 09.01.2026 (pass@k, pass^k, 20 bis 50 Aufgaben).
• Anthropic: Übergabe des Model Context Protocol an die Agentic AI Foundation, 09.12.2025.
• Chroma: Context Rot: How Increasing Input Tokens Impacts LLM Performance, 14.07.2025.
• METR: Measuring AI Ability to Complete Long Tasks, März 2025.
• Gartner: Pressemitteilung zu Agentic-AI-Projekten, 25.06.2025.
• Bitkom: Erstmals nutzt die Mehrheit der Unternehmen KI, 14.09.2026.
• OWASP: LLM06:2025 Excessive Agency.
• OpenTelemetry: Semantic Conventions für GenAI-Agenten, Status Development.
• Europäische Kommission: AI Omnibus enters into force, 27.07.2026, sowie Verordnung (EU) 2026/1744.

Die Grafiken, die Beispiele aus meinem Setup und der 90-Tage-Plan sind eigene Darstellungen. Die Rechnung zu pass@k und pass^k ist ein Rechenbeispiel, keine Messung.

Most AI agents do not fail because of the model. They fail because of what is missing around it. A loop without a stop condition runs all night, a tool with write access changes data it was only supposed to read. I have been running my own agent setup for websites, servers and texts for months. Almost every failure I saw there was a system failure. The model's answer was usually plausible.

This article sorts the ten concepts that turn a language model into a reliable agent. Each concept comes with an explanation, a graphic, a check question for your own project and an example from my setup. The order follows the path of a task through the system. At the end there is a 90-day plan that gets a mid-sized company's first agent off the ground properly. The content is also available as a presentation with 31 slides (in German).

What separates agentic AI from a chatbot

Agentic AI describes AI systems that pursue a goal over several steps on their own. A chatbot gets a question and gives an answer. An agent gets a task, plans steps, calls tools, reads the result and decides what happens next. It works in a loop until the task is done or a limit applies.

In its guide Building effective agents, Anthropic draws the line like this: workflows follow predefined paths, agents direct their own path. The guide recommends starting with the simplest system that solves the task and adding complexity only when it measurably helps.

The following graphic shows the structure as a system. At the centre, the model works in its loop. The ten concepts sit around it as rings. Select a ring to see what it is responsible for.

Why systems thinking matters for AI agents now

Gartner expects more than 40 percent of all agentic AI projects to be canceled by the end of 2027. The reasons it names are rising costs, unclear business value and inadequate risk controls. All three sit in the system, none in the model. In the same prediction, Gartner estimates that only about 130 of thousands of vendors deliver real agentic capabilities. The rest rebrand existing chatbots and automation.

At the same time, what agents can do keeps growing. The research institute METR measures how long tasks can be that a model completes with a 50 percent success rate. That span has doubled roughly every seven months since 2019. Longer tasks mean more steps, more tool calls and more chances for errors. The longer an agent works, the more the system decides the outcome.

In Germany, AI has arrived in everyday business. According to Bitkom, 57 percent of companies with 20 or more employees use AI; 603 companies were surveyed in summer 2026. Nine out of ten still see themselves at the beginning. For many, the next step from assistant to agent is the question right now.

1. Harness engineering: the scaffold around the model

Harness engineering is the work on everything between the model's decision and its execution. The model says "read this file" or "send this email". The harness decides whether, how often and under which conditions that happens. In November 2025 Anthropic described how a good harness carries long tasks across many context windows: a first agent sets up the environment, every following run leaves a progress file and clean commits for the next one.

Four building blocks belong in every harness:

• Retry and fallback path: a tool fails, the harness tries again after a pause. If the error persists, a fallback path takes over or the run ends with a clear message.
• Sandboxed execution: code and commands run in a sandbox, with access only to the directories and network addresses the task needs.
• Rate and cost limits: a budget per run, per day and per tool. Without a budget, an agent can spend in one night what the team plans for a month.
• Graceful degradation: if a service fails, the agent delivers a partial result with a note. Silently carrying on without a note is the worst case.

From my setup: For a while, my review agent ran against a model that no longer existed. Every request ended with HTTP 404, all reviews failed silently. An empty result looked like a clean one. Since then the harness has a rule that an empty answer never counts as a finding. It is an error until proven otherwise.

Check question: What happens if your agent's most important tool is unreachable for an hour?

2. Loop engineering: when the agent stops

Loop engineering designs the cycle of acting, checking and acting again. Every round costs time and compute. A loop without a stop condition is the most common reason for agents that run for hours and deliver nothing.

A good loop has three exits. The goal is reached and proven by a test. The budget of rounds, time or cost is used up. Or the last rounds brought no progress. On top of that comes a clear feedback signal per round: a test result, an error message, a number. Without a signal, the agent guesses whether it is getting closer to the goal.

From my setup: Every build step has a hard limit of three rounds, per step and per goal. After the third unsuccessful round the agent stops and reports status, finding and best option in three lines. Before that, it phrases the success criterion as a check command. Without that command, no loop starts. The limit has saved more time than any prompt improvement.

Check question: Can you say in one sentence how your agent knows it is done?

3. Context engineering: what the model sees at each step

Context engineering decides which information sits in the context window at each step. Anthropic calls context a finite resource with diminishing marginal returns and advises the smallest possible set of high-signal information. That sounds obvious, but agents break it quickly. Every tool call appends results, every round lengthens the history.

The database company Chroma measured how strong the effect is in July 2025. Its study Context Rot tested 18 language models with growing input length. Performance dropped for all of them, even on simple tasks. A longer context is not automatically a better context.

Three techniques help. Compaction: old rounds become a summary that keeps only decisions and open items. Load on demand instead of up front: the agent gets file paths and search tools and fetches content only when it needs it. Weighting: recent information takes priority, unless an older rule is explicitly meant to last.

From my setup: My agents read files through a tool that shortens unchanged content to a few characters on the second read. Large outputs, such as browser logs above 50 KB, run in a separate session. The main session only gets the result.

Check question: Which part of your context is still needed after ten rounds, and who clears away the rest?

4. Tool design: tools an agent uses correctly

Tool design is the design of the tools an agent is allowed to call. To a model, a tool is just a name, a description and a schema. If one of them is unclear, the agent calls the wrong tool or fills in the parameters wrongly.

In Writing effective tools for agents, Anthropic recommends four things. Every tool has a clear, distinct purpose. Names carry a prefix that shows the area, for example crm_contact_search instead of search. Responses are short and contain only what the agent needs for the next step. Error messages say what to do instead of just naming a code. The same guide has a practical example: only when a tool required absolute file paths did the model stop making path errors.

On the number of tools: twenty similar tools confuse a model more than five well separated ones. The Model Context Protocol, MCP for short, has made tools interchangeable. Anthropic handed the protocol over to the Agentic AI Foundation under the Linux Foundation in December 2025. Choosing the right tools is still manual work.

Check question: Would a new colleague understand what the tool does from its name and description alone?

5. Memory architecture: what an agent keeps

Memory architecture defines what an agent keeps beyond a session and how it finds it again. The context window is working memory. It ends with the session. Anything that should last longer needs its own store.

Three layers have proven useful. Working memory holds the current task. Structured notes hold progress and open items across several runs, for example as a progress file. Long-term memory holds rules, decisions and facts that still apply in weeks. The hardest question is what does not get stored. A memory full of intermediate states becomes the context problem of the next session.

From my setup: Each memory is its own file with exactly one fact, one reason and one usage rule. An index with one line per entry is loaded in every session, the files themselves only when needed. Memories that turn out to be wrong get deleted instead of amended. A rule I may only change with explicit approval carries its own marker.

Check question: Who decides in your system that a stored piece of information is outdated?

6. Orchestration patterns: one agent or several

Orchestration describes how several agents or work steps cooperate. Anthropic distinguishes five patterns: chains that work through steps one after another, routing that hands requests to specialists, parallel runs, an orchestrator with workers, and a pair of generator and evaluator.

Several agents can achieve a lot. Anthropic reports that a research system with a lead agent and several subagents outperformed a single agent by 90.2 percent in an internal evaluation. The same report names the price: agents use about four times as many tokens as a chat, multi-agent systems about fifteen times as many. More agents only pay off when the task truly splits into independent parts.

From my setup: Exactly one agent writes, a second one only reviews, read-only. For every area there is a lock file with area, agent, time and reason. The rule came from an incident: two sessions worked in the same directory and pushed two different versions to my own website within 70 seconds. Since then there is one writer per area, no exceptions.

Check question: Which subtask of your agent could truly run in parallel without waiting for another result?

7. Guardrails and permissions: the blast radius

Guardrails limit what an agent may do and what it may see. Since 2025, the OWASP list of the top ten risks for LLM applications has an entry for this, Excessive Agency: too much functionality, too many permissions, too much autonomy. The recommendation is clear. Permissions are enforced in the target system, not in the prompt. A sentence like "never delete files" is a request, not a lock.

The idea of a blast radius helps. For every action you ask what happens in the worst case and whether it can be undone. Reading has a small radius. So does writing a draft. Writing to a live system, moving money or emailing customers has a large radius and needs approval or a technical lock. Input from outside, such as web pages or emails, is treated by the agent as data, never as an instruction.

From my setup: A hook blocks every deploy script and every service restart as long as no release check has run in the session. The reviewing agent has no write access. A sync command with a delete option is banned on live directories by rule, ever since an agent used one to roll back a live version.

Check question: Which action of your agent cannot be undone, and who approves it?

8. Evals for agents: test before you trust

Evals are repeatable tests that show whether an agent solves a task reliably. Anthropic distinguishes two angles: the transcript of a run with all tool calls, and the outcome, meaning the state at the end. The recommendation is to grade the outcome rather than the path. An agent may take a different route than expected if the result is right.

You do not need hundreds of tasks to start. Anthropic names 20 to 50 simple tasks drawn from real failures as a good start. If a language model is used as a grader, it must be closely calibrated against human experts, with a separate rubric per dimension.

Two metrics show why reliability has to be measured differently for agents. pass@k is the probability that at least one of k attempts succeeds. pass^k is the probability that all k attempts succeed. For an agent that does the same task every day, the second number counts. The graphic works this out for an agent that passes a single attempt 80 percent of the time.

From my setup: Two of my check reports once said "0 vs 0: passed". The check had received no data and therefore found nothing. Since then every check names its population first. If it is empty, the result is "not checkable". And every check has to turn red on purpose once before I trust it.

Check question: Which ten tasks from your team's recent failures would you take as your first test set?

9. Human in the loop: where a human decides

Human in the loop means a human checks, approves or takes over at defined points. This is not a vote of no confidence in the agent, it distributes responsibility by risk. The danger lies elsewhere: if the human has to sign off every detail, they become a bottleneck and at some point approve without checking.

A simple rule helps: the larger the possible damage and the harder it is to reverse, the earlier the human comes in. For small, reversible actions a spot check is enough. For large, final actions the human decides and the agent prepares. For the handoff, the human needs a summary with a decision proposal, not a 200-line transcript.

Legally, the topic now has a date. Article 14 of the EU AI Act requires effective human oversight for high-risk systems, including the ability to stop the system. With the AI Omnibus, in force since 27 July 2026, these obligations apply to stand-alone high-risk systems from 2 December 2027. An agent in candidate screening or credit checks falls under this, an agent for blog texts does not.

Check question: For which of your agent's decisions do you already need to name a human who is accountable?

10. Observability and tracing: seeing what the agent does

Observability means every step of an agent is recorded in a traceable way. A trace shows the chain of model calls, tool calls and results with duration, tokens and cost. Without a trace you guess at every error. With a trace you look for a line and find it.

The OpenTelemetry project is working on common terms for these records, such as invoke_agent for the agent run and execute_tool for a tool call. The conventions are still in "development" status, so not final. Four metrics are enough to start: success rate, duration per task, cost per task and the share of runs a human had to correct. Add alerts when a number leaves its usual band.

From my setup: A deploy check once reported green because the page answered with HTTP 200. What was served, however, was an error page, just with status 200. Since then every acceptance check verifies a content marker per route: a sentence that only appears on the right page. The status alone proves nothing.

Check question: Could you find out within five minutes which tool call returned a wrong value yesterday?

How the ten concepts work together

None of the concepts works alone. A loop without evals does not know when it is done. Guardrails without tracing cannot be verified. Memory without context engineering fills the context window with leftovers. The following map shows the path of a request through the system. Select an element to see its connections.

A 90-day plan for the first agent in a mid-sized company

For a mid-sized company, the best first agent has a small blast radius and measurable value. Good candidates are pre-sorting incoming enquiries, preparing quotes from existing templates or checking invoices against purchase orders. The plan below puts the ten concepts in the order in which they are needed.

The most important point comes first: the test set exists before the agent is built. If you build first and test afterwards, you only measure what the agent can do anyway. If you want support along the way, you will find the steps in my approach to AI consulting from business goal to pilot. How an agent loop works in detail is described in The agent loop.

Frequently asked questions

Sources and status

Status: 16 October 2026, all sources retrieved on that day.

• Anthropic: Building effective agents, 19 December 2024.
• Anthropic: Effective harnesses for long-running agents, 26 November 2025.
• Anthropic: Effective context engineering for AI agents, 29 September 2025.
• Anthropic: Writing effective tools for agents, 11 September 2025.
• Anthropic: How we built our multi-agent research system, 13 June 2025 (90.2 percent, factor 4 and 15 for tokens).
• Anthropic: Demystifying evals for AI agents, 9 January 2026 (pass@k, pass^k, 20 to 50 tasks).
• Anthropic: Donating the Model Context Protocol and establishing the Agentic AI Foundation, 9 December 2025.
• Chroma: Context Rot: How Increasing Input Tokens Impacts LLM Performance, 14 July 2025.
• METR: Measuring AI Ability to Complete Long Tasks, March 2025.
• Gartner: Press release on agentic AI projects, 25 June 2025.
• Bitkom: Erstmals nutzt die Mehrheit der Unternehmen KI (German), 14 September 2026.
• OWASP: LLM06:2025 Excessive Agency.
• OpenTelemetry: Semantic conventions for GenAI agent spans, status development.
• European Commission: AI Omnibus enters into force, 27 July 2026, and Regulation (EU) 2026/1744.

The graphics, the examples from my setup and the 90-day plan are my own work. The pass@k and pass^k calculation is a worked example, not a measurement.