OrchestrierungVeröffentlicht: 9. Juli 2026Marek Adamczyk

Agentic Engineering: die Disziplin hinter zuverlässigen KI-Agenten in der Produktion

Was Agentic Engineering ist, wie es sich von Prompt Engineering und Orchestrierung unterscheidet, und wie die sieben Säulen von opsagent sich zu einem Prozess fügen, der Agenten vom Prototyp bis zur zuverlässigen Produktion trägt.

Definition

Agentic Engineering ist die technische Disziplin, KI-Agenten zuverlässig für die Produktion zu entwerfen, zu bauen, zu evaluieren und zu betreiben — sie umfasst Prompt-, Kontext-, Harness-, Inference-, Gedächtnis-, Evaluations- und Code-Engineering als einen zusammenhängenden Prozess, nicht einen einzelnen Prompt oder die Wahl eines Orchestrierungs-Frameworks.

Agentic Engineering hat sich als Begriff erst 2025 und 2026 in der Branche durchgesetzt, doch das Problem, das er beschreibt, ist deutlich älter: wie man von einer Demo, die einmal in einem Konferenzraum funktioniert, zu einem Agenten kommt, der zuverlässig tausendmal am Tag in der Produktion läuft, ohne dass ein Mensch jeden Fehler unterwegs korrigiert. Das ist keine Frage nach einem besseren Prompt oder dem richtigen Orchestrierungs-Framework — es ist eine Frage nach einem gesamten technischen Prozess: von der ersten Anweisung über das, was der Agent bei jedem Schritt sieht und sich merkt, bis hin dazu, wie Sie messen, dass er wirklich funktioniert, bevor Sie ihm Zugriff auf etwas Wichtiges geben.

Dieser Artikel ist eine Landkarte dieses Prozesses und der Einstiegspunkt in den Rest von opsagent. Die Seite teilt das Thema KI-Agenten in sieben Säulen — Sicherheit, MCP und Identität, Governance, Observability, Evals, Orchestrierung, Aufsicht — und jede geht tief in ihren eigenen Ausschnitt des Puzzles. Agentic Engineering ist der Rahmen, der zeigt, wie diese Ausschnitte zu einem einzigen Prozess zusammenpassen, statt zu sieben getrennten Projekten.

Was Agentic Engineering ist — und was nicht

Der Branchenkonsens von 2026 definiert Agentic Engineering als die technische Disziplin, KI-Agenten zuverlässig für die Produktion zu entwerfen, zu bauen, zu evaluieren und zu betreiben — nicht einen einzelnen Prompt, sondern den gesamten Lebenszyklus eines Systems, das auf ein Ziel hinarbeitet, statt nur auf eine einzelne Anweisung zu antworten. Es umfasst sieben ineinandergreifende Arbeitsschichten, gelegentlich mit dem Kürzel ETCLOVG bezeichnet: Prompt Engineering, Context Engineering, Harness Engineering, Inference, Gedächtnis, Evaluation und Code Engineering.

Diese Unterscheidung ist wichtig, weil diese drei Begriffe in der Praxis ständig vermischt werden:

Begriff	Umfang	Typische Frage, die er beantwortet
Prompt Engineering	Die Formulierung einer einzelnen Anweisung an das Modell	Wie formuliere ich diese Anweisung, damit das Modell in dieser Runde gut antwortet?
Context Engineering	Die gesamte Nutzlast, die das Modell bei jedem Schritt sieht — Anweisungen, abgerufenes Wissen, Tool-Ergebnisse, Gedächtnis	Was genau soll bei diesem Schritt ins Kontextfenster, und was bleibt draußen?
Orchestrierung	Tools und Frameworks, die den Kontrollfluss über Schritte oder Agenten koordinieren	Wer tut was, in welcher Reihenfolge, mit welcher Zustandsübergabe?
Agentic Engineering	Der gesamte Prozess: alles Obige plus Harness, Gedächtnis und Evaluation als eine Disziplin	Wie entwerfe, baue und betreibe ich einen Agenten, dem ich in der Produktion vertrauen kann?

Prompt Engineering und Context Engineering sind Fähigkeiten innerhalb von Agentic Engineering. Orchestrierung ist ein Werkzeugsatz, zu dem Sie greifen, sobald eine Aufgabe tatsächlich die Koordination mehrerer Komponenten erfordert — kein Ziel für sich. Teams, die 2026 in der Produktion erfolgreich sind, investieren konsequent mehr Aufmerksamkeit in Prompt- und Context Engineering als in die Komplexität der Orchestrierung, denn dort liegt der Großteil des tatsächlichen Hebels auf die Ausgabequalität eines Agenten — nicht in der Anzahl der Knoten in einem Koordinationsgraphen.

Agentic Engineering leiht sich Werkzeuge aus mehreren benachbarten Disziplinen, ohne mit einer davon identisch zu sein. Aus der klassischen Softwareentwicklung übernimmt es die Disziplin der Versionierung, des Testens und der Code-Reviews. Von MLOps übernimmt es die Gewohnheit, Qualität über die Zeit zu überwachen und Drift als etwas zu behandeln, das man aktiv sucht, statt darauf zu warten, dass es sich von selbst meldet. Keine der beiden ist es jedoch, denn keine der Disziplinen beantwortet unmittelbar, wie man Tool-Rechtegrenzen, Gedächtnisarchitektur oder den Kontrollpunkt entwirft, an dem ein Mensch eine Entscheidung freigeben muss, bevor sie unumkehrbar wird. Diese Fragen sind spezifisch für Systeme, die autonom auf ein Ziel hinarbeiten, und genau sie machen Agentic Engineering zu einer eigenständigen Disziplin, statt zu einer Teilmenge von etwas bereits Bestehendem.

Sieben Schichten, ein Prozess

Die ETCLOVG-Schichten sind keine Schritte, die einmal abgearbeitet und abgehakt werden — sie bilden eine Schleife, zu der Sie bei jeder Änderung der Aufgabe, des Modells oder der Autonomiestufe zurückkehren. Das Diagramm unten zeigt vereinfacht, in welcher Reihenfolge diese Schichten in der Praxis meist reifen, vom ersten Prototyp bis zur Produktion.

Agentic Engineering ist keine lineare Kette — es ist eine Schleife, zu der Sie bei jeder Änderung der Aufgabe, des Modells oder der Autonomiestufe zurückkehren. Das Diagramm zeigt die Reihenfolge, in der diese Entscheidungen typischerweise reifen.

Prompt — die Aufgabenanweisung: Ziel, Einschränkungen, Ausgabeformat. Ein Ausgangspunkt, nicht das Ende der Arbeit.
Kontext — was genau bei einem Schritt ins Fenster des Modells gelangt: abgerufenes Wissen, Tool-Ergebnisse, Verlauf. Ausführlich behandelt in Context Engineering.
Harness — die Ausführungsumgebung um das Modell herum: welche Tools der Agent aufrufen darf, unter welchen Rechten, wie sich die Ausführungsschleife verhält und was passiert, wenn ein Tool-Aufruf fehlschlägt.
Inference — das Modell selbst und die Art, wie es aufgerufen wird: die Wahl des passenden Modells für die Aufgabe, Temperatur, Wiederholungsstrategie, Kosten pro Aufruf.
Gedächtnis — was der Agent innerhalb einer Sitzung und über Sitzungen hinweg behält, wie es gespeichert wird und wer darauf schreiben darf. Vertieft in Speicherarchitektur eines Agenten.
Evaluation — woher Sie wissen, dass der Agent tut, was er soll, bevor Sie ihm vertrauen. Eine eigene Säule — Evals —, weiter vertieft in Agenten auf Zuverlässigkeit evaluieren.
Code — die Logik rund um den Agenten, die nicht der Prompt ist: Antworten parsen, validieren, Integrationen, Fehlerbehandlung. Gewöhnliche Softwareentwicklung, angewandt auf ein System, das sich nicht immer zweimal gleich verhält.

Harness Engineering — die Schicht mit der geringsten Aufmerksamkeit

Wenn Prompt und Context Engineering die meiste Aufmerksamkeit bekommen, bekommt der Harness die wenigste — dabei entscheidet gerade er, ob ein Agent überhaupt produktionsreif ist. Der Harness ist die gesamte Ausführungsumgebung um das Modell: Tool-Rechte, die Art, wie Tools aufgerufen werden, Fehler- und Wiederholungsbehandlung, die Stellen, an denen das System festhält, was geschehen ist, und die Mechanismen, mit denen Sie den Agenten stoppen können, bevor er etwas Unumkehrbares tut.

In der Praxis verbindet der Harness Themen, die opsagent als eigene Säulen behandelt: Eine MCP-Autorisierungs-Gateway entscheidet, was ein Agent aufrufen darf und unter welchen Bedingungen; Observability macht aus der Ausführung eines Agenten keine Blackbox mehr, sondern etwas, das sich Schritt für Schritt nachvollziehen lässt; und ein dokumentiertes Managementsystem, wie das bei der Einführung von ISO 42001 beschriebene, liefert den Rahmen, in dem diese Entscheidungen benannt und überprüft werden, statt einmal getroffen und vergessen zu werden. Ein guter Harness ist keine Komponente, die man kauft — er ist die Summe dieser Entscheidungen, konsequent angewendet bei jedem neuen Tool, das Sie dem Agenten geben.

Orchestrierung ist ein Werkzeug, kein Ziel

Das Orchestrator-Worker-Muster — ein Agent zerlegt ein Ziel in Teilaufgaben, delegiert sie und fasst die Ergebnisse zusammen — ist oft die richtige Lösung, aber nur, wenn sich die Aufgabe tatsächlich in spezialisierte, lose gekoppelte Rollen zerlegen lässt. Frameworks wie LangGraph, CrewAI und AutoGen setzen unterschiedliche Modelle dieser Koordination um; ein vollständiger, herstellerneutraler Vergleich steht in Agenten-Orchestrierung: LangGraph vs. CrewAI vs. AutoGen.

Was auf Ebene der Disziplin zählt, nicht nur auf Ebene des Werkzeugs: Orchestrierung löst das Koordinationsproblem, nicht das Qualitätsproblem eines einzelnen Agenten. Bevor Sie zur Frage kommen, wie mehrere Agenten zu koordinieren sind, müssen Sie geklärt haben, was bei einem einzigen passiert — was er im Kontext sieht, wie er Tools sicher ausführt, was er sich merkt. Ein Multi-Agenten-System, das auf einem wackligen Einzelagenten-Fundament aufbaut, behebt diese Schwächen nicht, sondern vervielfacht sie, denn jede Übergabe zwischen Agenten ist eine weitere Stelle, an der ein Fehler oder eingeschleuster Inhalt sich verstärken kann, statt eingedämmt zu werden.

Evaluation: bevor Sie einem Agenten in der Produktion vertrauen

Eine Demo durchläuft den Erfolgspfad einmal, während jemand bereitsteht, um einen Fehler zu korrigieren. Produktion verlangt etwas anderes: Wiederholbarkeit, ohne dass ein Mensch jeden Schritt beobachtet. Den Unterschied zwischen diesen beiden Zuständen misst die Evaluation — kein einmaliger Test vor dem Start, sondern ein fortlaufender Prozess, der prüft, ob ein Agent noch tut, was er soll, wenn sich Modell, Prompt, Daten oder Last ändern.

Die Säule Evals baut das von Grund auf auf: wie man ein Testset baut, das Regressionen tatsächlich erkennt, wie man LLM als Richter dort einsetzt, wo menschliche Bewertung nicht skaliert, und warum Regressionstests für Agenten nicht nur prüfen müssen, dass eine neue Korrektur funktioniert, sondern dass sie nicht drei andere Dinge kaputt gemacht hat. Evaluation ist das, was Agentic Engineering erlaubt, aus „es scheint zu funktionieren“ ein „ich weiß, dass es funktioniert, weil ich es gemessen habe“ zu machen — und ohne sie baut jede andere Schicht, Harness, Gedächtnis, Orchestrierung, auf Vermutungen.

Sicherheit und Aufsicht von Anfang an eingebaut, nicht nachträglich angeklebt

Der deutlichste Unterschied zwischen Agentic Engineering und dem Bauen nach dem Prinzip „schnell und dann sehen wir weiter“ ist der Zeitpunkt, an dem die Frage nach Sicherheit und Aufsicht in den Prozess eintritt. Unter Agentic Engineering geschieht das ganz am Anfang, beim Entwurf von Tool-Rechten und Autonomiegrenzen — nicht nach einem Vorfall.

Excessive Agency — übermäßige Handlungsbefugnis — ist eines der teuersten und am häufigsten übersehenen Risiken bei Agenten, gerade weil es unsichtbar bleibt, bis ein Agent etwas tut, wozu er technisch Zugriff hatte, was er aber nie hätte nutzen sollen. Die OWASP Top 10 für agentenbasierte Anwendungen katalogisiert das vollständige Spektrum dieser Risiken samt Gegenmaßnahmen, und die Säule Sicherheit entwickelt daraus praktische Entwurfsmuster. Auf der Aufsichtsseite zeigt menschliche Aufsicht und Autonomie von Agenten, wie man einen Kontrollpunkt entwirft, der eine echte Barriere ist und keine Formalität, die ein überlasteter Prüfer ungelesen abnickt.

Die praktische Regel: Gehen Sie davon aus, dass der Agent irgendwann etwas Falsches tun wird — durch einen Fehler, Drift oder einen Angriff — und entwerfen Sie so, dass dieses Falsche überlebbar ist. Diese Annahme von Anfang an einzubauen ist günstiger als eine Untersuchung nach dem Vorfall.

Warum so viele Projekte zwischen Pilotphase und Produktion steckenbleiben

Die Kluft zwischen dem Experimentieren mit Agenten und dem tatsächlichen Skalieren gehört zu den am besten belegten Mustern der Agentic AI im Jahr 2026 — und sie zeigt deutlich, warum technische Disziplin und nicht Begeisterung für ein neues Werkzeug den Unterschied macht.

Adoption von Agentic AI in Unternehmen — Momentaufnahme 2026 (richtungsweisend)

Unternehmen, die mit KI-Agenten experimentieren62%
Unternehmen mit mindestens einem Agenten in Produktion31% · Vorreiter: Banken/Versicherungen ~47%
Unternehmen, die einen Agenten tatsächlich skalieren23% · in mindestens einer Geschäftsfunktion
Unternehmen mit messbarem Produktivitätsgewinn66% · unter denen, die Agenten bereits nutzen
Führungskräfte, die KI-Budgets wegen Agenten erhöhen wollen88%

Diese Zahlen stammen aus unabhängigen Branchenumfragen und Adoptionsberichten zu Agentic AI aus dem Jahr 2026; Methodik und Stichproben unterscheiden sich, weshalb dies als richtungsweisendes Bild des Ausmaßes zu lesen ist, nicht als Ergebnis einer einzigen einheitlichen Studie. · opsagent — Synthese von Branchenberichten zur Adoption von Agentic AI, 2026

Dieselben Berichte beziffern die mittlere Zeit vom Projektstart bis zum messbaren Geschäftswert auf etwa fünf Monate — und schätzen, dass mehr als 40 % der Agentic-AI-Projekte bis Ende 2027 eingestellt werden, wegen steigender Kosten, unklarem Geschäftswert oder unzureichender Risikokontrolle. Das ist keine Prognose, dass Agenten als Idee scheitern. Es ist eine Prognose, dass Projekte scheitern, die einen Agenten wie eine Funktion behandeln, die man ausliefert, statt wie ein System, das man entwirft — ohne Evaluation, ohne Harness, ohne Plan dafür, was passiert, wenn etwas schiefgeht. Die Teams, denen es gelingt, kommen überproportional aus technischen Funktionen — Softwareentwicklung, IT, Serviceoperationen — also genau dort, wo technische Disziplin schon vor den Agenten Teil der Kultur war.

So sieht es in der Praxis aus — fünf Gewohnheiten

Agentic Engineering braucht kein großes Team und kein teures Werkzeug, um zu beginnen. Es braucht fünf Gewohnheiten, konsequent angewendet, unabhängig von der Größe:

Kontext bewusst entwerfen, nicht maximal füllen. Behandeln Sie jeden Schritt als eigenes Zusammenstell-Problem: was der Agent jetzt wirklich sehen muss, nicht alles, was er je gesehen hat.
Tool-Rechte als Entwurfsentscheidung behandeln, nicht als Standardeinstellung. Beginnen Sie beim Minimum und erweitern Sie nur, wenn das Fehlen einer konkreten Fähigkeit einen konkreten Ausfall verursacht.
Evaluation haben, bevor Sie sie brauchen. Schon ein kleines, von Hand geprüftes Set von einem Dutzend Fällen ist mehr wert als das Gefühl, dass etwas „zu funktionieren scheint“.
Von Anfang an eine Ausführungsspur erfassen. Die Spur eines Agenten — was er getan hat, welche Tools er genutzt hat, was es gekostet hat — ist zugleich Rohstoff für Debugging, Kostenrechnung und Audit.
Autonomie stufenweise erweitern, nicht auf einen Schlag. Jede neue Zugriffsstufe sollte sich der Agent verdienen, etwa entlang der Stufen im gestuften Deployment, statt sie mit der ersten Freigabe automatisch zu erhalten.

Diese fünf Gewohnheiten sind keine Zusatzarbeit neben dem „eigentlichen“ Bau eines Agenten — sie sind der Bau des Agenten, wenn das Ziel ein System ist, das den Kontakt mit der Produktion übersteht.

Ein Rahmen, keine weitere Speiche

Agentic Engineering ersetzt keine der sieben Säulen von opsagent — es verbindet sie. Orchestrierung liefert die Werkzeuge zur Koordination, MCP und Identität regelt, wie ein Agent sich mit der Außenwelt verbindet, Governance liefert den rechtlichen und organisatorischen Rahmen, Observability zeigt, was der Agent tatsächlich getan hat, Evals misst, ob er es gut getan hat, und Aufsicht entscheidet, wie viel Autonomie sich der Agent tatsächlich verdient hat. Agentic Engineering ist die Disziplin, die all diese Fragen gleichzeitig stellt, bei jeder Entscheidung, statt sie als getrennte Projekte nacheinander abzuhaken. Begriffe aus diesem Artikel und den übrigen Säulen finden sich im Glossar.

Häufige Fragen

Wie unterscheidet sich Agentic Engineering von Prompt Engineering?

Im Umfang und im zeitlichen Horizont, nicht nur im Namen. Prompt Engineering ist die Arbeit an einer einzelnen Anweisung — wie Sie eine Bitte formulieren, damit das Modell in dieser einen Runde gut antwortet. Agentic Engineering umfasst den gesamten Lebenszyklus eines Systems, das über viele Schritte hinweg auf ein Ziel hinarbeitet: was der Agent bei jedem Schritt sieht (Context Engineering), über welche Tools und Rechte er verfügt (der Harness), was er sich über Schritte und Sitzungen hinweg merkt (Gedächtnis), woher Sie wissen, dass seine Antworten tatsächlich korrekt sind (Evaluation), und wie all das ohne einen Menschen läuft, der jeden einzelnen Schritt kontrolliert. Ein guter Prompt ist ein Teil dieses Puzzles, rettet aber keinen Agenten, der sich bei einem Tool-Fehler in Schleifen verfängt, vergiftetes Gedächtnis anhäuft oder die Kontrolle über die eigenen Kosten verliert. Teams, die Agentic Engineering als 'besseres Prompt Engineering' behandeln, entdecken die Lücke meist erst in der Produktion, wenn sich die Demo nicht mehr wiederholt. Prompt Engineering ist eine Fähigkeit innerhalb von Agentic Engineering, kein Ersatz dafür.

Ist Agentic Engineering nur Agenten-Orchestrierung unter neuem Namen?

Nein — Orchestrierung ist ein Werkzeug im Werkzeugkasten, Agentic Engineering ist der Werkzeugkasten selbst samt der Entscheidung, wann welches Werkzeug greift. Ein Orchestrierungs-Framework wie LangGraph oder CrewAI koordiniert den Kontrollfluss über Schritte oder Agenten hinweg: Wer tut was, in welcher Reihenfolge, mit welcher Zustandsübergabe. Das ist ein reales, nützliches Problem, aber ein engeres. Bevor Sie überhaupt zur Frage kommen, wie mehrere Agenten zu koordinieren sind, müssen Sie klären, was ein einzelner Agent im Kontext sieht, wie er Tools sicher ausführt und was er sich merkt — und all das gilt bereits bei einem einzigen Agenten. Teams, die in der Produktion erfolgreich sind, investieren tendenziell mehr in Prompt- und Context Engineering als in die Komplexität der Orchestrierung selbst, denn dort liegt der Großteil des tatsächlichen Hebels auf die Antwortqualität des Agenten. Orchestrierung ist die Architektur der Zusammenarbeit zwischen Komponenten; Agentic Engineering ist die Disziplin, die entscheidet, wann diese Zusammenarbeit überhaupt nötig ist.

Wie viele der sieben Schichten brauche ich, damit es als Agentic Engineering zählt?

Es gibt keine formale Schwelle, aber der praktische Test ist, ob Sie die Frage 'warum hat der Agent genau das getan' beantworten können, ohne zu raten. Ein kleines Team, das einen einzelnen Agenten prototypt, kann mit bewusstem Prompt- und Context Engineering plus einem kleinen Evaluationsset für eine Handvoll Fälle beginnen — das zählt bereits als Agentic Engineering im Kleinen, sofern die Entscheidungen bewusst getroffen wurden und nicht zufällig entstanden sind. Schichten wie ein formaler Harness mit vollständiger Observability, verwaltetes Langzeitgedächtnis oder ein Red-Teaming-Programm kommen hinzu, sobald der Einsatz wächst: mehr Nutzer, mehr Rechte, mehr Geld im Spiel. Der Fehler liegt nicht darin, eine Schicht früh auszulassen — der Fehler liegt darin, sie ohne bewusste Entscheidung und ohne Plan auszulassen, wann sie nachgerüstet wird. Die Disziplin zeigt sich darin, Lücken als Schuld zu behandeln, die vor jeder Erweiterung der Autonomie eines Agenten beglichen werden muss, nicht als etwas, worüber man erst nachdenkt, wenn etwas schiefgeht.

Warum bleiben so viele Agentenprojekte zwischen Pilotphase und Produktion stecken?

Weil Pilotphase und Produktion völlig verschiedene Dinge messen und die meisten Teams auf die Pilotphase hin optimieren. Eine Demo muss die Menschen im Raum überzeugen, dass die Idee funktioniert, und dafür reicht es, den Erfolgspfad einmal zu durchlaufen, während jemand bereitsteht, um einen Fehler zu korrigieren. Produktion verlangt etwas anderes: Wiederholbarkeit ohne Menschen, der jeden Schritt beobachtet, Erholung von Teilausfällen, Kosten, die bei einem schlechten Durchlauf nicht explodieren, und eine Antwort darauf, was der Agent getan hat und warum, wenn irgendjemand irgendwann danach fragt. Nichts davon entsteht von selbst mit größerem Budget oder einem besseren Modell — es muss entworfen werden: Evaluation, Observability, Rechtegrenzen, Kontrollpunkte. Teams, die den Agenten als Demo bauen und diese Elemente erst danach andocken wollen, stellen meist fest, dass sie große Teile des Systems neu entwerfen müssen, statt sie nur zu erweitern. Genau diese Lücke erklärt, warum die Zahl der Unternehmen, die mit Agenten experimentieren, die Zahl derer, die ihren Einsatz tatsächlich skalieren, so deutlich übersteigt.

Ist Agentic Engineering dasselbe wie MLOps?

Es leiht sich Elemente von MLOps, löst aber ein anderes Problem. MLOps konzentriert sich auf den Lebenszyklus des Modells — Training, Versionierung, Deployment, Drift-Überwachung — und setzt meist ein System voraus, das für eine gegebene Eingabe eine vorhersehbare Ausgabe liefert. Agentic Engineering befasst sich mit einem System, das über viele Schritte hinweg plant, Tools aufruft, sich erinnert, wiederholt und auf ein Ziel hinarbeitet, wobei das Modell nur eine von mehreren beweglichen Komponenten neben Harness, Gedächtnis und Evaluationslogik ist. MLOps-Praktiken helfen weiterhin — Prompt-Versionierung entspricht der Modell-Versionierung, Drift-Überwachung hat ein Gegenstück in der Qualitätsüberwachung von Agenten —, reichen aber allein nicht aus, weil sie nichts zu Tool-Rechtegrenzen, Gedächtnisarchitektur oder der Aufsicht über autonomes Handeln aussagen. Behandeln Sie MLOps als benachbarte Disziplin, von der Sie Gewohnheiten übernehmen, nicht als vollständiges Handbuch für Agenten.

Wo sollte ein kleines Team mit Agentic Engineering anfangen?

Bei einem Agenten, einer eng umrissenen Aufgabe und einer bewussten Antwort auf vier Fragen, bevor Sie den ersten Prompt schreiben: was der Agent bei jedem Schritt genau sehen soll, welche Tools er mit welchen Rechten aufrufen darf, wie Sie prüfen, dass sein Ergebnis korrekt ist, bevor irgendjemand ihm vertraut, und was passiert, wenn etwas schiefgeht. Sie brauchen nicht sofort einen vollständigen Harness mit produktionsreifer Observability oder ein Multi-Agenten-System — das ist verfrühte Komplexität, die meist eher bremst als hilft. Beginnen Sie mit einem kleinen, von Hand geprüften Evaluationsset aus einem Dutzend realer Fälle, bevor Sie automatisierten Metriken vertrauen, und behandeln Sie jede zusätzliche Stufe an Autonomie als etwas, das sich der Agent verdienen muss, nicht als etwas, das er von vornherein bekommt. Diese Gewohnheit — bewusster, gestufter Ausbau statt einmaligem 'bauen und ausliefern' — ist die Disziplin selbst, unabhängig von der Teamgröße.

Brauche ich ein Multi-Agenten-System, um Agentic Engineering zu betreiben?

Nein, und in den meisten Fällen fahren Sie besser, ohne eines zu beginnen. Agentic Engineering beschreibt die Disziplin, einen in der Produktion zuverlässigen Agenten zu entwerfen und zu betreiben, und ein einzelner gut entworfener Agent — mit klarem Kontext, sauber begrenzten Tools, Evaluation und einem Kontrollpunkt — bewältigt ein überraschend breites Aufgabenspektrum. Ein Multi-Agenten-System bringt realen Aufwand mit sich: Koordinationsaufwand, mehr bewegliche Teile zum Debuggen und ein konkretes Sicherheitsrisiko, sobald Agenten die Ausgabe des jeweils anderen als automatisch vertrauenswürdig behandeln. Der legitime Grund für mehr Agenten ist eine Aufgabe, die sich tatsächlich in spezialisierte, lose gekoppelte Rollen mit unterschiedlichen Tools oder Rechten zerlegen lässt, nicht der Wunsch, anspruchsvoller zu wirken. Die vollständige Orientierung zu dieser Entscheidung steht in [Single-Agent oder Multi-Agent](/de/blog/single-vs-multi-agent). Die Disziplin des Agentic Engineering gilt in beiden Fällen identisch — bei einem Agenten ist sie schlicht leichter im Griff zu behalten.