Agent as Code 2026: Warum KI Agenten keine neue Plattform brauchen

Rund um KI Agenten wächst gerade eine neue Tool Landschaft: Agent Runtime, Agent Governance, Agent Observability, Agent Deployment. Ein LinkedIn Post hat diese Woche eine einfache Frage gestellt: Warum erfinden wir das alles neu? Die These dahinter heißt Agent as Code. Agenten werden gebaut, versioniert und ausgeliefert wie jede andere Software. Wir sehen das genauso. Mit einer Ergänzung, die in der Debatte fehlt.

Alte Fragen mit neuem Etikett

Runtime, Deployment, Secrets, Rollbacks, Monitoring, Ownership. Streicht das Wort Agent aus der Liste. Übrig bleiben Fragen, die Teams seit Jahren mit Pipelines, Git und Monitoring lösen. Neu ist nur ein kleiner Teil.

Frage	Gibt es schon	Was beim Agent dazukommt
Deployment	CI/CD mit GitHub Actions oder GitLab CI	Prompts und Rules Dateien gehören ins Release
Versionierung und Rollback	Git und GitOps	Auch die Modellversion wird festgeschrieben
Secrets	Secret Management der Pipeline	Der Agent bekommt nur die Keys für seine Aufgabe
Monitoring	Sentry und Grafana	Tool Aufrufe und Kosten pro Lauf mitloggen
Ownership	Codeowner und Teams	Ein Mensch pro Agent, der für das Ergebnis geradesteht

Die Prinzipien von OpenGitOps passen fast eins zu eins: Der gewünschte Zustand ist deklarativ beschrieben, versioniert und wird automatisch abgeglichen. Ein Agent mit Auftrag, Tools und Rechten ist genau so ein Zustand. Er gehört in dieselbe Pipeline wie euer restlicher Code.

Was Agent as Code im Repository bedeutet

Alles, was einen Agenten ausmacht, liegt neben dem Code. Kein Klickpfad in einer Plattform Oberfläche, den später niemand mehr nachvollziehen kann.

• Auftrag: Welche Aufgabe erledigt der Agent, und wann hört er auf?
• Tools und Rechte: Was darf er lesen, was darf er schreiben?
• Modell: Welches Modell in welcher Version, lokal oder bei einem Hoster in der EU?
• Quality Gates: Welche Prüfungen muss jede Änderung bestehen?
• Owner: Wer ist verantwortlich?

Ein vereinfachter Steckbrief kann so aussehen. Das ist kein Standard Format, nur ein Beispiel für die Idee:

agent: rechnungen-vorpruefen
owner: team-buchhaltung
capability: Eingangsrechnungen auf Vollständigkeit prüfen
model: llama (lokal über Ollama)
tools:
  - read: rechnungen_eingang
  - write: pruefnotizen
verboten:
  - zahlung_freigeben
gates:
  - evals: rechnungen_testfaelle
  - review: Mensch bei jeder Abweichung

Mit so einem Steckbrief sieht jeder im Merge Request, was sich ändert. Bekommt der Agent ein neues Recht? Das fällt im Review auf. Für Coding Agents arbeiten wir genauso: Rules Dateien und Berechtigungen liegen bei uns im Repository. Wie das im Alltag aussieht, beschreiben die Agentic Coding Patterns. Die Pipeline dazu bauen wir im GitLab CI/CD Pipeline Setup.

Wo Agenten sich von Microservices unterscheiden

Bis hierhin trägt die These. Drei Dinge kennt eure Plattform aber trotzdem nicht.

Gleicher Input, anderes Ergebnis

Ein Microservice liefert bei gleichem Input dasselbe Ergebnis. Ein Agent nicht. Klassische Unit Tests reichen deshalb nicht. Ihr braucht Evals mit echten Testfällen, die bei jedem Release laufen. Welche Tests mit Agents wichtiger werden, zeigt Die Testpyramide für KI Agents.

Daten werden zu Befehlen

Ein Microservice führt aus, was im Code steht. Ein Agent liest Mails, Dokumente und Webseiten. Steht darin eine versteckte Anweisung, kann sie den Agenten umsteuern. Die OWASP Top 10 für LLM Anwendungen führen Prompt Injection deshalb ganz oben.

Der Agent wählt seine Werkzeuge selbst

Ein Service ruft die APIs auf, die im Code stehen. Ein Agent entscheidet zur Laufzeit, welches Tool er nimmt. Jedes Recht, das er hat, wird er irgendwann nutzen. OWASP nennt das Risiko Excessive Agency. Die Antwort ist alt: so wenig Rechte wie möglich, und eine menschliche Freigabe bei allem, was sich nicht rückgängig machen lässt.

Diese drei Punkte brauchen neue Guardrails. Eine neue Plattform brauchen sie nicht. Warum Agents mehr Leitplanken brauchen als Menschen, steht in 800.000 Zeilen Tests gelöscht.

Bedeutung ist Chefsache

Der stärkste Gedanke der Debatte betrifft keine Technik. Was ein Agent im Unternehmen tun soll, entscheidet kein Developer allein. Vier Fragen gehören vor jede Zeile Code:

• Aufgabe: Welche Arbeit im Unternehmen übernimmt der Agent?
• Daten: Welche Systeme darf er lesen, welche verändern?
• Grenze: Welche Entscheidung bleibt immer beim Menschen?
• Verantwortung: Wer steht für das Ergebnis gerade?

Der fachliche Kontext ist dabei kein neues Konzept. Domain Driven Design nennt ihn Bounded Context. Ein Agent ohne klaren Kontext wird schnell zum Generalisten mit zu vielen Rechten. Warum KI Führungssache ist, beschreibt KI Beauftragter im Unternehmen. Wer die Regeln festhalten will, startet mit einer KI Nutzungsrichtlinie. Fehlen diese Antworten, bauen Teams ihre Agenten trotzdem, nur ohne Absprache. Das Ergebnis ist Schatten KI im Unternehmen.

Deshalb sitzen im KI Workshop am Hockenheimring Führung, Fachabteilungen und Developer am selben Ort. Die einen klären, was ein Agent tun soll. Die anderen bauen die Leitplanken, in denen er es sicher tut.

Fazit

Agent as Code ist der richtige Weg. Eure Pipeline, euer Git und euer Monitoring tragen auch Agenten. Neu sind Evals, Schutz vor Prompt Injection und enge Rechte. Und eine Frage, die vor jeder Technik steht: Welche Aufgabe soll der Agent übernehmen, und wer steht dafür gerade?

Häufige Fragen zu Agent as Code

Was bedeutet Agent as Code 2026?

Agent as Code heißt: Auftrag, Prompts, Tools, Rechte, Modell und Quality Gates eines KI Agenten liegen versioniert im Repository. Änderungen laufen durch Review und Pipeline wie jeder andere Code. So bleibt nachvollziehbar, was der Agent darf und wer ihn verantwortet.

Brauchen KI Agenten 2026 eine eigene Plattform?

Meist nicht. Deployment, Secrets, Rollbacks und Monitoring lösen bestehende Pipelines bereits. Ergänzen müsst ihr Evals für nicht deterministische Ergebnisse, Schutz vor Prompt Injection und enge Berechtigungen für jedes Tool.

Welche Dateien gehören zu einem Agenten ins Repository?

Der Auftrag mit Abbruchkriterium, die Prompts oder Rules Dateien, die Liste der erlaubten Tools und Rechte, die Modellversion und die Testfälle für Evals. Dazu ein Owner, der für das Ergebnis verantwortlich ist.

Wie testet man KI Agenten?

Mit Evals: echte Testfälle, deren Ergebnis bei jedem Release geprüft wird. Dazu kommen klassische Tests für den Code rund um den Agenten und eine menschliche Freigabe für alles, was sich nicht rückgängig machen lässt.

Wem sollte ein KI Agent gehören?

Dem Team, dessen Aufgabe er übernimmt. Die Fachabteilung legt fest, was der Agent tun soll und wo seine Grenzen liegen. Developer sorgen dafür, dass er diese Grenzen technisch einhält.