← Zurück zur Übersicht
1. Juli 2026

Wenn der Agent altert: Der Lebenszyklus selbstgebauter KI-Agenten

Selbstgebaute KI-Agenten sind Code – also haben sie einen Lebenszyklus. Warum Reife dosieren heißt statt maximal ausbauen, und warum kein Release-Prozess einen Agenten deterministisch macht.

KI-AgentenAgentic AILebenszyklusGovernanceQualitätssicherung

Ein früherer Artikel dieser Reihe hat den Befund festgehalten: Selbstgebaute KI-Agenten – der Testfall-Ersteller, der Doku-Agent, der Analyse-Agent – sind keine persönlichen Einstellungen, sondern Code-Bestandteile, und gehören versioniert, gereviewt und abgesichert wie anderer Code. Wenn das stimmt, folgt daraus eine Frage, die bisher unterbelichtet blieb: Code wird nicht nur eingecheckt. Er bekommt Releases, wird wiederverwendet, altert und wird ausgemustert. Hat ein selbstgebauter Agent denselben Lebenszyklus?

Die Antwort ist ja – aber in der Tiefe, die zu ihm passt. Ein Wegwerf-Helfer, den eine Person eine Woche nutzt, braucht keinen Release-Prozess. Ein Agent, der teamübergreifend in Produktion läuft, schon. Dieser Artikel geht den Lebenszyklus Phase für Phase durch – Release, Wiederverwendung, Eval-Gate, Weiterentwicklung, Ausmusterung – und prüft jede Phase an derselben Frage: Rechtfertigen Skalierung, Risiko und Lebensdauer diese Tiefe? Vier Vorbehalte ziehen sich durch – und sie gelten unabhängig von der gewählten Tiefe.

Releases und Versionieren: Nummern kommunizieren Absicht, nicht Verhalten

Bei Agenten entstehen Releases oft unbemerkt. Claude Codes Plugin-Marketplaces machen das sichtbar: Setzt man im Plugin kein version-Feld, wird der Commit-Hash zur Version – jeder Push ist faktisch ein Release.1 Wer das nicht will, vergibt explizite Versionen. Beim Model Context Protocol ist diese Disziplin sogar Pflicht: Der Versions-String eines veröffentlichten MCP-Servers muss eindeutig und nach Veröffentlichung unveränderlich sein, Versionsbereiche sind verboten, semantische Versionierung wird empfohlen – wobei die Registry selbst noch im Preview-Stadium ist.2 Für Prompts und Agenten-Anweisungen bieten Prompt-Management-Werkzeuge Vergleichbares: LangSmiths Prompt Hub legt bei jedem Speichern einen Commit mit Hash an und kennt verschiebbare Tags sowie reservierte staging- und production-Umgebungen, zwischen denen man eine Version ohne Code-Änderung hochstuft.3 Anbieter wie PromptLayer oder Braintrust werben mit Versionierung und Rollback.4

Hier kommt der erste Vorbehalt. Semantische Versionierung verspricht, dass ein „Patch” verhaltensneutral ist. Bei Prompts gilt das nicht: In einer Untersuchung lieferte ein verbreitetes Modell selbst bei Temperatur 0 in rund 24 Prozent der Läufe abweichende Ausgaben, und schon minimale Textänderungen – also genau das, was ein Patch wäre – trieben die Divergenz stark nach oben.5 Zwei Präzisierungen gehören dazu, sonst verselbständigt sich die Zahl: Sie ist stark task- und modellabhängig (von nahezu deterministisch bis stark schwankend), und ein Teil des Nicht-Determinismus ist ein technisches Nebenprodukt der Batch-Verarbeitung, das sich mit batch-invarianten Rechenkernen sogar vollständig beseitigen lässt – die Outputs werden dann bitgenau reproduzierbar, zulasten des Durchsatzes.6 Fürs Versionieren ändert das nichts an der Kernaussage: Eine Versionsnummer kann die Absicht kommunizieren („Major = ich erwarte Inkompatibilität, etwa durch Modell- oder Schema-Wechsel”), aber ohne teuer erkauften Determinismus ist sie keine Garantie über das Verhalten. Das ist die phasenspezifische Zuspitzung des Satzes „versionierbar ist das Setup, nicht der Output”.

Wiederverwenden: Kataloge sind nützlich – oder werden Friedhöfe

Die nächste Phase ist Wiederverwendung statt Neubau. Die Plattformen drängen genau dorthin. AWS begründet seine Agent Registry damit, dass Teams Agenten, Werkzeuge und Skills „entdecken, teilen und wiederverwenden” sollen, statt Vorhandenes neu zu bauen; Einträge sind versioniert und lassen sich ausmustern, die Registry begleitet einen Agenten „bis zur eventuellen Stilllegung” – noch als Preview in wenigen Regionen.7 Microsoft hat mit Agent 365 seit Mai 2026 eine zentral verwaltete Ebene allgemein verfügbar gemacht: Agenten durchlaufen Einreichung und Admin-Freigabe, bevor sie im internen Store erscheinen.89 Für kleine Teams ist das Pendant der Aufstieg eines Claude-Code-Plugins „vom persönlichen Setup zum Org-Standard”.1

Der zweite Vorbehalt: Ein Katalog nützt nur, wenn er gepflegt und genutzt wird – sonst verwaist er. Das Muster ist aus dem Developer-Portal-Umfeld bekannt: Kataloge wie Backstage entfalten ihren Nutzen nur mit aktiver Pflege und interner Verbreitung; ohne das bleibt die Verbreitung niedrig, und zwar nicht aus technischen, sondern aus organisatorischen Gründen.10 Aus dem API- und Inner-Source-Umfeld ist derselbe Mechanismus lange dokumentiert: solide Artefakte, die niemand findet, weil Doku und Kümmerer fehlen, und wo nur ein Team ein Interesse hat, bringt Wiederverwendung ohnehin nichts.1112 Ein Wiederverwendungskatalog lohnt also erst ab mehreren beteiligten Teams und nur mit gepflegter Auffindbarkeit.

Und er hat einen Preis, den die Katalog-Werbung selten nennt: Wiederverwendung über eine proprietäre Plattform tauscht Neubau-Kosten gegen Lock-in-Kosten. Genau die empfohlenen Registries sind herstellergebundene Orchestrierungs- und Store-Schichten; Anbieterbindung gilt als strategisches Wechselhemmnis, das man vor der Plattformwahl bewerten sollte, und bei langlebigen Agenten kommt – so die naheliegende Zuspitzung – ein „Verhaltens-Lock-in” aus angesammeltem Kontext hinzu, der sich nicht ohne Weiteres exportieren lässt.13 Das bricht die These nicht – aber Wiederverwendung ist ein Trade-off, kein Selbstläufer.

Eval-gated Releases: das Gate begrenzt das Risiko, es beseitigt es nicht

Wird ein Agent risikoreicher, koppelt man sein Release an eine Evaluation: Erst wenn definierte Tests bestehen, geht er live. Die Werkzeuge dafür sind reif genug. Das quelloffene promptfoo bricht über eval --fail-on-error eine CI-Pipeline ab und integriert sich in gängige CI-Systeme.14 Braintrust positioniert Evaluation als Voraussetzung fürs Deployment und postet Score-Vergleiche bei jedem Pull Request.15 LangSmith verbindet Versionierung mit gestaffelter Hochstufung von staging nach production.3

Der dritte Vorbehalt: Das Gate ist selbst fehlbar und teuer. Evaluationen, die ein zweites Modell als Bewerter einsetzen, kosten ein Vielfaches klassifikatorbasierter Verfahren – Größenordnungen vom 50- bis 500-Fachen werden berichtet –, und solche Bewerter sind verzerrt und mit sich selbst uneinig.16 Wie groß dieser blinde Fleck wird, zeigt eine aktuelle Untersuchung an einem produktiv eingesetzten mehrstufigen Agenten: Der eingebaute LLM-Prüfer erkannte nur zwei von neun Fehlertypen, und in 100 Durchläufen, in denen Menschen 23 einzelne Defekte bestätigten, schlug das automatische Gate kein einziges Mal an. Das Fazit der Autoren: Ein solcher Prüfer fängt bestenfalls die gröbsten Rückschritte ab, ersetzt aber keine menschliche Prüfung.17 Ein Eval-Gate begrenzt Risiko also, statt es zu beseitigen. Tragfähig wird es nur mit billigen, harten deterministischen Vor-Gates zuerst, gezielten semantischen Kriterien danach und einem klaren Kostenbudget – dasselbe Prinzip der Verhältnismäßigkeit, das schon für die Eval-Empfehlung der Reihe galt.

Weiterentwickeln: geteilte Artefakte bringen Wartungslast mit sich

Ein wiederverwendeter Agent bleibt nicht stehen. Andere Teams steuern Änderungen bei, jemand muss dafür verantwortlich sein, und äußere Veränderungen – ein Modell- oder Infrastruktur-Update – erzwingen immer wieder eine Neubewertung. Wer teilt, übernimmt Wartungslast: Eine Untersuchung von gut 31.000 öffentlich geteilten Skills fand bei rund 26 Prozent mindestens eine Schwachstelle – hier nicht als Sicherheits-, sondern als Pflegeargument zu lesen, denn ungepflegte geteilte Artefakte verfallen.18 Das Muster ist aus dem Ökosystem bekannt: Die meisten MCP-Server und Skills sind Solo-Projekte, und ein Solo-Maintainer, der das Interesse verliert, hinterlässt ein verwaistes, aber weiter installiertes Artefakt.19 Und Weiterentwicklung schafft Übertragbarkeitsprobleme: Erweiterte Agent-Felder eines Werkzeugs (etwa für sequentielle Übergaben) werden von anderen Werkzeugen nicht zwingend gelesen, eine Definition lässt sich also nicht vollständig zwischen den Ökosystemen übertragen.20 Wo der zugrunde liegende Modellstand driftet, ist das kein einmaliges Ereignis, sondern der wiederkehrende Anlass, erneut zu evaluieren.

Ausmustern: geordnet – oder von außen erzwungen

Agenten werden abgeschaltet, geordnet oder ungeordnet – meist ungeordnet: Nur rund ein Fünftel der Organisationen hat überhaupt einen formalen Prozess, um einen KI-Agenten außer Dienst zu stellen.21 Das ist nicht nur eine Ordnungsfrage. Ein Agent ist eine handelnde Dienstidentität mit eigenen Zugriffsrechten; fällt der menschliche Verantwortliche weg, läuft er als „verwaister” Dienst mit intakten Zugriffen weiter – ein offenes Sicherheitsleck, kein sauber abgeschlossener Vorgang. Ausmustern ist damit auch ein Sicherheitsthema.

Reife Lebenszyklen kennen deshalb einen Stilllegungs-Status: Die MCP-Registry markiert Server als active, deprecated oder deleted.222 Als Vorbild taugt die Modell-Deprecation der Anbieter selbst – Anthropic staffelt von Active über Legacy und Deprecated bis Retired, mit mindestens 60 Tagen Vorlauf vor der Abschaltung bei aktiver Nutzung, und sagt zu, die Gewichte ausgemusterter Modelle zu erhalten.2324 Microsoft Agent 365 lässt inaktive Agenten über konfigurierbare Regeln automatisch auslaufen und blockiert als riskant markierte; AWS erlaubt das Ausmustern nicht mehr genutzter Einträge.8257

Der vierte Vorbehalt liegt genau hier: Die eigene Deprecation-Politik konkurriert mit erzwungener Ausmusterung von außen. Das ist keine Theorie – wer im Frühjahr 2026 ein Modell in einem Agenten fest an eine Version gebunden hatte, musste zusehen, wie Anthropic Claude Sonnet 4 und Opus 4 zum 15. Juni 2026 abschaltete.26 Ein abgeschaltetes Modell zwingt zum Re-Release, ob es in die eigene Planung passt oder nicht.

Wie viel davon ist 2026 schon Alltag?

Wenig, ehrlich gesagt – jedenfalls als gelebter End-to-End-Lebenszyklus. Das MCP-Ökosystem selbst ist längst groß, aber die Governance drumherum ist jung: Die genannten Registries sind teils kaum einen Monat alt oder ausdrücklich als Vorschau markiert. Die Adoptionslage dämpft zusätzlich: Die Mehrheit der KI-Pilotprojekte erreicht laut Branchenauswertungen nicht die Produktion – eine viel zitierte Schätzung nennt rund 88 Prozent, bezieht sich aber auf KI-POCs allgemein, nicht speziell auf Agenten; nur etwa ein Drittel der Organisationen betreibt überhaupt einen Agenten produktiv, mit großer Spreizung je Branche.2728

Bemerkenswert ist, was Gartner als Grund benennt. In einer Prognose vom Mai 2026 heißt es, bis 2027 würden rund 40 Prozent der Unternehmen Agenten zurückstufen oder ausmustern – nicht trotz, sondern wegen einheitlicher, undifferenzierter Governance: Wer jeden Agenten gleich schwer behandelt, erstickt die unkritischen und kontrolliert die kritischen zu schwach.29 Das ist kein Argument gegen den Lebenszyklus, sondern der stärkste Beleg für seine Dosierung. In dieselbe Richtung zeigt, dass zu strenge Vorgaben den Einsatz in die Schatten-KI treiben.30 Positiv stimmt immerhin ein erster empirischer Hinweis: Repositories mit einer gepflegten geteilten Anweisungsdatei zeigten in einer kleinen Studie spürbar kürzere Laufzeiten und weniger Token-Verbrauch – eine Korrelation aus zehn Repositories, kein Wirkungsnachweis.31

Fazit: Welche Lebenszyklus-Tiefe braucht dieser Agent?

Die Leitfrage ist nicht „Welcher Lebenszyklus?”, sondern „Wie viel davon braucht dieser Agent?” – beantwortet entlang von vier Achsen:

Eine Randbedingung hebt diese Freiheit allerdings punktuell auf: Regulatorik. Fällt der Einsatzzweck unter die Hochrisiko-Einstufung des EU AI Act, sind ab dem 2. August 2026 automatisches Event-Logging über den Lebenszyklus, Risikomanagement und menschliche Aufsicht gesetzlich vorgeschrieben – unabhängig von Team- oder Agentengröße.32 „Dosiert” gilt für die technische Tiefe, nicht gegen das Gesetz: Wo ein Agent eine hochriskante Funktion ausführt, ist „optional” keine Option mehr.

Wenn der Agent Code ist, hat er einen Lebenszyklus. Aber Reife heißt nicht, jede Phase maximal auszubauen, sondern die Tiefe zu wählen, die dem Agenten angemessen ist. Versionsnummern kommunizieren Absicht, nicht Verhalten; Kataloge brauchen Pflege, sonst werden sie Friedhöfe; Eval-Gates begrenzen Risiko, statt es zu beseitigen. Dosiert, nicht maximal – das ist der Unterschied zwischen wirksamer Steuerung und bloßer Scheinkontrolle.

Eine Warnung noch: Die Einstufung eines Agenten auf diesen Achsen ist selbst eine Governance-Entscheidung mit Eigeninteressen – das bauende Team tendiert zu „leichtgewichtig”, Security zu „schwer”. Überlässt man sie dem Erbauer allein, werden Agenten systematisch zu niedrig eingestuft – und das größte Risiko geht gerade von dem Agenten aus, den niemand ernst genug genommen hat. Bei bereichsübergreifenden Agenten gehört diese Entscheidung deshalb an eine benannte, zentrale Stelle – nicht allein an den, der den Agenten baut.

Was der Lebenszyklus nicht kann. Egal wie sauber ein Agent versioniert, katalogisiert und eval-gated ist – deterministisch wird er dadurch nicht. Der Lebenszyklus begrenzt den Nicht-Determinismus, er hebt ihn nicht auf: Zwei identische Läufe können auseinandergehen, und kein Release-Prozess ändert daran etwas. Das hat eine unbequeme Konsequenz. Ein solcher Agent entlastet den Anwender von Arbeit – macht seine Fachkenntnis aber nie überflüssig. Wer die Ausgabe eines nicht-deterministischen Agenten verantwortet, muss sie beurteilen können, und dafür braucht er genau das Wissen, das der Agent scheinbar überflüssig macht. Der Lebenszyklus verschiebt die Frage von „Können wir dem Agenten vertrauen?” zu „Können wir seine Ergebnisse fachlich prüfen?” – und die zweite beantwortet kein Tool, sondern eine Person.

Grenzen dieser Auswertung

Quellen

  1. Anthropic, „Create and distribute a plugin marketplace” (Plugin als versionierte Einheit; ohne version-Feld wird der Commit-SHA zur Version, jeder Push = Release), https://code.claude.com/docs/en/plugin-marketplaces, abgerufen am 2026-07-01. ↩ ↩2

  2. Model Context Protocol, „Versioning Published MCP Servers” (Versions-String MUSS eindeutig und unveränderlich; Versionsbereiche verboten; SemVer empfohlen; Registry im Preview), https://modelcontextprotocol.io/registry/versioning, abgerufen am 2026-07-01. ↩ ↩2

  3. LangChain/LangSmith, „Prompt Engineering Concepts” (Commit-Hash je Speicherung; verschiebbare Tags; reservierte staging/production-Environments), https://docs.langchain.com/langsmith/prompt-engineering-concepts, abgerufen am 2026-07-01. ↩ ↩2

  4. Braintrust (Anbieter), „Best Prompt Versioning Tools 2026” (Vendor-Übersicht zu Versionierung/Rollback, u. a. PromptLayer, Langfuse), https://www.braintrust.dev/articles/best-prompt-versioning-tools-2025, abgerufen am 2026-07-01. ↩

  5. „Quantifying non-deterministic drift in LLMs”, arXiv:2601.19934 (≈24 % abweichende Outputs bei Temperatur 0 für ein verbreitetes Modell; minimale lexikalische Änderungen erhöhen die Divergenz stark), https://arxiv.org/abs/2601.19934, abgerufen am 2026-07-01. ↩

  6. „Non-Determinism of Deterministic LLM Settings”, arXiv:2408.04667 (Übereinstimmungsraten der geparsten Antworten (TARa@10) je Modell/Task von nahe 0 % bis ~99,6 % – stark aufgabenabhängig), https://arxiv.org/abs/2408.04667; sowie Thinking Machines Lab, „Defeating Nondeterminism in LLM Inference” (2025; Hauptursache ist Batch-Varianz der Inferenz-Kernels, nicht das „Würfeln” des Modells; batch-invariante Kernels erzeugen bitgenau reproduzierbare Outputs – zu Durchsatzkosten), https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/. Beide abgerufen am 2026-07-01. ↩

  7. Amazon Web Services, „The future of managing agents at scale: AWS Agent Registry now in preview” („discover, share, and reuse … instead of rebuilding”; Einträge versioniert + deprecatebar; Lifecycle bis „eventual retirement”; Preview), https://aws.amazon.com/blogs/machine-learning/the-future-of-managing-agents-at-scale-aws-agent-registry-now-in-preview/, abgerufen am 2026-07-01. ↩ ↩2

  8. Microsoft, „Microsoft Agent 365 now generally available” (GA seit 2026-05-01; Auto-Expiry inaktiver Agenten, Blockierung riskanter Agenten), https://www.microsoft.com/en-us/security/blog/2026/05/01/microsoft-agent-365-now-generally-available-expands-capabilities-and-integrations/, abgerufen am 2026-07-01. ↩ ↩2

  9. Microsoft Learn, „Share and manage agents built with Microsoft 365 Copilot” (Einreichung → Admin-Freigabe → interner Agent Store), https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/agent-builder-share-manage-agents, abgerufen am 2026-07-01. ↩

  10. getDX, „How Spotify’s Backstage drives internal adoption” (Developer-Portale/Kataloge entfalten ihren Nutzen v. a. mit aktiver Pflege und internem „Vertrieb”; Adoption ist ein organisatorisches, kein technisches Problem), https://getdx.com/blog/spotify-backstage/, abgerufen am 2026-07-01. (Interessenlage: getDX ist im Developer-Portal-Markt aktiv; hier nur qualitativ als Analogie verwendet.) ↩

  11. DigitalAPI, „Why Internal APIs Go Unused” (der „stille API-Friedhof”: Adoption scheitert organisatorisch an Discovery/Doku, nicht technisch), https://www.digitalapi.ai/blogs/why-internal-apis-go-unused-strategies-to-boost-adoption, abgerufen am 2026-07-01. ↩

  12. InfoQ, „Inner Source: Adopting Open Source Practices in Organizations” (kulturelles/governance-seitiges Scheitern; ohne mehrere Stakeholder kein Nutzen), https://www.infoq.com/articles/inner-source-open-source-development-practices/, abgerufen am 2026-07-01. ↩

  13. Kai Waehner, „Enterprise Agentic AI Landscape 2026: Trust, Flexibility and Vendor Lock-in” (2026-04; rahmt Anbieterbindung als strategisches Risiko, das vor der Vendor-Wahl zu bewerten ist – „data gravity”/„ecosystem entanglement”), https://www.kai-waehner.de/blog/2026/04/06/enterprise-agentic-ai-landscape-2026-trust-flexibility-and-vendor-lock-in/, abgerufen am 2026-07-01. (Der „Verhaltens-Lock-in” aus akkumuliertem Agenten-Kontext ist eine Zuspitzung des Autors dieses Beitrags, keine Aussage der Quelle.) ↩

  14. promptfoo, „CI/CD Integration” (eval --fail-on-error bricht die Pipeline ab; Integration in gängige CI-Systeme; Open Source), https://www.promptfoo.dev/docs/integrations/ci-cd/, abgerufen am 2026-07-01. ↩

  15. Braintrust (Anbieter), „Evaluate” (Evaluation als Voraussetzung fürs Deployment; Regressionserkennung vor Produktion, Score-Vergleich je Pull Request), https://www.braintrust.dev/docs/evaluate, abgerufen am 2026-07-01. ↩

  16. Arize (Anbieter), „The Definitive Guide to LLM Evaluation” (LLM-Judge-Evaluationen um Größenordnungen teurer als klassifikatorbasierte; Bewerter verzerrt/inkonsistent), https://arize.com/llm-evaluation/, abgerufen am 2026-07-01. ↩

  17. Zhang, Wang, Lei, „Catching One in Five: LLM-as-Judge Blind Spots in Production Multi-Turn Agents”, arXiv:2606.10315 (2026-06; eingebauter LLM-Prüfer erkannte 2 von 9 Fehlertypen; flaggte 0 von 100 Runden, in denen Menschen 23 Defekte bestätigten; „a regression floor, not a substitute for human review”), https://arxiv.org/abs/2606.10315, abgerufen am 2026-07-01. ↩

  18. „Agent Skills in the Wild: An Empirical Study”, arXiv:2601.10338 (Audit von 31.132 Skills; ~26,1 % mit mindestens einer Schwachstelle), https://arxiv.org/abs/2601.10338, abgerufen am 2026-07-01. ↩

  19. Zencoder (Anbieter), „AI Agent Survival Guide, Part 3” (viele MCP-Server/Skills sind Solo-Projekte; „ghosted maintainer”-Muster → verwaiste, aber weiter installierte Artefakte), https://zencoder.ai/blog/ai-agent-survival-guide-part-3-that-mcp-server-you-just-installed, abgerufen am 2026-07-01. ↩

  20. Microsoft, „Custom agents in VS Code” (erweiterte Felder wie handoffs werden nicht von allen Werkzeugen gelesen; Definitionen nur teilweise tool-übergreifend portabel), https://code.visualstudio.com/docs/agent-customization/custom-agents, abgerufen am 2026-07-01. ↩

  21. Cloud Security Alliance / Token Security, „Autonomous but Not Controlled” (Umfrage, 418 Befragte, erhoben Jan 2026: nur ~21 % mit formalem Decommissioning-Prozess; 82 % mit unbekannten „Schatten”-Agenten), https://cloudsecurityalliance.org/artifacts/autonomous-but-not-controlled-ai-agent-incidents-now-common-in-enterprises, abgerufen am 2026-07-01. (Interessenlage: von Token Security, einem NHI-Security-Anbieter, beauftragt.) ↩

  22. Stacktree, „What changed in the 2026-07 MCP specification” (Status-Werte active/deprecated/deleted; Sekundärbeleg), https://stacktr.ee/blog/mcp-2026-spec-changes, abgerufen am 2026-07-01. ↩

  23. Anthropic, „Model deprecations” (Lebenszyklus Active → Legacy → Deprecated → Retired; ≥ 60 Tage Vorlauf bei aktiver Nutzung; Retirement Claude Sonnet 4 / Opus 4 zum 15.06.2026), https://platform.claude.com/docs/en/about-claude/model-deprecations, abgerufen am 2026-07-01. ↩

  24. Anthropic, „Commitments on model deprecation and preservation” (Erhalt der Gewichte ausgemusterter Modelle), https://www.anthropic.com/research/deprecation-commitments, abgerufen am 2026-07-01. ↩

  25. Microsoft Learn, „Governance and Lifecycle actions for agents” (M365 Admin Center) (regelbasiertes Lebenszyklus-Management: Regeln werden konfiguriert, die Ausführung – u. a. Ablauf inaktiver Agenten – erfolgt automatisch), https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-actions, abgerufen am 2026-07-01. ↩

  26. Anthropic, „Model deprecations” (Retirement von Claude Sonnet 4 und Opus 4 zum 15. Juni 2026), https://platform.claude.com/docs/en/about-claude/model-deprecations; Übersicht: endoflife.date, „Claude”, https://endoflife.date/claude. Beide abgerufen am 2026-07-01. ↩

  27. Gartner, „Hype Cycle for Agentic AI 2026” (agentische KI nahe dem „Peak of Inflated Expectations”), https://www.gartner.com/en/articles/hype-cycle-for-agentic-ai, abgerufen am 2026-07-01. ↩

  28. Die viel zitierte „88 %“-Schätzung (Pilots erreichen keine Produktion) stammt aus dem IDC/Lenovo CIO Playbook 2025 und bezieht sich auf KI-POCs allgemein, nicht agentenspezifisch: CIO.com, „88% of AI pilots fail to reach production”, https://www.cio.com/article/3850763/88-of-ai-pilots-fail-to-reach-production-but-thats-not-all-on-it.html. Weitere Adoptionsdaten (~⅓ produktiv, Branchenspreizung; Eval-Lücken und Governance-Reibung als Top-Blocker): Joget, „AI Agent Adoption in 2026”, https://joget.com/ai-agent-adoption-in-2026-what-the-analysts-data-shows/. Abgerufen am 2026-07-01. ↩

  29. Gartner, Pressemitteilung vom 2026-05-26, „Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure” (Prognose: bis 2027 stufen ~40 % der Unternehmen Agenten zurück oder mustern sie aus; Ursache uniforme statt differenzierte Governance), https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure; Aufbereitung: CIO.com, „Many autonomous agents doomed by governance failures” (29.05.2026), https://www.cio.com/article/4178628/many-autonomous-agents-doomed-by-governance-failures.html. Beide abgerufen am 2026-07-01. (Direktabruf der Gartner-PM bot-geblockt; Aussage und Datum über die CIO-Aufbereitung bestätigt.) ↩

  30. CIO, „Shadow AI: the hidden agents beyond traditional governance” (zu strenge Vorgaben treiben Nutzung in die Schatten-KI), https://www.cio.com/article/4083473/shadow-ai-the-hidden-agents-beyond-traditional-governance.html, abgerufen am 2026-07-01. ↩

  31. Lulla u. a., „On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents”, arXiv:2601.20404 (≈ −28,6 % Median-Laufzeit, ≈ −16,6 % Output-Token; 10 Repositories/124 PRs – Korrelation, kleine Stichprobe, kein Wirkungsnachweis), https://arxiv.org/abs/2601.20404, abgerufen am 2026-07-01. ↩

  32. Europäische Union, AI Act – Art. 12 (automatisches Event-Logging über den Lebenszyklus), Art. 19 (Aufbewahrung der Logs, i. d. R. ≥ 6 Monate) und Art. 26 (Betreiberpflichten); die Pflichten für Hochrisiko-Systeme gelten ab dem 2. August 2026, https://artificialintelligenceact.eu/article/12/ · https://artificialintelligenceact.eu/article/19/ · https://artificialintelligenceact.eu/article/26/, abgerufen am 2026-07-01. ↩

Transparenzhinweis: Dieser Beitrag wurde KI-gestützt erstellt und vor Veröffentlichung redaktionell geprüft.

© 2026 ITBM – IT-Beratung Million http://localhost:4321/blog/ki-agenten-lebenszyklus/