Habitat Engineering: Die vierte Disziplin, die über Agent-Erfolg entscheidet

Du rufst den Agenten. Er startet. Er hat alles: das richtige Modell, den richtigen Prompt, das richtige Harness (das Gurtzeug des Agenten: seine Tools und Systemverbindungen). Und dann scheitert er. Irgendwie. Unklar warum. Du schreibst den Prompt um. Gibst ihm mehr Kontext. Fügst noch ein Tool hinzu. Scheitert wieder. Du denkst: schlechter Agent.

Die Diagnose stimmt oft nicht.

Aus meiner Erfahrung mit agentischen KI-Systemen: Das Problem liegt nicht immer am Agenten. Es liegt an der Welt, in der er lebt. In diesem Artikel geht es um eine Disziplin, die ich Habitat Engineering nenne. Die vierte Ebene in einer Hierarchie, die du vielleicht schon kennst: Prompt Engineering, Context Engineering, Harness Engineering. Und jetzt Habitat Engineering. Die vierte Disziplin, die entscheidet, ob all das andere wirklich funktioniert.

Was ist Habitat Engineering, und warum reichen Prompt, Context und Harness nicht?

Habitat Engineering ist die Disziplin, die sich um die Welt außerhalb des Agenten selbst kümmert. Nicht das Modell, nicht seine Instruktionen, nicht sein Werkzeugkasten, sondern die Umgebung, in der er operiert.

Eine Analogie macht das sofort greifbar. Stell dir niedliche kleine Wesen aus einem bekannten Franchise vor, die man fangen, trainieren und in Kämpfe schicken kann:

Tier 1, Prompt Engineering: Das ist der Kampfbefehl: „Donnerschock!“. Eine Instruktion. Was soll das Wesen tun? Das ist der System Prompt, der Instruktionstext.

Tier 2, Context Engineering: Was sieht das Wesen gerade? Was ist im Sichtfeld? Im Agenten ist das das Context Window: Tokens, Retrieval, Memory, Retrieval-Augmented Generation.

Tier 3, Harness Engineering: Das Gurtzeug des Wesens. Die Ausrüstungsgegenstände, die erlernten Fähigkeiten, der Fangbehälter. Im Agenten sind das Tools, MCP-Server, Skills, Hooks, Sandbox.

Und dann kommt Tier 4, das im bisherigen Diskurs keinen Namen hatte: Habitat Engineering. Das ist nicht das Gurtzeug. Das ist das Land selbst. Das hohe Gras, das erschlossen werden kann. Die Wege, die nicht ins Nirgendwo führen. Das Erholungszentrum, das wirklich zugänglich ist. Die Welt, in der dieses Wesen lebt.

Im Agenten-Kontext sind das: Markdown-Seiten, die ein Agent lesen kann. Dokumentierte APIs mit klaren Fehlercodes. Knowledge Graphs mit navigierbaren Wikilinks. AGENTS.md, CLAUDE.md, Skill-Files an wohldefinierten Orten. Outcome-orientierte Aufgabenbeschreibungen statt Implementations-Tickets. Ein /llms.txt im Website-Root. OpenAPI-Specs, die Agenten Kontrakte statt Rätsel geben. Sichere Schreibumgebungen, die Produktionsrisiken fernhalten. Klare Eskalationspfade für Entscheidungen, die ein Agent nicht selbst treffen soll. Und noch viel mehr. Nichts davon ist Infrastruktur im klassischen Sinne: kein Server, keine Datenbank, kein Netzwerk. Und genau deshalb fehlt der Begriff.

Operativer Agent-Erfolg ist eine Funktion aus Modell, Harness und Habitat. Ein perfekt ausgestatteter Agent in einem chaotischen Habitat scheitert. Eine gut gestaltete Welt ohne Harness ist tot. Beides ist nötig. Keine Konkurrenz, orthogonale Schichten.

Was KI-Agenten grundsätzlich leisten können und welche Fragen du dir beim Einsatz stellen solltest, habe ich in „Von Prompts zu Agenten“ beschrieben. Heute gehe ich einen Schritt tiefer: In welcher Welt muss dieser Agent eigentlich leben, damit er das leisten kann?

Was ist der Unterschied zwischen Harness Engineering und Habitat Engineering?

Im Februar 2026 hat Mitchell Hashimoto, Gründer von HashiCorp und Schöpfer von Terraform, in einem Blogpost eine Disziplin beschrieben, die er Harness Engineering nennt. Quelle: Augment Code, April 2026. Ein paar Tage später folgte ein Field Report von OpenAI, und der Begriff breitete sich aus. Das ist richtig und wichtig. Ich glaube aber: Die Hierarchie endet nicht bei drei. Sie endet bei vier.

Harness Engineering ist agent-zentrisch. Es fragt: Womit arbeitet der Agent? Habitat Engineering ist welt-zentrisch. Es fragt: In welcher Welt operiert er?

Der Begriff ist bewusst gewählt. „Infrastructure“ ist tech-stack-vorbelegt: Server, Datenbanken, Netzwerk, Cloud. Aber eine CLAUDE.md-Datei ist keine Infrastruktur. Eine /llms.txt im Website-Root ist keine Infrastruktur. Outcome-orientierte Aufgabenbeschreibungen sind keine Infrastruktur. Der Begriff schließt genau das aus, was gemeint ist.

„Environment“ hat ein anderes Problem: es ist doppelt besetzt. In der Ökologie. Und im Dev/Staging/Prod-Kontext. Wenn du „Agent Environment“ sagst, denkst du an eine Staging-Umgebung. Das ist nicht gemeint.

„Habitat“ ist im KI-Diskurs relativ frei.

Was gehört zu einem agent-freundlichen Habitat?

Habitat Engineering lässt sich in klar abgrenzbare Bereiche gliedern. Wenn du das Stichwort KI Agent Umgebung aufbauen kennst oder dir das schon mal gedacht hast, das ist genau dieser Bereich.

Content und Konventionen

Fange mit dem Einfachsten: /llms.txt im Website-Root. Das ist eine schlichte Textdatei, die beschreibt, was es auf deiner Website zu finden gibt, strukturiert für KI-Systeme statt für Menschen. Eine Art Inhaltsverzeichnis für Agenten. Du legst sie in zehn Minuten an, und sie sagt jedem KI-System, das deine Website besucht: Was gibt es hier? Was ist wichtig? Wo fange ich an? Statt dass ein Agent deine JavaScript-gerenderte Seite zu entziffern versucht.

Laut einer SE Ranking-Analyse über 300.000 Domains hat llms.txt eine Adoptionsrate von 10,13%. Websites mit llms.txt zeigen 30 bis 70% höhere Genauigkeit in KI-generierten Zusammenfassungen. Quelle: SE Ranking / linkbuildinghq.com, 2026. Das ist Habitat Engineering in zehn Minuten.

Dazu gehören: .md-Versionen wichtiger Seiten, AGENTS.md und CLAUDE.md an stabilen Orten, Outcome-orientierte Aufgabenbeschreibungen statt Implementierungs-Tickets.

API- und Daten-Hygiene

Hier wird es technischer. Gartner-Forschung aus 2025 zeigt: Nur 12% der Organisationen haben Daten von ausreichender Qualität für KI-Anwendungen. 85% der gescheiterten KI-Projekte nennen schlechte Datenqualität als Ursache. Quelle: Folio3 AI / Gartner, 2025. Das ist kein Modell-Problem. Das ist ein Habitat-Problem.

Was das konkret bedeutet: Idempotente, dokumentierte APIs mit klaren Fehlercodes, nicht „200 OK mit Fehler im Body“. Das ist eines der häufigsten Anti-Patterns. Ein Agent bekommt ein 200 OK, denkt alles ist gut, und handelt auf falscher Basis. OpenAPI-Specs und JSON-Schemas geben Agenten Kontrakte statt Rätsel. Sandbox-Lanes ermöglichen sicheres Schreiben ohne Produktionsrisiko.

Wissens-Topographie

Wissen muss für Agenten navigierbar sein. Das heißt: kurze, fokussierte Seiten statt Mega-Dokumente, die ein Dutzend Themen mischen. Verknüpfte Einträge statt Wissenssilos. Und: Ist eine Aussage belegtes Wissen oder eine Einschätzung? Ein Agent erkennt den Unterschied nicht automatisch. Das muss explizit im Habitat stehen.

Gartner prognostiziert: 60% aller KI-Projekte ohne AI-ready Data werden bis 2026 eingestellt. Quelle: Gartner, Februar 2025. Schlechtes Wissens-Habitat verhindert Agent-Erfolg, unabhängig davon, wie gut Prompt und Harness konfiguriert sind.

Identity, Trust, Audit

Das ist die Schicht, die am wenigsten sichtbar ist, und die größte Sprengkraft hat. Jeder Agent braucht seinen eigenen Service Account. Nicht shared. Nicht „wir haben einen Dev-User für alle Automatisierungen“. NIST hat im Februar 2026 die AI Agent Standards Initiative gestartet, mit explizitem Fokus auf Agent Security und Identity. Quelle: Strata Identity, 2026.

Warum ist das ein Habitat-Thema und kein Harness-Thema? Weil Identitäten und Audit-Strukturen außerhalb des Agenten liegen. Der Agent bringt sie nicht mit. Sie müssen in der Welt gebaut sein.

Was das konkret bedeutet: Jeder Agent bekommt eigene Zugangsdaten mit dem kleinstmöglichen Berechtigungsumfang. Schreibzugriff nur dort, wo Schreiben wirklich gebraucht wird. Lesezugriff nur auf Daten, die für den jeweiligen Workflow relevant sind. Und: Ein vollständiger Audit-Trail für jeden Agenten-Aufruf. Welcher Agent hat wann, im Auftrag von wem, welche Aktion auf welcher Ressource ausgeführt, und mit welchem Ergebnis? Wenn diese Frage nicht beantwortbar ist, gibt es kein Audit. Nur Hoffnung.

Die OpenID Foundation hat es 2025 formuliert: „An API call made by an agent on a user’s behalf is often logged indistinguishably from an action taken directly by the user, creating a black hole for accountability and forensics.“ Quelle: OpenID Foundation, 2025. Das ist ein Habitat-Fehler, kein Agent-Fehler.

Wie konkret diese Risiken sind, zeigt „Wenn KI-Agenten zur Angriffsfläche werden“: 341 bösartige Skills auf einem KI-Marktplatz, entdeckt, weil die Identitätsarchitektur darunter nicht stimmte.

Organisations-Substrat

Der letzte Bereich ist der am schwierigsten zu greifen, weil er nicht technisch ist. Klare Outcome-Definitionen für Workflows: der Agent soll das Ziel kennen, nicht den Schritt-für-Schritt-Weg. Eskalations-Pfade zu Menschen, sauber dokumentiert. Und: Routine versus Markenmoment getrennt. Wenn ein Agent nicht weiß, ob etwas Standard oder etwas Besonderes ist, rät er. Das ist gefährlich.

Der Habitat Compass: sechs Achsen für die Bewertung

Niemand baut alle fünf Bereiche auf einmal. Der Habitat Compass hilft dir zu sehen, wo du gerade stehst und wo der nächste sinnvolle Schritt liegt. Sechs Achsen: drei zeigen, was das Habitat dem Agenten ermöglicht, drei zeigen, was es verhindert.

Die Kernregel: Möglichkeiten maximieren, Grenzen standardmäßig einbauen, und beides baulich, nicht prozessual. Prozessuale Constraints verfallen unter Zeitdruck. Checklisten, Reviews, Schulungen, sie halten, solange niemand Druck hat. Bauliche Constraints, Sandbox, Default-Deny, Quotas, Approval-Gates, halten unter Druck.

Habitat-Mängel werden als Agent-Mängel fehldiagnostiziert. Schlechte Daten? „Der Agent halluziniert.“ Keine Konventionen? „Der Agent macht komische Sachen.“ Kein Audit-Trail? „Irgendwas ist schiefgelaufen.“

Einmal gebaut, für jeden Agenten: die Hebelwirkung des Habitats

Habitat Engineering hat eine Eigenschaft, die die anderen drei Tiers nicht haben: Die Investition wächst mit jedem Agenten. Nicht linear. Kumulativ.

Wenn du heute deinen Prompt verbesserst, hilft das dem nächsten Prompt. Wenn du den Context verbesserst, hilft das dem nächsten Query. Wenn du ein Tool zum Harness hinzufügst, hilft das dem nächsten Task.

Wenn du heute dein Habitat baust, zahlt das für jeden zukünftigen Agenten, der dort operiert. Kein erneutes Kalibrieren. Kein erneutes Dokumentieren. Die /llms.txt existiert, jeder Agent liest sie. Der Knowledge Graph ist strukturiert, jeder neue Agent kann darin navigieren.

Das ist der entscheidende Unterschied zu den anderen drei Tiers: das Habitat arbeitet für jeden Agenten, der danach kommt. Statt dass jeder neue Agent neu kalibriert, neu dokumentiert, neu abgesichert werden muss, übernimmt er das, was bereits im Habitat steht.

Dazu kommt ein Befund, der viele überrascht: Laut einer Analyse von AI Governance Today / Folio3 AI, 2026 sind 77% der KI-Ausfälle organisatorischer Natur, nicht technischer. Das ist kein Modell-Problem. Das ist ein Habitat-Problem. Und für kleine Unternehmen mit drei Systemen statt fünfzehn: Das Habitat ist leichter zu bauen als in jedem Konzern. Weniger Altlasten. Weniger Trägheit. Agentische Strukturen für kleine Unternehmen sind nicht das abgespeckte Konzernprojekt. Sie sind der klarste Einstieg.

Wie fange ich mit Habitat Engineering an?

Drei Fragen, die du dir heute stellen kannst, ohne Architektur-Projekt, ohne Budget.

Erstens: Kannst du /llms.txt in zehn Minuten anlegen? Wenn ja , tu es. Das ist der kleinste erste Schritt ins Habitat.

Zweitens: Welche drei Fragen tauchen bei dir in der Woche am häufigsten auf , und liegen die Antworten so, dass ein Agent sie finden könnte? Ohne dich zu fragen?

Drittens: Wenn ein Agent heute eine Aktion in deinem System ausgeführt hat: Wüsstest du morgen noch, welcher Agent es war, warum, und im Auftrag von wem?

Wenn du mindestens eine dieser Fragen mit „nein“ beantwortest, hast du dein erstes Habitat-Ticket.

Die Vier-Tier-Hierarchie ist auch ein strukturiertes Diagnose-Werkzeug: Wenn dein Agent scheitert, fange nicht reflexartig beim Prompt an. Frag der Reihe nach: War die Anweisung klar? Hatte er die richtigen Informationen? Hatte er die richtigen Werkzeuge? Und dann: Konnte die Welt überhaupt erschlossen werden? Die Schicht, die momentan noch oft übersehen wird, ist Tier 4. Daten chaotisch, APIs undokumentiert, Wissen fragmentiert, das sieht aus wie ein schlechter Agent. Ist aber ein schlechtes Habitat.

Meine Einschätzung: In den nächsten zwei Jahren wird Habitat Engineering von einem Begriff zu einer Praxis. Nicht für alle gleichzeitig, sondern für die, die jetzt anfangen, sich die richtige Frage zu stellen. Nicht: „Wie verbessere ich den Prompt?“ Sondern: „In welcher Welt lebt mein Agent?“

Die ersten Antworten findest du, sobald du beginnst, deinen Agenten wie einen Bewohner zu behandeln, nicht wie ein Werkzeug.