Wissensbasis

Die Begriffe des Agentic Engineering, jeder in wenigen Sätzen.

Zu jedem Begriff gibt es eine eigene Seite.

A

Agent Loop: Der Agent Loop ist der Zyklus, in dem jeder Coding-Agent arbeitet: Das Modell überlegt, ruft ein Tool auf, liest das Ergebnis und macht weiter, bis eine Abbruchbedingung greift. Zwischen zwei Aufrufen behält das Modell nichts. Verlässlich wird der Agent erst durch dieses Feedback und dadurch, dass Prompts, Kontext und Kontrollfluss in gewöhnlichem Code stehen.
Agent Observability: Agent Observability heißt, jeden Agentenlauf und jede Änderung eines Agenten aufzuzeichnen: Prompts, Tool Calls, Tokens, Laufzeiten, Entscheidungen und wer hinter jedem Commit steht. Agentenläufe unterscheiden sich von Ausführung zu Ausführung. Ohne diese Aufzeichnung kann ein Team Fehler weder debuggen noch auditieren noch daraus lernen.
Agent-Instruktionen (CLAUDE.md, AGENTS.md): Agent-Instruktionen sind die Dateien wie CLAUDE.md oder AGENTS.md, die ein Coding-Agent zu Beginn jeder Sitzung in einem Repository liest: Build- und Testbefehle, Konventionen und die Regeln des Teams. AGENTS.md ist ein offenes Format, das viele Coding-Agenten verstehen, und Claude Code greift darauf zurück, wenn ein Projekt keine CLAUDE.md hat. So reicht eine Datei für das ganze Team. Sie braucht einen Owner, denn getrennte Dateien pro Tool laufen mit der Zeit auseinander.
Agentic Continuous Delivery: Agentic Continuous Delivery schickt die Änderungen von Agenten durch dieselbe Pipeline wie die von Menschen, und die Latte liegt mindestens genauso hoch. Ein Mensch verantwortet die Absicht, die Pipeline prüft, ob Absicht, Tests, Code und Architektur zusammenpassen, und kein Agent schiebt seine eigene Änderung in Produktion.
Agentic Engineering: Agentic Engineering heißt: Coding-Agenten schreiben den Code, und die Regeln des Engineerings gelten weiter. Menschen legen fest, wann eine Aufgabe fertig ist, geben dem Agenten den Kontext, den er braucht, und prüfen das Ergebnis mit Tests und Gates. Es erweitert klassisches Software Engineering und löst Vibe Coding überall dort ab, wo ein Team betreiben und ändern muss, was es gebaut hat.
Automationskatalog: Ein Automationskatalog umfasst die Jobs, die in einer Software Factory ständig rund um die Coding-Agenten laufen, ohne dass jemand sie anstößt: zum Beispiel einen Pull-Request-Reviewer, einen Verifier nach dem Merge und einen Auditor, der die übrigen Automationen prüft. Jeder Job steht in einer Datei im Repository, mit Auslöser, Aufgabe und dem, was er ändern darf, und so kann jeder nachlesen, was die Factory tut.

C

Context Engineering: Context Engineering heißt zu entscheiden, was wann in welches Kontextfenster eines Agenten kommt. Jedes Token konkurriert um die Aufmerksamkeit des Modells, also bleibt die Hauptsitzung klein, und Recherche und andere umfangreiche Arbeit wandern in eigene Fenster.
Context Product: Ein Context Product macht Unternehmenswissen oder Code für Agenten wiederverwendbar: mit Owner, Metadaten und stabiler Schnittstelle. Dokumente werden dafür extrahiert, zerlegt, angereichert und indexiert, aus Gesprächen wird verwaltetes Gedächtnis, und aus dem Syntaxbaum des Quellcodes entsteht ein Wissensgraph, den Agenten abfragen können.
Cost to Serve Software (CTS-SW): Cost to Serve Software (CTS-SW) misst bei Amazon, was es insgesamt kostet, eine Einheit Software auszuliefern. Nach Amazons eigenen Angaben sank die Kennzahl 2024 durch Arbeit an der Developer Experience um 15,9 Prozent gegenüber dem Vorjahr, während die wöchentlichen Produktions-Deployments pro Builder um 18,3 Prozent stiegen.
Creator-Verifier: Creator-Verifier verteilt Agentenarbeit auf zwei Rollen: Der eine Agent baut die Änderung, ein zweiter mit eigenem Kontext beurteilt sie. Wer seine eigene Arbeit bewertet, winkt sie meist durch, das gilt auch für Agenten. Der Verifier prüft deshalb gegen Kriterien, die schon vor dem Code feststanden, und schaut darauf, was die Änderung wirklich tut.

D

Dark Factory: Eine Dark Factory ist eine Software Factory, die ohne menschliche Freigabe für jeden Schritt auskommt: Agenten schreiben, testen, deployen und warten den Code, und zwar innerhalb von Regeln und Qualitätsgrenzen, die Menschen vorher festgelegt haben.
Disciplined Compounding Loop: Der Disciplined Compounding Loop schickt jede Agentenaufgabe durch denselben Zyklus: planen, testgetrieben bauen, prüfen und zum Schluss eine kurze Retrospektive, deren Erkenntnisse ins Repository zurückfließen. So macht jede fertige Änderung den nächsten Lauf besser, und Änderungen werden mit der Zeit billiger.
Dynamisch-robuste Organisation: Eine dynamisch-robuste Organisation steuert bekannte Arbeit über Pläne und Regeln. Für Unbekanntes setzt sie auf Strategie innerhalb klarer Prinzipien, auf temporäre Teams und auf das Urteil vor Ort. Ihre Führungskräfte wechseln den Modus, sobald sich das Problem ändert, statt jede Aufgabe durch denselben Prozess zu pressen.

E

Enabling Environment: Das Enabling Environment umfasst Laufzeitumgebung, Plattform und Repository, in denen ein Agent arbeitet, und es bremst eine Software Factory stärker als das Modell. Kann ein Agent die App nicht starten, echte Dienste nicht erreichen und die Testsuite nicht vollständig laufen lassen, liefert er Code, der richtig aussieht und nie geprüft wurde.
Evals für nicht-deterministische Systeme: Evals für nicht-deterministische Systeme messen ein System, das auf dieselbe Eingabe jedes Mal anders antworten kann, ein einzelner Lauf beweist dort also nichts. Die deterministischen Teile deckt ihr mit Unit-Tests ab, alles andere lasst ihr viele Male laufen und vergleicht die Verteilung der Erfolgsquoten mit einer festgehaltenen Baseline. Bewertet wird dabei nicht nur die Antwort, sondern auch der Weg dorthin, also die Schritte und Tool Calls des Agenten.

F

Federated Context Platform: Eine Federated Context Platform liefert Agenten im Unternehmen kontrollierten Kontext, ohne alle Quellen in einen zentralen Speicher zu holen: Jede Fachdomäne verantwortet ihren Kontext selbst und veröffentlicht ihn als Produkt. Ein gemeinsames Gateway und ein Katalog machen diese Produkte auffindbar und sicher nutzbar, und für jeden Abrufbedarf gibt es den passenden Speicher.

H

Harness Engineering: Harness Engineering heißt, das System zu bauen, in dem ein Coding-Modell arbeitet: Umgebung, Regeln, deterministische Gates, Feedback-Schleifen und Validierung. Der Harness übernimmt genau das, was das Modell allein noch nicht zuverlässig kann. Erst durch ihn wird aus einer Flotte von Agenten eine Software Factory.
Hooks: Hooks sind Befehle, die der Agent-Harness an festen Stellen einer Sitzung von selbst ausführt: vor oder nach einem Tool Call, wenn ein Prompt eingeht oder wenn der Agent anhält. Eine Instruktionsdatei kann das Modell übergehen, einen Hook nicht. Er blockiert etwa einen gefährlichen Befehl, startet nach jeder Änderung den Typechecker oder protokolliert jeden Tool Call.

J

Just-in-time Retrieval: Just-in-time Retrieval heißt: Der Agent merkt sich nur Verweise wie Dateipfade und Suchanfragen und holt die eigentlichen Daten erst über Tools, wenn ein Schritt sie braucht. Für Coding-Agenten ist das der Standard, der sich bewährt: Vorberechnete Embedding-Indizes veralten und verfehlen Anfragen, die sich quer durch eine Codebasis ziehen.

K

Kontextfenster: Das Kontextfenster umfasst alles, was ein Modell in einer Sitzung sieht, gezählt in Tokens bis zu einer festen Grenze: Systemprompt, Instruktionsdateien, Tool-Definitionen, gelesene Dateien und das bisherige Gespräch. Schon lange vor der Grenze lässt die Qualität nach, und Fakten aus der Mitte eines langen Kontexts findet das Modell am schlechtesten wieder. Ein kleineres, gut geordnetes Fenster ist deshalb meist besser als ein volles.

M

MCP (Model Context Protocol): MCP (Model Context Protocol) ist ein offenes Protokoll, mit dem ein Agent über eine einheitliche Schnittstelle an Tools, Ressourcen und Prompts kommt, statt für jede Kombination einen eigenen Connector zu brauchen. Bezahlt wird vor allem mit Kontext: Die meisten Clients laden alle Tool-Schemas vorab, das füllt das Fenster, und die Tool-Auswahl wird schlechter.
Menschliche Verantwortung: Menschliche Verantwortung heißt: Was ausgeliefert wird, entscheidet eine namentlich benannte Person, nicht der Agent, und sie steht dafür ein. Agenten können untersuchen, umsetzen und testen, aber ob die Belege reichen, beurteilt diese Person. Sie geht das Risiko ein und trägt die Folgen.

P

Prompt Engineering: Prompt Engineering ist das Schreiben der Instruktionen, nach denen ein Modell oder Agent arbeitet. Agentische Prompts wirken am besten, wenn sie gebaut sind wie ein kleines Programm, mit Zweck, Eingaben, nummerierten Schritten und festgelegtem Bericht, dazu konkreten Beispielen und dem Grund für jede Regel. Es ist ein Teil von Agentic Engineering, und um alles Übrige, was das Modell sieht, kümmert sich Context Engineering.

Q

Quality Gates: Quality Gates sind die automatischen Prüfungen, durch die eine Änderung muss, bevor es weitergeht, etwa Build, Typprüfung, Linter, Tests, Security-Scan und Coverage-Schwelle. Jedes Gate prüft nach einer festen Regel und sagt bestanden oder nicht bestanden. Es startet bei einem Ereignis wie Commit oder Push und nie nach Ermessen des Agenten.

R

Research, Plan, Implement (RPI): Research, Plan, Implement (RPI) teilt eine Coding-Aufgabe in drei getrennte Schritte, jeder in einem frischen Kontextfenster: herausfinden, wie das System funktioniert, und das Ergebnis verdichten, einen konkreten Plan schreiben und dann nach diesem Plan umsetzen. Menschen prüfen früh, an den kurzen Recherche- und Abstimmungsnotizen, wo eine falsche Annahme am wenigsten kostet, und noch einmal am fertigen Code.

S

Skill: Ein Skill ist ein Ordner mit Instruktionen, Skripten und Referenzdateien, den ein Agent erst dann lädt, wenn eine Aufgabe ihn verlangt. Vorher belegen nur sein Name und seine Beschreibung Platz im Kontextfenster, so bringt ein Skill eine neue Fähigkeit fast ohne Kontextkosten.
Software Factory: Eine Software Factory ist das Delivery-System, das aus der Absicht eines Teams ausgelieferte Software macht, auf die sich das Team verlassen kann. Zu ihr gehören Spezifikationen, der Kontext für die Agenten, die Umgebungen, in denen sie laufen, die Prüfungen für jede Änderung, die Regeln dafür, wer freigeben und handeln darf, und das Feedback, das den nächsten Lauf besser macht. Menschen bauen und justieren dieses System, statt das Produkt selbst zu schreiben. Wie viel die Factory ausliefert, hängt an Spezifikationsqualität, Prüfkapazität und Inferenzkosten, nicht daran, wie schnell Agenten Code schreiben.
Spec-driven Development: Spec-driven Development macht eine geschriebene Spezifikation zur maßgeblichen Quelle für die Arbeit der Agenten: eine Markdown-Datei im Repository, die wie Code reviewt wird und Änderung, Rahmenbedingungen und Abnahmetests festlegt, bevor die erste Zeile Code entsteht. Alle weiteren Schritte arbeiten mit dieser Datei, und Korrekturen landen in der Spec, nicht als Patch im Chat. Die Abnahmetests werden aus der Spec abgeleitet, und der Agent, der die Änderung umsetzt, schreibt und ändert sie nie. Weichen Code oder Tests von der Spec ab, entscheidet der Owner der Spec, welche Seite nachzieht, und hält das fest.
Subagent: Ein Subagent ist eine eigene Agenteninstanz mit eigenem Kontextfenster, eigenen Instruktionen und eigenen Tool-Rechten, an die der Hauptagent eine Aufgabe delegiert. Das Suchen und Lesen passiert in seinem Fenster, zurück kommt nur eine kurze Zusammenfassung, und die Hauptsitzung bleibt klein. Subagenten teilen Kontext auf, sie spielen keine Rollen wie Frontend oder QA.

T

Thin Harness: Ein Thin Harness hält den Agent Loop schlank und lässt das Modell planen und sich anpassen. Nach diesem Prinzip ist Claude Code gebaut: Spezialisierte Fähigkeiten liegen in Plugins, MCP-Servern, SDKs und Language Servern, und mit jedem Modell-Release baut der Kern Scaffolding ab und nimmt die Erweiterungen auf, die sich bewährt haben.

V

Verification Literacy: Verification Literacy heißt, Code prüfen zu können, den ein Modell per Inferenz erzeugt hat und nicht ein Compiler. Dazu gehört, zu wissen, wo Modelle plausible Details erfinden, das Wichtige zu testen und die Review-Kapazität mit der Menge an generiertem Code wachsen zu lassen, damit Review nicht zur Formsache verkommt.
Versioned Context: Versioned Context gibt Skills, Regeln und Instruktionsdateien einen Software-Lebenszyklus. Das braucht ein Team, sobald es viele davon hat und nicht mehr nur einen Prompt: Sie werden erzeugt, mit Evals getestet, über Registries verteilt und wie Code überarbeitet.
Vibe Coding: Vibe Coding heißt: Man promptet ein Modell, bis etwas läuft, ohne Plan, ohne Definition von fertig und ohne automatische Prüfungen. Für Prototypen, Experimente und Wegwerf-Skripte geht das gut. Sobald ein Team die Software betreiben, ändern und verantworten muss, bricht Vibe Coding zusammen, und an dieser Stelle übernimmt Agentic Engineering.