Wie ich tatsächlich KI-Agenten baue, die Arbeit erledigen

Vor sechs Monaten sah ich einen Engineer, der einen KI-Agenten demonstrierte, der Meetings buchte, Angebote entwarf und ein CRM aktualisierte — alles aus einem einzigen Prompt. Die gesamte Sequenz dauerte etwa neunzig Sekunden. Das Publikum klatschte. Jemand fragte "ist das echt?" Der Präsentator lächelte und sagte ja.

Ich ging nach Hause und versuchte, dasselbe zu bauen. Es dauerte drei Wochen, bis ich etwas hatte, das halb so funktional war. Der Agent halluzinierte Tool Calls. Er vergaß den Kontext zwischen den Schritten. Er rief die falschen API-Endpoints mit den falschen Parametern auf. An einem Punkt schickte er eine Test-E-Mail an einen echten Kunden mit der Betreffzeile "TODO: fix this later."

Diese Erfahrung lehrte mich etwas, auf das ich immer wieder zurückkomme: Die Kluft zwischen einer KI-Agent-Demo und einem KI-Agenten, der in Produktion funktioniert, ist enorm. Und fast niemand spricht darüber, was diese Kluft füllt.

Kürzlich sah ich mir Remy Gasills Aufschlüsselung zum Meistern von KI-Agenten an — ein wirklich gründlicher Durchlauf, der den gesamten Stack von mentalen Modellen bis zur praktischen Architektur abdeckt. Es kristallisierte viele Muster, die ich intuitiv verwendet hatte, zu Frameworks, die ich jetzt klar erklären kann. Was folgt, ist meine Sicht auf diese Konzepte, gefiltert durch Monate des Bauens von Agenten mit Claude Code für echte Projekte, echte Kunden und echte Fehler.

Was mich am meisten überraschte? Der schwierigste Teil beim Bauen nützlicher KI-Agenten ist nicht die KI. Es ist alles rund um die KI.

Chat-Modelle sind keine Agenten (und die Verwechslung kostet dich Wochen)

Das muss ich zuerst klären, denn das Missverständnis ist so weit verbreitet, dass es zum Standard-Denkmodell geworden ist — und es ist falsch.

Wenn die meisten Menschen sagen "ich nutze KI-Agenten," meinen sie, dass sie ChatGPT oder Claude öffnen und Fragen eintippen. Das ist ein Chat-Modell. Ein sehr gutes. Aber es ist grundlegend eine One-Shot-Interaktion: du fragst, es antwortet, du fragst nochmal, es antwortet nochmal. Jeder Austausch ist relativ isoliert. Das Modell geht nicht in deinem Auftrag los und erledigt Dinge. Es reagiert.

Ein Agent ist architektonisch anders. Ein Agent empfängt ein Ziel, zerlegt es in Schritte, führt diese Schritte mit Tools aus, bewertet die Ergebnisse und entscheidet, was als Nächstes zu tun ist — alles ohne dass du einen weiteren Prompt eingibst. Der Mensch legt das Ziel fest. Der Agent fährt.

Denk so darüber nach. Wenn du ein Chat-Modell bittest, "ein neues Express.js-Projekt mit TypeScript, ESLint und Prettier konfiguriert aufzusetzen," bekommst du eine wunderbare Antwort, die jeden Schritt erklärt. Vielleicht sogar Code Blocks zum Kopieren und Einfügen. Aber du musst immer noch die Dateien erstellen. Du musst immer noch die Befehle ausführen. Du musst immer noch die Konfigurationskonflikte zwischen ESLint und Prettier debuggen, die das Modell vergessen hat zu erwähnen.

Ein Agent, der in Claude Code läuft? Er erstellt das Verzeichnis. Initialisiert das Projekt. Installiert Dependencies. Schreibt die Konfigurationsdateien. Führt den Linter aus, um zu verifizieren, dass alles funktioniert. Behebt die zwei Konfigurationskonflikte, die er findet. Committed das Ergebnis. Fertig.

Dieser Unterschied — zwischen dir zu sagen, was du tun sollst, und es tatsächlich zu tun — ist der gesamte Paradigmenwechsel. Und er verändert, wie du über jede Aufgabe nachdenkst, die du an KI delegierst.

Ich verbrachte meinen ersten Monat mit Claude Code und behandelte es immer noch wie ein Chat-Modell. Fragen stellen. Antworten lesen. Die Vorschläge manuell ausführen. In dem Moment, als ich anfing, ihm Ziele statt Fragen zu geben, veränderte sich meine Produktivität auf eine messbare Weise: Aufgaben, die mich 45 Minuten kosteten, waren in unter 10 erledigt. Nicht weil die KI schlauer wurde. Weil ich aufhörte, der Flaschenhals zwischen ihrem Denken und ihrem Handeln zu sein.

Aber hier ist der Punkt — ein Agent funktioniert nur, wenn die zugrunde liegende Architektur solide ist. Und diese Architektur hat einen Namen.

Die Agent Loop: Observe, Think, Act

Jeder funktionale KI-Agent läuft auf derselben Kernschleife. Remy Gasill nennt sie "observe, think, act," und dieses Framing ist das klarste, das ich gesehen habe. Sobald du diese Schleife verstehst, verstehst du, warum Agenten Erfolg haben oder scheitern — und noch wichtiger, wie du sie debuggen kannst, wenn sie kaputtgehen.

Observe. Der Agent nimmt Kontext auf. Das umfasst die ursprüngliche Aufgabe, alle gelesenen Dateien, Tool-Outputs aus vorherigen Schritten, Fehlermeldungen, Umgebungsstatus. Alles, was der Agent in diesem Moment weiß, lebt in seinem Context Window. Die Qualität dieser Beobachtungsphase bestimmt alles Nachfolgende.

Think. Das LLM argumentiert über das, was es beobachtet hat. Was wurde bisher erreicht? Was bleibt übrig? Was ist der nächste logische Schritt? Soll es ein Tool aufrufen, um Klärung bitten oder ein Endergebnis liefern? Hier zählt die Intelligenz des Modells wirklich — und hier beginnen günstigere Modelle bei komplexen Aufgaben zu kämpfen.

Act. Der Agent führt einen Tool Call aus. Eine Datei lesen. Einen Terminalbefehl ausführen. Eine API-Anfrage stellen. Code bearbeiten. Welche Aktion der Reasoning-Schritt auch ausgewählt hat, der Agent führt sie aus. Das Ergebnis dieser Aktion fließt zurück in die Beobachtungsphase, und die Schleife geht weiter.

Dieser Zyklus wiederholt sich — manchmal dreimal, manchmal dreißigmal — bis der Agent feststellt, dass die Aufgabe abgeschlossen ist.

Das hat eine Weile gedauert, bis ich es verinnerlicht hatte: Die Schleife ist, wo die Qualität des Agenten liegt. Nicht im Modell. Nicht in den Tools. In der Schleife. Ein mittelmäßiges Modell mit exzellentem Context Engineering und gut designten Tools übertrifft ein brillantes Modell mit schlampigem Kontext und schlecht definierten Tools. Ich habe das getestet. Ich habe dieselbe Aufgabe durch Claude Opus 4.6 mit miserablen Kontextdateien geschickt versus Claude Sonnet mit sorgfältig erstelltem Kontext. Sonnet gewann. Durchgehend.

Deshalb sind die nächsten drei Konzepte — Harnesses, Context Engineering und Skills — so wichtig. Sie sind allesamt Mechanismen, um die Schleife besser funktionieren zu lassen.

Agent Harnesses: das Cockpit, in dem deine KI sitzt

Die Agent Loop läuft nicht im Vakuum. Sie braucht eine Umgebung — ein Harness — das die Schleifenausführung verwaltet, Tools bereitstellt, Berechtigungen handhabt und die Schnittstelle präsentiert, mit der du interagierst. Stell es dir als Cockpit vor. Das LLM ist der Pilot. Das Harness ist jedes Instrument, jede Steuerfläche und jedes Sicherheitssystem rund um diesen Piloten.

Ich habe intensiv mit vier Harnesses gearbeitet, und jedes hat seine eigene Persönlichkeit.

Claude Code ist mein tägliches Arbeitstier. Terminal-nativ, tiefe Filesystem- und Git-Integration, granulare Berechtigungen. Wenn ich einen Agenten brauche, der über eine gesamte Codebase argumentieren und Änderungen souverän durchführen kann, kommt im Moment nichts anderes heran.

Codex von OpenAI startet eine gesandboxte Cloud-Umgebung für jede Aufgabe — deine lokalen Dateien bleiben unberührt, es sei denn, du synchronisierst Ergebnisse explizit zurück. Hervorragend für Teams, die sich um den Blast Radius sorgen. Der Kompromiss ist Latenz durch das Hochfahren der Umgebung.

OpenClaw ist die Open-Source-Option, die es sich zu beobachten lohnt. Terminal-basiert, erweiterbar, community-getrieben. Rauere Kanten als Claude Code, aber maximale Kontrolle über das Agentenverhalten.

Co-work-Agenten (wie Anthropics webbasierter Claude-Agent) bewältigen langlaufende Aufgaben. Schick eine Anfrage ab, schließ den Browser, komm für die Ergebnisse zurück. Forschungssynthese, Analyse großer Dokumente, mehrstufige Workflows, die keine Echtzeit-Interaktion benötigen.

Wähle das Harness, das zu deiner Arbeitsweise passt. Ich habe zwei Wochen verschwendet, einen webbasierten Agenten für schnelle Code-Iteration zu nutzen, bevor ich zu Claude Code wechselte — und meine Frustration verschwand über Nacht. Es gibt keine universell beste Wahl, nur die richtige Passung für deinen Workflow.

Aber unabhängig davon, welches Harness du wählst, gibt es ein Protokoll, das schnell zum Standard für die Verbindung von Agenten mit externen Tools wird. Und wenn du es noch nicht nutzt, baust du mit einer Hand auf dem Rücken gefesselt.

MCP: der USB-C-Anschluss für KI-Agenten

Model Context Protocol — MCP — ist eines dieser Dinge, die langweilig klingen, bis man versteht, was es tatsächlich freischaltet. Dann wird es zum aufregendsten Teil des Agent-Stacks.

Hier ist das Problem, das MCP löst. Angenommen, du möchtest, dass dein Agent mit deiner Datenbank interagiert. Ohne MCP würdest du Custom Code schreiben: eine Funktion, die sich mit PostgreSQL verbindet, eine Query ausführt, die Ergebnisse formatiert und an den Agenten zurückgibt. Dann willst du Slack-Integration. Mehr Custom Code. Dann Google Calendar. Mehr Custom Code. Dann deine interne API. Mehr Custom Code. Jede Integration ist Maßarbeit, fragil und wird nur von dir allein gepflegt.

MCP standardisiert das. Es schafft ein universelles Protokoll — stell es dir als USB-C-Anschluss vor — an den sich jedes Tool anschließen kann. Jemand baut einmal einen MCP-Server für PostgreSQL, und jedes Agent-Harness, das MCP unterstützt, kann ihn nutzen. Ein anderer baut einen für Slack. Noch einer für Notion. Wieder einer für dein CRM. Dem Agenten ist egal, wie das Tool intern funktioniert. Er ruft es einfach über MCP auf und bekommt strukturierte Ergebnisse zurück.

Ich betreibe derzeit MCP-Server für GitHub, Filesystem-Zugriff und eine custom interne API, die ich für ein Kundenprojekt gebaut habe. Das Hinzufügen einer neuen Fähigkeit zu meinem Agenten bedeutete früher, Integrationscode zu schreiben. Jetzt bedeutet es, drei Zeilen zu einer Konfigurationsdatei hinzuzufügen, die auf einen MCP-Server verweist.

Das praktische Setup sieht in Claude Code so aus:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token-here"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

Setze das in deine .claude/-Konfiguration, und plötzlich kann dein Agent GitHub-Repos und PostgreSQL-Datenbanken so natürlich abfragen, wie er Dateien liest. Keine Custom Wrapper. Kein fragiler API-Code. Einfach Tools, verfügbar und bereit.

Das MCP-Ökosystem wächst schnell. Anfang 2026 gibt es von der Community gepflegte Server für Dutzende von Diensten — Datenbanken, Kommunikationstools, Cloud-Anbieter, Projektmanagement-Plattformen. Die Qualität variiert (manche sind hervorragend, manche sind Wochenendprojekte), aber die Richtung ist klar. MCP wird zur Standard-Integrationsschicht für KI-Agenten.

Eine Sicherheitsbemerkung, die ich hier anmerken möchte, weil sie wichtig ist: Jeder MCP-Server, den du hinzufügst, erweitert die Angriffsfläche deines Agenten. Ein MCP-Server mit Datenbankzugriff bedeutet, dass dein Agent deine Datenbank lesen — und möglicherweise beschreiben — kann. Begrenze Berechtigungen strikt. Nutze wo möglich Read-only-Verbindungen. Gib deinem Agenten nicht die Schlüssel zur Produktion, es sei denn, du hast gründlich darüber nachgedacht, was passiert, wenn er einen Fehler macht. Denn er wird Fehler machen. Meiner hat es auf jeden Fall getan.

Das bringt uns zu etwas, das genauso wichtig ist wie die Tools, die dein Agent nutzen kann — und möglicherweise noch wichtiger: der Kontext, den dein Agent erhält, bevor er mit der Arbeit beginnt.

Context Engineering: die Fähigkeit, die niemand lehrt

Früher dachte ich, Prompt Engineering sei die Engpass-Fähigkeit für die Arbeit mit KI. Schreib bessere Prompts, bekomm bessere Ergebnisse. Und das stimmt — für Chat-Modelle. Für Agenten ist der Engpass etwas anderes: Context Engineering.

Context Engineering ist die Praxis, zu strukturieren, was ein Agent vor und während der Ausführung weiß. Es ist nicht nur der Prompt, den du eingibst. Es sind die Dateien, die der Agent automatisch liest. Die projektspezifischen Anweisungen, die er verarbeitet, bevor er deine Anfrage bearbeitet. Das Gedächtnis, das er aus früheren Sitzungen mitbringt. Die Konventionen, die er befolgt, ohne jedes Mal daran erinnert zu werden.

In Claude Code lebt Context Engineering hauptsächlich an zwei Stellen: CLAUDE.md und agents.md-Dateien.

Deine CLAUDE.md-Datei ist das Erste, was Claude Code liest, wenn es eine Sitzung in einem Verzeichnis startet. Meine enthält projektspezifische Konventionen, Architekturentscheidungen, Coding-Standards und explizite Anweisungen darüber, was NICHT zu tun ist. Dieser letzte Teil — die negativen Einschränkungen — erwies sich als überraschend wichtig. Ohne sie macht der Agent ständig vernünftige-aber-falsche Annahmen.

Hier ist ein gekürztes Beispiel aus einem meiner Laravel-Projekte:

# CLAUDE.md

## Project Architecture
- Laravel 11 with Inertia.js + React 19 + TypeScript
- PostgreSQL 16, Redis 7 for caching and queues
- All API responses use the ApiResponse helper class — never return raw arrays

## Conventions
- Controllers: single-action when possible, __invoke method
- Form Requests for ALL validation — never validate in controllers
- Feature tests use RefreshDatabase, unit tests don't touch the database

## Do NOT
- Never modify the User model without explicit approval
- Never change database migrations that have already been committed
- Never use DB::raw() — use the query builder or Eloquent scopes
- Never create routes outside of routes/web.php and routes/api.php

Diese Datei erspart mir, den Agenten dutzende Male pro Sitzung zu korrigieren. Ohne sie würde Claude Code gelegentlich Validierungslogik in Controller setzen, rohe SQL-Queries verwenden oder Routendateien an nicht standardmäßigen Orten erstellen. Alles vernünftige Entscheidungen isoliert betrachtet — nur falsch für dieses spezifische Projekt.

Das agents.md-Muster erweitert dies weiter für Multi-Agent-Setups. Wenn ich spezialisierte Agenten habe — einen Code-Review-Agenten, einen Dokumentations-Agenten, einen Testing-Agenten — bekommt jeder seine eigene Kontextdatei, die seine Rolle, Einschränkungen und erwartetes Verhalten definiert. So gehst du von einem Allzweck-Agenten zu einem Team spezialisierter Agenten über, die jeweils ihre Arbeit gut machen.

Remy Gasill machte einen Punkt, der mir im Gedächtnis blieb: Context Engineering geht letztlich darum, die Anzahl der Entscheidungen zu reduzieren, die ein Agent eigenständig treffen muss. Jede Entscheidung, die er autonom trifft, ist ein potenzieller Fehler. Jede Entscheidung, die du in den Kontext codierst, ist eine Gelegenheit weniger für den Agenten, vom Kurs abzukommen. Die besten Agent-Setups, die ich gebaut habe, sind fast langweilig anzusehen. Der Agent trifft keine kreativen Entscheidungen. Er folgt einem klar definierten Pfad, mit klar definierten Tools, innerhalb klar definierter Einschränkungen. Und er liefert exzellente Arbeit wegen dieser Vorhersagbarkeit, nicht trotz ihr.

Aber Kontextdateien decken nur ab, was der Agent zu Beginn wissen sollte. Was ist mit dem, was er während der Arbeit lernt?

Memory.md: deinem Agenten beibringen, sich zu erinnern

Das ist das Feature, das meine Agent-Workflows von sitzungsbasiert zu kontinuierlich transformiert hat.

Standardmäßig verschwindet alles, was der Agent während einer Sitzung gelernt hat, wenn du eine Claude-Code-Sitzung schließt. Öffne eine neue Sitzung, und er fängt von vorne an. Er weiß nichts über den Bug, den du gestern behoben hast. Er weiß nichts über das API-Muster, auf das ihr euch letzte Woche geeinigt habt. Er weiß nicht, dass die UserService-Klasse in der vorherigen Sitzung in drei kleinere Services refactored wurde.

Memory.md ändert das. Es ist eine persistente Datei — gespeichert in deinem Projektverzeichnis — die der Agent zu Beginn jeder Sitzung liest und während der Sitzung aktualisieren kann. Stell es dir als gemeinsames Notizbuch zwischen deinen vergangenen und zukünftigen Agent-Sitzungen vor.

Meine memory.md für ein aktuelles Projekt sieht ungefähr so aus:

# Memory

## Decisions Made
- 2026-03-10: Switched from JWT to session-based auth. JWT was causing issues
  with token refresh on mobile. Session approach uses Redis for storage.
- 2026-03-14: Moved all email templates from Blade to React Email. Better
  component reuse and type safety.
- 2026-03-17: Added rate limiting middleware to all public API endpoints.
  Config: 60 requests/minute for authenticated, 20 for unauthenticated.

## Known Issues
- The PaymentService has a race condition on concurrent subscription updates.
  Temporary fix: database-level advisory lock. Proper fix planned for next sprint.
- Test suite takes 4+ minutes to run. Focus: writing targeted tests, not
  running the full suite on every change.

## Patterns Established
- All new services use constructor injection with interfaces, not facades.
- Background jobs extend BaseJob which handles retry logic and dead-letter queue.
- API versioning: URI-based (/v1/), not header-based.

Wenn der Agent diese Datei zu Beginn der Sitzung liest, hat er sofort Kontinuität. Er wird kein JWT für das Auth-System vorschlagen. Er wird kein Blade für E-Mail-Templates verwenden. Er weiß von der Race Condition und wird sie nicht versehentlich auslösen. Er folgt den etablierten Mustern, ohne daran erinnert zu werden.

Ich aktualisiere diese Datei manuell etwa einmal pro Woche, und ich habe begonnen, den Agenten selbst Einträge hinzufügen zu lassen, wenn während einer Sitzung bedeutende Entscheidungen getroffen werden. Der Befehl ist einfach — "add this decision to memory.md" — und der Agent formatiert und fügt ihn hinzu.

Der Zinseszinseffekt ist real. Nach einem Monat der Pflege von memory.md starten meine Agent-Sitzungen spürbar schneller. Weniger Korrekturen. Weniger Wiederholungen. Weniger "nein, wir haben beschlossen, es nicht so zu machen." Der Agent hat institutionelles Wissen. Und dieses Wissen bleibt erhalten.

Wenn du lieber möchtest, dass jemand diese gesamte Agent-Architektur für dich aufbaut — Kontextdateien, Gedächtnissysteme, MCP-Integrationen, den gesamten Workspace — übernehme ich genau solche Aufträge. Du kannst sehen, was ich gebaut habe, unter fiverr.com/s/EgxYmWD.

Nun sagt Memory dem Agenten, was in der Vergangenheit passiert ist. Aber wie sagst du ihm, wie er wiederkehrende Aufgaben jedes Mal richtig ausführen soll?

Skills: Standard-Arbeitsanweisungen, denen dein Agent folgen kann

Skills sind das Konzept, das meine Agenten endlich konsistent gemacht hat. Bevor ich sie einführte, variierte die Ausgabequalität jedes Mal, wenn ich einen Agenten bat, "einen Blogbeitrag zu schreiben" oder "einen API-Endpoint zu erstellen" oder "einen neuen Microservice aufzusetzen." Manchmal hervorragend. Manchmal mittelmäßig. Immer leicht anders als beim letzten Mal.

Das Problem war nicht das Modell. Es war ich. Ich gab vage Anweisungen und erwartete konsistente Ergebnisse. Das ist, als würdest du jemandem eine Stellenbezeichnung geben ohne Einarbeitungshandbuch und dich dann wundern, dass er Dinge anders macht als erwartet.

Skills sind das Einarbeitungshandbuch.

Ein Skill ist eine Markdown-Datei — gespeichert in .claude/skills/ — die schrittweise Anweisungen für eine bestimmte, wiederholbare Aufgabe enthält. Der Agent liest den relevanten Skill vor der Ausführung und folgt ihm wie einer Standard-Arbeitsanweisung.

Hier ist ein echter Skill, den ich für das Erstellen von API-Endpoints in meinen Laravel-Projekten verwende:

# Skill: Create API Endpoint

## Steps
1. Create a Form Request class in `app/Http/Requests/` with validation rules
2. Create a single-action controller using `__invoke` method
3. Add the route to `routes/api.php` inside the appropriate version group
4. Create a feature test in `tests/Feature/Api/` that covers:
   - Successful request with valid data
   - Validation failure with each invalid field
   - Authentication/authorization check
   - Edge cases specific to the endpoint
5. Run the test suite: `php artisan test --filter={TestClassName}`
6. If tests pass, add the endpoint to the API documentation in `docs/api.md`

## Conventions
- Response format: always use ApiResponse::success() or ApiResponse::error()
- Status codes: 201 for creation, 200 for retrieval/update, 204 for deletion
- Never return Eloquent models directly — use API Resources

## Common Mistakes to Avoid
- Don't forget to add the route inside the auth middleware group
- Don't use Route::resource() — we use explicit single-action routes
- Don't skip the authorization check in the Form Request

Wenn ich dem Agenten sage "erstelle einen API-Endpoint für Benutzerprofil-Updates," liest er diesen Skill und folgt ihm Schritt für Schritt. Jedes Mal. Die Controller-Struktur ist konsistent. Die Testabdeckung ist konsistent. Das Antwortformat ist konsistent. Keine Varianz mehr. Kein "oh, er hat diesmal den Form Request vergessen."

Das Schöne an Skills als einfachen Markdown-Dateien ist die Portabilität. Sie funktionieren über Agent-Harnesses hinweg. Dieselbe Skill-Datei, die ich in Claude Code verwende, funktioniert in Cursor, in OpenClaw, in jedem Tool, das Markdown-Anweisungen liest. Eine Quelle der Wahrheit, mehrere Nutzer.

Ich habe derzeit elf Skills in meinem Hauptprojekt: API-Endpoint-Erstellung, Datenbankmigration, Component-Scaffolding, Tests schreiben, Code Review, Dokumentationsaktualisierung, Deployment Checks, Security Audit, Performance Review, Bug Triage und PR-Beschreibungsgenerierung. Jeder hat mich 15-20 Minuten zum Schreiben gekostet. Zusammen sparen sie mir Stunden pro Woche und — noch wichtiger — sie haben eine ganze Kategorie von "der Agent hat es falsch gemacht"-Momenten eliminiert.

Skills verstärken sich mit Memory. Der Agent liest den Skill für wie etwas zu tun ist. Er liest memory.md für welche Entscheidungen bereits getroffen wurden. Zusammen geben sie dem Agenten das prozedurale Wissen und den institutionellen Kontext, den er braucht, um wie ein Teammitglied zu arbeiten, das seit Monaten am Projekt ist, nicht wie ein Auftragnehmer, der die Codebase zum ersten Mal sieht.

Sicherheit und Berechtigungsscoping: das Gespräch, das niemand führen will

Ich sage es direkt: einem KI-Agenten Zugriff auf dein Dateisystem, Terminal und externe APIs zu geben, ist eine Sicherheitsentscheidung. Behandle sie als solche.

Ein Engineer, den ich kenne, gab seinem Agenten pauschalen Schreibzugriff, und er überschrieb eine Produktions-.env-Datei während eines routinemäßigen Refactorings. Nichts Böswilliges — einfach eine vernünftige-aber-katastrophale Entscheidung in einem Kontext, in dem der Agent diese Macht nicht hätte haben sollen.

Meine Berechtigungsprinzipien:

Prinzip der minimalen Rechte. Gib dem Agenten genau den Zugriff, den er braucht, und nichts mehr. Wenn er nur Dateien lesen muss, gewähre keinen Schreibzugriff. Wenn er nur innerhalb von /src arbeiten muss, lass ihn nicht auf / zugreifen. MCP-Server sollten Read-only-Datenbankverbindungen verwenden, es sei denn, Schreibzugriff ist explizit für die Aufgabe erforderlich.

Sandbox für nicht vertrauenswürdige Operationen. Wenn du einen neuen Skill testest oder einen neuen MCP-Server ausprobierst, führe ihn zuerst in einer gesandboxten Umgebung aus. Ein frischer Git-Branch, ein Docker-Container, eine wegwerfbare VM. Beobachte, was der Agent tut, bevor du ihm etwas Wertvolles anvertraust.

Audit Trails sind wichtig. Git Diffs sind dein Freund. Jede Agentenänderung sollte inkrementell committed werden, damit du reviewen und revertieren kannst. Ich reviewe agentengenerierte Diffs auf dieselbe Weise wie Pull Requests von Junior Developern — mit Aufmerksamkeit und gesunder Skepsis.

Trenne Umgebungen strikt. Produktionsprojekte bekommen striktere Berechtigungen, weniger MCP-Server und explizite Do NOT-Abschnitte. Experimentelle Projekte bekommen mehr Freiheit, weil der Blast Radius kleiner ist.

API-Schlüssel und Credentials. Lege niemals Credentials in für den Agenten zugängliche Konfigurationsdateien. Nutze Umgebungsvariablen. Geh davon aus, dass alles, was der Agent lesen kann, versehentlich in einem Log oder generierten Code-Kommentar auftauchen könnte. Ich habe es erlebt.

Die Agenten, denen ich am meisten vertraue, sind diejenigen, die ich am sorgfältigsten eingeschränkt habe.

Apropos sorgfältige Architektur — wie du all diese Teile organisierst, ist wichtiger als man erwarten würde.

Workspace-Architektur: die Ordnerstruktur, die skaliert

Nach Monaten der Iteration habe ich mich auf eine Workspace-Struktur für agentenbetriebene Projekte festgelegt, die alles handhabt — Kontext, Gedächtnis, Skills, MCP-Konfiguration — ohne zum Chaos zu werden, wenn das Projekt wächst.

project-root/
├── .claude/
│   ├── settings.json          # MCP servers, permission config
│   ├── agents/
│   │   ├── code-review.md     # Specialized agent: code review
│   │   ├── documentation.md   # Specialized agent: docs
│   │   └── testing.md         # Specialized agent: test writing
│   └── skills/
│       ├── create-endpoint/
│       │   └── skill.md
│       ├── write-migration/
│       │   └── skill.md
│       ├── security-audit/
│       │   └── skill.md
│       └── deploy-check/
│           └── skill.md
├── CLAUDE.md                  # Project-level context (read on every session)
├── memory.md                  # Persistent agent memory
├── src/                       # Your actual code
├── tests/
└── docs/

Drei Designentscheidungen, die es wert sind, erwähnt zu werden. Erstens steht CLAUDE.md im Projektstamm, nicht versteckt in .claude/ — Sichtbarkeit gewährleistet Pflege. Zweitens sind Skills Ordner (nicht einzelne Dateien), weil sie mit der Zeit unterstützende Templates und Beispiele ansammeln. Drittens ist memory.md einzigartig und global. Ich habe per-Agent Gedächtnisdateien versucht. Synchronisation war ein Albtraum. Eine gemeinsame Datei hält institutionelles Wissen über alle Agenten hinweg vereint.

Diese Struktur hat vier Kundenprojekte überlebt, ohne reorganisiert werden zu müssen. Der Schlüssel ist, von Tag eins damit zu beginnen — ein bestehendes Projekt nachträglich umzubauen ist möglich, aber mühsam.

Loslegen: dein erstes produktionsreifes Agent-Setup in 30 Minuten

Wenn du bis hierher gelesen hast, hast du das mentale Modell. Hier folgt, wie du von null zu einem funktionierenden Agent-Setup kommst, das alles umfasst, was wir besprochen haben — Kontext, Gedächtnis, Skills und grundlegende MCP-Integration. Dreißig Minuten. Keine Abkürzungen, keine Spielzeugbeispiele.

Schritt 1: Installiere Claude Code (5 Minuten)

npm install -g @anthropic-ai/claude-code

Führe claude in deinem Projektverzeichnis aus. Es authentifiziert sich beim ersten Start mit deinem Anthropic-Konto. Wenn du ein günstigeres Setup brauchst, habe ich Claude Code with OpenRouter in einer separaten Anleitung behandelt.

Schritt 2: Erstelle deine CLAUDE.md (10 Minuten)

Das sind die zehn Minuten mit der größten Hebelwirkung, die du verbringen wirst. Erstelle eine CLAUDE.md in deinem Projektstamm mit vier Abschnitten: Project Overview (was es ist, welcher Stack), Architecture (wichtige Entscheidungen, Verzeichnisstruktur), Conventions (Coding-Standards, Benennungsmuster) und Do NOT (Dinge, die der Agent niemals tun darf).

Sei spezifisch. "Best Practices befolgen" ist nutzlos. "Alle API-Antworten müssen die ResponseHelper-Klasse in app/Helpers/ verwenden" ist nützlich. Der Agent kann deine Gedanken nicht lesen, aber er kann dein Markdown lesen.

Schritt 3: Initialisiere memory.md (2 Minuten)

Erstelle eine memory.md im Projektstamm mit drei leeren Abschnitten: Decisions Made, Known Issues und Patterns Established. Beginne sparsam. Diese Datei wächst organisch, während du und der Agent gemeinsam echte Entscheidungen treffen. Vorzeitig Inhalte hineinzupressen erzeugt Rauschen.

Schritt 4: Erstelle deinen ersten Skill (8 Minuten)

Wähle die Aufgabe, die du am häufigsten ausführst. Für mich war das das Erstellen von API-Endpoints. Für dich könnte es das Schreiben von Tests sein, das Scaffolding von Komponenten oder das Einrichten neuer Seiten. Was auch immer es ist — schreibe die Schritte, die du jedes Mal befolgst, in eine skill.md-Datei:

mkdir -p .claude/skills/your-task-name

Schreibe die Skill-Datei mit nummerierten Schritten, Konventionen und häufigen Fehlern. Halte sie unter 50 Zeilen. Wenn sie länger ist, kombinierst du entweder mehrere Skills oder spezifizierst zu viel.

Schritt 5: Füge einen MCP-Server hinzu (5 Minuten)

Beginne mit etwas Risikoarmem. Der Filesystem-MCP-Server oder der GitHub-Server sind gute erste Wahlen. Erstelle .claude/settings.json:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Speichere den tatsächlichen Token in deinen Umgebungsvariablen, nicht in der Konfigurationsdatei. Teste es, indem du den Agenten bittest, "list my recent GitHub pull requests," und verifiziere, dass echte Daten zurückkommen.

Schritt 6: Führe deine erste agentische Aufgabe aus (5 Minuten)

Beginne mit etwas, bei dem du die richtige Antwort kennst — nicht etwas Komplexes. Bitte den Agenten, eine Aufgabe auszuführen, die von deiner Skill-Datei abgedeckt wird. Beobachte, wie er Kontext aus CLAUDE.md nutzt und den Schritten des Skills folgt.

Wenn die Ausgabe das Ziel verfehlt, liegt die Lösung fast immer in den Kontextdateien, nicht im Prompt. Schärfe die CLAUDE.md. Aktualisiere den Skill mit dem Schritt, den er übersprungen hat. Dieses iterative Nachschärfen ist die eigentliche Arbeit beim Bauen von Produktions-Agenten.

Die Zukunft ist ein persönliches KI-Betriebssystem

Hier ist, worüber ich nachdenke, wenn ich schaue, wohin das alles führt — und ich möchte ehrlich sein, das ist Spekulation auf Basis von Mustern, keine Vorhersage, auf die ich meine Hypothek verwetten würde.

Wir bauen in Richtung persönlicher KI-Betriebssysteme. Nicht die Vaporware-Art, die auf Konferenzen gepitcht wird. Die praktische Art, bei der dein Agent-Workspace zum primären Interface für deine digitalen Tools wird. Denk an das, was wir bereits haben: einen Agenten, der Dateien liest, Befehle ausführt, über MCP mit APIs interagiert, vergangene Entscheidungen erinnert, dokumentierte Prozeduren befolgt und sich verbessert, während Kontext und Skills sich ansammeln. Das ist kein Chatbot. Das ist eine Betriebssystemschicht zwischen dir und deinen Tools.

Remy Gasill zeigte in dieselbe Richtung. MCP liefert den Integrationsstandard. Skills liefern prozedurales Wissen. Memory liefert Kontinuität. Context Engineering liefert Ausrichtung. Die Puzzleteile existieren. Sie werden auf offenen Protokollen gebaut, die jedes Harness übernehmen kann.

Was mich am meisten begeistert, ist nicht die Erweiterung der Fähigkeiten — es ist die Multiplikation der Hebelwirkung. Ein Engineer mit einem gut konfigurierten Agent-Workspace arbeitet auf einer anderen Ebene. Aufgaben, die früher erforderten, jemanden einzustellen, werden zu Aufgaben, die du zwischen dem Kaffee und deinem ersten Meeting delegierst.

Was das tatsächlich an deiner Arbeitsweise ändert

Hier ist, was ich möchte, dass du mitnimmst — ein klares mentales Modell und eine konkrete Aktion.

Das mentale Modell: Ein KI-Agent ist eine Schleife (observe, think, act), die in einem Harness läuft (Claude Code, Codex, etc.), verbunden mit Tools (via MCP), geleitet durch Kontext (CLAUDE.md, agents.md), Prozeduren befolgend (Skills) und vergangene Arbeit erinnernd (memory.md). Jede dieser Komponenten ist ein Hebel, den du bewegen kannst, um deinen Agenten zu verbessern. Wenn etwas schiefgeht, identifiziere, welche Komponente versagt hat, und repariere diese — schreib nicht einfach deinen Prompt um.

Die konkrete Aktion: Nimm dir heute dreißig Minuten und baue die Workspace-Struktur, die ich im Implementierungsabschnitt beschrieben habe. Erstelle die CLAUDE.md. Starte die memory.md. Schreibe einen Skill. Füge einen MCP-Server hinzu. Führe eine Aufgabe aus. Das ist deine Startlinie.

In sechs Monaten wirst du auf den Agent-Workflow zurückblicken, den du gebaut hast — den angesammelten Kontext, die verfeinerten Skills, die kampferprobte Gedächtnisdatei — und du wirst etwas erkennen. Der Agent ist in diesen sechs Monaten nicht schlauer geworden. Du bist besser darin geworden, ihn zu dirigieren. Und das ist die echte Fähigkeit, die niemand lehrt: nicht wie man KI benutzt, sondern wie man das System architektiert, das KI nützlich macht.

Was ist die erste Aufgabe, die du delegieren wirst?

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem KI-Agenten und einem gewöhnlichen Chatbot?

Ein KI-Agent führt autonom mehrstufige Aufgaben mit Tools aus — Dateien lesen, Befehle ausführen, APIs aufrufen — in einer kontinuierlichen Schleife, bis das Ziel erreicht ist. Ein Chatbot reagiert auf einzelne Prompts, ohne Aktionen durchzuführen. Für Details zur Observe-Think-Act-Schleife siehe den Abschnitt Agent Loop oben.

Wie funktioniert MCP (Model Context Protocol) mit KI-Agenten?

MCP bietet eine standardisierte Schnittstelle zur Verbindung von KI-Agenten mit externen Tools und Diensten wie Datenbanken, APIs und Kommunikationsplattformen. Du konfigurierst MCP-Server in der Einstellungsdatei deines Agenten, und der Agent ruft sie wie native Tools auf. Siehe den MCP-Abschnitt oben für Konfigurationsbeispiele.

Brauche ich Programmiererfahrung, um KI-Agenten für Produktivität einzurichten?

Grundlegendes Wohlbefinden mit dem Terminal und Vertrautheit mit der Dateibearbeitung reichen zum Start aus. Das Workspace-Setup verwendet Markdown-Dateien und JSON-Konfiguration — kein Framework-Code erforderlich. Die schrittweise Anleitung im Implementierungsabschnitt deckt das komplette Setup für Einsteiger ab.

Welches KI-Agent-Harness sollte ich verwenden — Claude Code, Codex oder OpenClaw?

Wähle basierend auf deinem Workflow: Claude Code für terminal-native Entwicklung mit tiefer Filesystem-Integration, Codex für gesandboxte Cloud-Ausführung mit Sicherheitsgarantien, OpenClaw für maximale Open-Source-Erweiterbarkeit. Der Abschnitt Agent Harnesses oben vergleicht jedes im Detail.

Wie halte ich meinen KI-Agenten sicher, wenn ich ihm Tool-Zugriff gebe?

Wende Prinzipien minimaler Rechte an: Read-only-Datenbankverbindungen, begrenzte API-Tokens, gesandboxtes Testen für neue Tools und explizite Berechtigungseinschränkungen in deinen Kontextdateien. Speichere niemals Credentials in für den Agenten lesbaren Konfigurationsdateien — nutze Umgebungsvariablen. Vollständige Sicherheitspraktiken werden im Abschnitt Sicherheit oben behandelt.

Lass uns zusammenarbeiten

Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (Custom Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io