Agentic Engineering 2026: Evals, Guardrails, Observability

Pexon Consulting | 11 Min. Lesezeit | 16.07.2026

TL;DR

Ein Demo-Agent ist in einer Woche gebaut, ein produktiver Agent nicht. Der Unterschied heißt Agentic Engineering: Evals, Guardrails, Observability, Multi-Agent-Orchestrierung und LLM-Ops. Genau diese Tiefe entscheidet, ob ein Agent in Produktion trägt oder halluziniert. Pexon Consulting (80 Mitarbeiter, Microsoft-Partner, Deutschland) baut und betreibt diese Schicht, statt nur ein Demo zu liefern.

Das Problem: Der Demo-Agent läuft, der Produktions-Agent halluziniert

Einen Agenten, der im Meeting beeindruckt, baut heute fast jeder. Ein Framework, ein Modell, ein paar Tools, und die Demo läuft. Der Sprung in den Produktivbetrieb ist der, an dem die meisten Projekte scheitern, weil zwischen Demo und Produktion eine ganze Disziplin liegt, die im Hype gern übersprungen wird.

Diese Disziplin ist Agentic Engineering. Sie beantwortet die Fragen, die eine Demo nie stellt: Woher weiß ich, dass der Agent besser geworden ist und nicht schlechter? Was hält ihn davon ab, eine falsche Aktion auszuführen? Wie sehe ich im Betrieb, was er tut und was er kostet? Wie orchestriere ich mehrere Agenten, ohne dass das Ganze zum unkontrollierbaren Automaten wird?

Dieser Artikel geht die vier Säulen durch, die einen Agenten produktionsreif machen: Evals, Guardrails, Observability und die Kombination aus Multi-Agent-Orchestrierung und LLM-Ops.

Evals: ohne Messung kein Fortschritt

Die kurze Antwort: Ohne Evals ist ein Agenten-Projekt Blindflug. Wenn Sie nicht messen können, ob eine Änderung den Agenten besser oder schlechter macht, optimieren Sie nach Gefühl. Evals sind aufgabenspezifische Testsätze mit definierten Erwartungen, gegen die jede Version läuft, oft ergänzt um LLM-Judges, die Antworten nach festen Kriterien bewerten.

Der Stand 2026 macht das zugänglich. MLflow 3 liefert Evaluation und Tracing als offenen Standard, und Managed-Plattformen wie Agent Bricks, seit dem Data + AI Summit im Juni 2026 allgemein verfügbar, erzeugen aufgabenspezifische Benchmarks und synthetische Bewertungsdaten automatisch. Ein simples Eval-Gerüst sieht so aus:

import mlflow

# Testfaelle mit erwartetem Verhalten definieren
testfaelle = [
    {"frage": "Storniere Bestellung 4711", "erwartet_tool": "cancel_order"},
    {"frage": "Wie ist das Wetter?",        "erwartet_tool": None},  # darf kein Tool rufen
]

with mlflow.start_run():
    treffer = 0
    for t in testfaelle:
        antwort = agent.invoke(t["frage"])
        if antwort.tool_used == t["erwartet_tool"]:
            treffer += 1
    mlflow.log_metric("tool_routing_accuracy", treffer / len(testfaelle))
# Jede Modell- oder Prompt-Version laeuft gegen dieselben Testsaetze.

Unsere Empfehlung: Evals gehören von der ersten Woche an ins Projekt, nicht als Nachgedanke. Sie sind das Sicherheitsnetz, das jede spätere Änderung absichert.

Guardrails: was der Agent nie tun darf

Ein Agent, der handeln kann, kann auch falsch handeln. Guardrails sind die Schicht, die definiert, was erlaubt ist und was nicht, auf Eingabe, Ausgabe und Werkzeugebene. Wir raten dringend davon ab, einen Agenten mit Schreib- oder Handlungsrechten ohne Guardrails produktiv zu schalten.

Konkret heißt das drei Dinge. Erstens Input-Validierung gegen Prompt Injection, denn ein manipuliertes Dokument kann sonst den Agenten übernehmen. Zweitens Output-Prüfung, damit sensible Daten nicht ungefiltert herauslaufen. Drittens Tool-Permissions, die dem Agenten nur die Aktionen erlauben, die sein Auftrag wirklich braucht. Wie ein manipuliertes Tool eine ganze Agent-Pipeline kompromittiert, zeigt unser Beitrag zu MCP Tool Poisoning. Der Kontroll-Layer dafür ist Teil unseres AI-Engineering-Stacks.

Observability: den Agenten im Betrieb sehen

Observability ist kein Nice-to-have, sondern die Voraussetzung, einen Agenten überhaupt zu betreiben. Ein Agent ist ein mehrstufiger Prozess: Er plant, ruft Tools, prüft, handelt weiter. Ohne Tracing sehen Sie nur Eingabe und Ausgabe, nicht die zehn Schritte dazwischen, in denen der Fehler steckt.

Tracing zeichnet jeden dieser Schritte auf, inklusive Modell-Aufrufe, Tool-Calls, Latenzen und Kosten. Tools wie Langfuse oder MLflow Tracing machen daraus ein durchsuchbares Bild des Betriebs. Das ist zugleich die Datenbasis, aus der die nächsten Evals entstehen: Echte Produktions-Traces zeigen, wo der Agent stolpert. Welches Observability-Tool zu welchem Setup passt, ordnen wir im Vergleich LangFuse, LangSmith und Helicone ein.

Multi-Agent-Orchestrierung und LLM-Ops

Sobald mehrere Agenten zusammenarbeiten, kommt eine Orchestrierungs-Ebene dazu: ein Supervisor, der Teilaufgaben an spezialisierte Agenten verteilt und Ergebnisse zusammenführt. Das ist mächtig, aber ohne die drei vorherigen Säulen auch gefährlich, weil sich Fehler über Agentengrenzen fortpflanzen. Deshalb gilt: erst ein Agent sauber im Griff, dann mehrere.

LLM-Ops ist der Betriebsrahmen darüber. Modell-Versionen, Prompt-Versionen und Eval-Ergebnisse gehören in eine Pipeline, in der eine Änderung erst nach bestandenem Eval live geht, wie im klassischen CI/CD. Ein Modell-Routing verteilt Anfragen nach Aufgabe auf das passende Modell, etwa claude-sonnet-4-6 für harte Fälle und ein günstigeres für den Rest. Genau diese Kombination aus Orchestrierung und Betrieb ist der Kern unserer Arbeit als Agentic-Engineering-Dienstleister. Den architektonischen Überbau dazu ordnen wir in den verwandten Themen am Ende ein.

Häufig gestellte Fragen

Was ist Agentic Engineering?

Die Disziplin, die einen KI-Agenten von der Demo in den Produktivbetrieb bringt. Sie umfasst Evals zur Qualitätsmessung, Guardrails gegen Fehlaktionen, Observability für den Betrieb, Multi-Agent-Orchestrierung und LLM-Ops als Betriebsrahmen. Ohne diese Schicht bleibt ein Agent ein beeindruckendes Demo ohne Produktionsreife.

Warum reichen ein Framework und ein Modell nicht?

Weil Framework und Modell nur den Kern bilden. Sie sagen nichts darüber, ob der Agent besser wird, was er nie tun darf, was er im Betrieb tatsächlich tut und wie Updates sicher live gehen. Genau diese Fragen beantwortet Agentic Engineering, und daran scheitern die meisten Projekte, nicht am Modell.

Was sind LLM-Guardrails?

Eine Kontrollschicht, die Eingaben, Ausgaben und Werkzeugzugriffe eines Agenten begrenzt. Sie schützt vor Prompt Injection, verhindert das Herauslaufen sensibler Daten und erlaubt dem Agenten nur die Aktionen, die sein Auftrag braucht. Ohne Guardrails sollte kein Agent mit Handlungsrechten produktiv laufen.

Wie messe ich die Qualität eines Agenten?

Mit Evals: aufgabenspezifischen Testsätzen mit erwartetem Verhalten, gegen die jede Version läuft. Ergänzt werden sie oft um LLM-Judges, die Antworten nach festen Kriterien bewerten. Werkzeuge wie MLflow 3 liefern das als offenen Standard. Entscheidend ist, dass jede Änderung gegen dieselben Fälle geprüft wird.

Braucht ein einzelner Agent schon LLM-Ops?

Ja, sobald er produktiv läuft. LLM-Ops sorgt dafür, dass Modell- und Prompt-Änderungen erst nach bestandenem Eval live gehen, dass Traces überwacht werden und dass Kosten im Blick bleiben. Bei einem einzelnen Agenten ist der Aufwand klein, aber der Nutzen groß, weil Sie Änderungen ohne Blindflug ausrollen.

Nächster Schritt

Wenn Ihr Agenten-Prototyp läuft, aber der Weg in die Produktion unklar ist, schneiden wir mit Ihnen die fehlende Engineering-Schicht: Evals, Guardrails, Observability, Betrieb.

Verwandte Themen