🐳 AI Tinkerers Paris: Agentische Workflows mit Docker – hin zu autonomen, sicheren und orchestrierten Systemen

der 22. April 2026

Bei diesem von GitGuardian organisierten und von Docker gesponserten Meetup stellten mehrere Redner ihre Vision von modernen agentenbasierten Systemen vor.

Das Ziel ist klar: von einfachen KI-Assistenten zu echten autonomen Agenten zu gelangen, die in der Lage sind, in der Produktion zu handeln, zusammenzuarbeiten und Aufgaben auszuführen.

🎤 Einführung - Sicherheit & Kontext (GitGuardian)

Der Abend beginnt in den Pariser Büros von GitGuardian, was uns an einen Punkt erinnert, der in Diskussionen über KI-Agenten oft unterschätzt wird: Bevor wir überhaupt über Autonomie sprechen, müssen wir über Zugriffssicherheit sprechen.

Die Botschaft ist klar: Geheimnisse sind allgegenwärtig: API-Schlüssel, JWTs, Tokens, Zugangsdaten oder jegliche Informationen, die Zugriff auf Ressourcen, Dienste oder Infrastrukturen ermöglichen. In einer Welt, in der Anwender zunehmend mit Code, Repositories, Kollaborationswerkzeugen oder vernetzten Systemen interagieren, wird die Erkennung und Kontrolle dieser Geheimnisse zu einem entscheidenden Faktor.

GitGuardian ist genau in diesem Bereich positioniert: Es hilft Entwicklern, Sicherheitsteams und Infrastrukturverantwortlichen dabei, offengelegte Geheimnisse in ihren Umgebungen zu identifizieren, seien es Git-Repositories, Kollaborationsplattformen wie Slack oder andere Oberflächen, auf denen sensible Informationen durchsickern können.

Aus dieser Einleitung ergibt sich ein weiteres interessantes Signal: Agentensicherheit ist kein theoretisches Thema mehr. Sie entwickelt sich zu einem konkreten Marktbedürfnis und begleitet damit eine Phase aktiven Wachstums bei GitGuardian, das nach Mitarbeitern für verschiedene Profile sucht, darunter Software-Ingenieure und KI-Ingenieure.

👉 Wichtigster Punkt:

Agenten sollten sensible Geheimnisse niemals ohne strenge Kontrollen preisgeben.

🥽 Lautsprecher

Die Qualität dieses Abends ist auch auf sein Programm zurückzuführen. Anstatt rein theoretische Profile zu präsentieren, brachte die Veranstaltung Referenten zusammen, die direkt an der Entwicklung von Werkzeugen, Laufzeitumgebungen und Infrastrukturen im Zusammenhang mit agentenbasierten Arbeitsabläufen beteiligt sind.

Sébastien Blanc – Agenten wirklich einsatzbereit machen

Sébastien Blanc, Technischer Direktor bei Sciam, präsentierte SAIL: Serverless Agentic Containers, einen verteilten, ausführungsorientierten Ansatz, bei dem Agenten nicht mehr als einfache lokale Assistenten, sondern als Workloads verstanden werden, die in einer serverlosen Umgebung ausgeführt werden können. Seine Präsentation erweitert die Diskussionen über Kubernetes, Knative und ereignisgesteuerte Architekturen um eine grundlegende Frage: Wie lassen sich robuste, skalierbare und ressourceneffiziente agentenbasierte Systeme entwickeln?

Philippe Charrière – Erforschung der Grenzen und des Potenzials winziger LLMs

Philippe Charrière, Principal Solutions Architect bei Docker, präsentierte einen Vortrag mit dem Titel „Compose and Dragons: Tiny LLMs“, der zweifellos zu den experimentellsten des Abends zählte. Sein Ansatz war besonders interessant: Er zeigte, dass kleine, lokale Modelle nicht bloß technische Kuriositäten sind, sondern als Grundlage für Multiagentensysteme dienen können, sofern ihre Speicher-, Leistungs- und Orchestrierungsbeschränkungen akzeptiert werden. Seine Arbeit verdeutlicht eine mögliche Zukunft, in der Agenten nicht nur auf große, entfernte Modelle, sondern auch auf lokale, spezialisierte und kombinierbare Bausteine zurückgreifen.

David Gageot – Vereinfachung der Agentenerstellung

David Gageot, Senior Principal Software Engineer bei Docker, sprach über Docker Agent: KI-Agenten ohne Programmierung. Sein Vortrag konzentrierte sich auf radikale Vereinfachung: die Reduzierung der Reibungsverluste zwischen der Idee eines Agenten und seiner konkreten Implementierung. Der Wert seines Vortrags liegt nicht nur im „No-Code“-Aspekt, sondern auch in der Möglichkeit, Agenten zugänglicher, deklarativer und einfacher in reale Arbeitsabläufe zu integrieren.

Guillaume Lours – Sicherung der Autonomie

Guillaume Lours, Softwareentwickler bei Docker, präsentierte Docker-Sandboxes – eines der strategisch wichtigsten Themen des Abends. Während sich viele Diskussionen über Agenten auf Modelle oder Eingabeaufforderungen konzentrieren, rückte Lours in seinem Vortrag die Laufzeitumgebung wieder in den Mittelpunkt: Damit ein Agent agieren kann, muss er isoliert, beobachtbar und steuerbar sein. Docker-Sandboxes bieten eine konkrete Lösung für Fragen der sicheren Ausführung, Netzwerkberechtigungen, Geheimnisse und Zugriffskontrolle.

Djordje Lukic – Betrachten Sie den Agenten als System, nicht als Gerät

Djordje Lukic, leitender Softwareentwickler bei Docker, präsentiert gemeinsam mit David Gageot den Docker Agent. Sein Beitrag ist bedeutsam, da er das Thema in den breiteren Kontext agentenbasierter Frameworks einordnet. Neben dem Versprechen einfach zu erstellender Agenten verfolgt er ein strukturelles Ziel: die Bereitstellung eines Frameworks, in dem Modelle, Werkzeuge, Anweisungen und Orchestrierung übersichtlich zusammengeführt werden können – basierend auf einer fundierten technischen Logik.

🧠 David Gageot - Djordje Lukic - Docker Agents - vom Assistenten zur echten Agentenlaufzeit

Der Docker-Abschnitt beginnt mit Georgi und seinem Team, die Docker Agent nicht nur als weiteren Assistenten, sondern als das, was sie selbst als „Schweizer Taschenmesser“ der Agenten-Frameworks bezeichnen, vorstellen. Die Idee ist klar: die bisherige, eher zufällige Nutzung des Modells hinter sich zu lassen und eine Logik zu entwickeln, in der KI zu einer vollwertigen Ausführungskomponente wird. Ihr Ausgangspunkt ist nicht theoretisch. Sie erklären, dass Docker seit fast zwei Jahren an diesen Themen arbeitet, insbesondere an Gordon, dem in Docker Desktop integrierten Assistenten, und dass Docker Agents intern zur Entwicklung und Verbesserung eigener Tools eingesetzt wird.

Was sofort ins Auge fällt, ist der Wunsch, Agenten konfigurierbar, zusammensetzbar und unter realen Bedingungen einsetzbar zu machen. Docker-Agenten können sich mit verschiedenen Modellen verbinden – lokal oder remote –, sich in diverse Tools integrieren lassen und, was am wichtigsten ist, sich sehr einfach in YAML beschreiben lassen, ohne systematisch eine komplexe Implementierung zu erfordern. Dies ist eine der wichtigsten Botschaften der Demo: Der Einstieg in die Agentenentwicklung beginnt nicht zwangsläufig mit einem umständlichen SDK oder einer verteilten Architektur, sondern manchmal mit einer einfachen, klaren deklarativen Definition, die nützliches Verhalten erzeugt.

Die erste Demonstration nutzt bewusst ein absurdes Szenario – einen Hacker-Agenten –, um zu zeigen, wie niedrig die Einstiegshürde ist. Mit einer Vorlage und einer Anleitung verfügt das Team bereits über einen angreifbaren Agenten. Die Demonstration wirkt unbeschwert, fast spöttisch, doch die Botschaft ist wichtig: Ein Agent benötigt keine umfangreiche Infrastruktur; er braucht primär ein klares Ausführungsframework. Darauf aufbauend kann Docker das Ganze zu etwas deutlich Ernsthafterem skalieren.

Genau das geschieht im zweiten Teil, der technisch deutlich anspruchsvoller ist. Das Team demonstriert, wie man eine bestehende API mithilfe ihrer OpenAPI-Definition mit einem Agenten verbindet. Im Beispiel handelt es sich um eine Pokémon-API – bewusst als spielerischer Ersatz für eine herkömmliche Business-API –, doch die Botschaft ist klar: In einem Unternehmensumfeld ließe sich derselbe Mechanismus nutzen, um interne Dienste, Wissensdatenbanken oder spezialisierte Tools zu verbinden. Die OpenAPI-Spezifikation wird in eine Reihe von Tools umgewandelt, und der Agent kann das System abfragen, ohne dass der Benutzer die Endpunkte direkt manipulieren muss. Nicht mehr der Mensch navigiert durch die API; die Vermittlung übernimmt der Agent.

Die Demo verdeutlicht zudem einen oft unterschätzten architektonischen Aspekt: Es geht nicht nur darum, einem Agenten Werkzeuge zur Verfügung zu stellen, sondern die richtigen. In der anschließenden Fragerunde räumte das Team ein, dass ein überlasteter Agent schnell ineffektiv wird. Selbst wenn eine OpenAPI-Spezifikation Dutzende oder gar Hunderte von Werkzeugen bereitstellt, ist es ratsam, diese stark zu filtern und nur eine für die jeweilige Aufgabe relevante Teilmenge zu verwenden. Der Kerngedanke lautet hier nicht „Mehr Werkzeuge = besserer Agent“, sondern fast das Gegenteil: Ein spezialisierter Agent arbeitet am besten mit einem begrenzten, übersichtlichen und bewusst definierten Umfang.

Der interessanteste Teil folgt mit den fortgeschritteneren Anwendungsfällen. Docker Agents beschränkt sich nicht auf einen Einzelagenten-Ansatz, der nur wenige API-Aufrufe verarbeitet. Das Team demonstriert ein mehrschichtiges System mit einem Hauptagenten, dedizierten Befehlen und Subagenten, von denen jeder seine eigene Rolle, Anweisungen, sein eigenes Modell und potenziell eigene Werkzeuge besitzt. Das interaktive Quiz und die Pokémon-Kampfsimulation veranschaulichen vor allem ein übergeordnetes Konzept: Nützliche Agentenarchitektur basiert weniger auf einem einzelnen „Superagenten“ als vielmehr auf der Orchestrierung klar getrennter Verantwortlichkeiten. Der Hauptagent koordiniert, die Subagenten führen die Befehle aus, und jeder agiert in einem klar definierten Kontext.

Die Antworten in der Fragerunde unterstreichen diesen Punkt. Docker unterscheidet insbesondere zwei Formen der Interaktion zwischen Agenten: zum einen Subagenten, die eine Aufgabe in einem neuen Kontext erhalten, zum anderen Übergabemechanismen, die den Übergang der Konversation von einem Agenten zum anderen ermöglichen. Das Team erwähnt außerdem die Möglichkeit, bestimmte Speicher- oder Aufgabenverwaltungstools zwischen mehreren Agenten zu teilen. Auch hier zeigt sich ein strukturierender Gedanke: Agentensysteme werden interessant, wenn sie nicht mehr nur konversationell, sondern organisatorisch werden. Wir bitten nicht mehr einfach ein Modell um eine Antwort, sondern verteilen die Arbeit auf mehrere spezialisierte Einheiten.

🔐 Guillaume Lours – Docker Sandboxes – Autonomie ermöglichen, ohne die Kontrolle abzugeben

Der zweite Teil ergänzt den ersten perfekt. Nachdem das Docker-Team gezeigt hat, wie man Agenten erstellt, stellt es die entscheidende Frage: Wo und wie sollen sie laufen? Hier kommt die Demonstration der Docker-Sandboxes ins Spiel. Die erste Erkenntnis ist eindeutig: Sobald ein Agent Dateien lesen, Abhängigkeiten installieren, Befehle ausführen oder auf das Netzwerk zugreifen muss, ist es unmöglich, ihn zuverlässig direkt auf dem Host-Rechner auszuführen, ohne ein extrem hohes Risiko einzugehen. Der Präsentator stellt es klar: Einem Agenten auf dem eigenen Laptop solch weitreichende Zugriffsrechte zu gewähren, ist absolut ausgeschlossen.

Dockers Lösungsvorschlag ist eine isolierte Ausführungsumgebung in Form einer Mikro-VM, die eine eigene Docker-Engine enthält und in der ein Container mit dem Agenten läuft. Dies stellt einen bedeutenden Perspektivwechsel dar. Die Herausforderung besteht nicht einfach darin, den Agenten einzuschränken, sondern ein Framework zu schaffen, das ihm im Gegenteil größere Autonomie gewährt und gleichzeitig die Möglichkeit bietet, seine Aktionen zu beobachten, zu filtern und zu unterbrechen. Ziel ist es daher nicht, den Agenten durch vollständige Blockierung unschädlich zu machen, sondern ihm genügend Freiheit zu geben, um innerhalb klar definierter Grenzen effektiv zu funktionieren.

Die Demonstration ist überzeugend: In einem einfachen Webprojekt kann der Agent selbstständig die notwendigen Abhängigkeiten installieren, Build-Befehle ausführen und Tests durchführen – selbst bei Operationen, die man auf dem eigenen Rechner nicht ohne Weiteres durchführen würde. Der entscheidende Vorteil liegt nicht nur in der technischen Isolation, sondern auch in der Transparenz. Sandboxes bieten eine Schnittstelle, über die Benutzer die laufenden Umgebungen auflisten, aktive Prozesse überprüfen, den vom Agenten generierten Netzwerkverkehr beobachten und allgemein nachvollziehen können, was dieser tatsächlich tut. Die Delegierung ist also nicht blind, sondern erfolgt innerhalb einer instrumentierten Umgebung.

Netzwerkmanagement ist wohl der überzeugendste Aspekt dieses Abschnitts. Docker demonstriert verschiedene Netzwerkrichtlinienmodi, von vollständiger Verweigerung bis hin zu einer deutlich permissiveren Offenheit, mit einer ausgewogenen Zwischenoption. Entscheidend ist dabei weniger die Bezeichnung der Modi als vielmehr die Granularität, die sie ermöglichen. Blockierter Zugriff lässt sich in den Netzwerkprotokollen der Sandbox visualisieren und anschließend explizit gewähren. Dadurch wird das Netzwerkverhalten des Agenten zu einer nachvollziehbaren und anpassbaren Richtlinie anstatt einer globalen, ein für alle Mal erteilten Berechtigung. Anders ausgedrückt: Der Zugriff auf das Web oder eine bestimmte Domain basiert nicht mehr auf implizitem Vertrauen, sondern auf einer expliziten Entscheidung.

Die gleiche Logik gilt für Geheimnisse. Auch hier verfolgt Docker einen interessanten Ansatz: Geheimnisse sind in der Umgebung des Agenten nicht einfach „sichtbar“, wie es auf einem falsch konfigurierten System der Fall wäre. Sie werden beim Erstellen der Sandbox hinzugefügt, je nach Bedarf mit einem globalen oder spezifischen Gültigkeitsbereich. Dieses Detail ist im Produktivbetrieb von entscheidender Bedeutung: Es bedeutet, dass ein Agent nicht standardmäßig alles vom Entwicklungsrechner erben sollte. Er arbeitet ausschließlich mit den Ressourcen, die ihm in seiner kontrollierten Umgebung bereitgestellt wurden. In der Praxis werden Geheimnisse dadurch zu einer explizit bereitgestellten Ressource und nicht zu einem Nebeneffekt der Benutzersitzung.

Die Port-Exposure-Demo verdeutlicht diesen Punkt. Eine Anwendung kann in der Sandbox ausgeführt werden, ohne von außen direkt sichtbar zu sein. Um darauf zugreifen zu können, muss der entsprechende Port veröffentlicht werden; wird er entfernt, existiert die Anwendung zwar weiterhin in ihrer isolierten Umgebung, ist aber von außen nicht mehr erreichbar. Auch hier demonstriert Docker eine klare Trennung zwischen Ausführung und Exposure, was in vielen übereilten Agenten-Demos fehlt.

Die Demonstration schließt mit einem besonders interessanten Anwendungsfall für moderne Arbeitsabläufe: Mehrere Agenten arbeiten am selben Quellcode, ohne sich gegenseitig zu beeinträchtigen. Der vorgestellte Ansatz basiert auf der automatischen Erstellung separater Branches oder Worktrees, sodass jeder Agent in seinem eigenen Arbeitsbereich agieren kann. Dieser Aspekt ist wichtig, da er zeigt, dass Docker den Agenten nicht nur als individuellen Assistenten, sondern auch als parallelen Akteur in einem kollaborativen Entwicklungsprozess betrachtet. Der Agent dient nicht mehr nur der Reaktion, sondern übernimmt einen Teil der Arbeit in einem kontrollierten, isolierten und potenziell parallelen Bereich.

Die implizite Schlussfolgerung dieser Sequenz ist zweifellos die nützlichste des gesamten Abends:

Das eigentliche Problem besteht nicht darin, Akteure am Handeln zu hindern, sondern darin, die Rahmenbedingungen zu schaffen, in denen sie angemessen handeln können.

Anders ausgedrückt: Sinnvolle Autonomie entsteht nicht durch blindes Vertrauen, sondern durch eine gut konzipierte Laufzeitumgebung: Isolation, differenzierte Netzwerkrichtlinien, kontrollierte Einbindung von Geheimnissen, Beobachtbarkeit und Trennung von Arbeitsbereichen. Genau hier liegt wahrscheinlich die größte Stärke des Docker-Ansatzes für Architekturen wie Darkwood, Flow oder jede andere Architektur, die Agenten von der Demo- in die Systemphase überführen möchte.

🧠 Philippe Charrière – Lokale Modelle, zwischen Versprechen und Erinnerungsdruck

Mit Philippe Charrières Präsentation verlagerte sich der Fokus des Abends von agentenbasierten Frameworks hin zu einem deutlich konkreteren Thema: den tatsächlichen Kosten für die lokale Ausführung eines Modells. Seine Präsentation hatte den Verdienst, das Thema wieder auf die Ebene von Rechner, Arbeitsspeicher und technischen Kompromissen zurückzuführen. Hinter der Begeisterung für „kleine Modelle“ verbarg sich seine einfache Beobachtung: Ja, lokale Modelle sind interessant, aber sobald man mehr als eine minimale Demo realisieren möchte, wird die Ressourcenknappheit, insbesondere auf Macs, sofort zum dominierenden Faktor.

Der Hauptgrund für die Probleme liegt seiner Erfahrung nach weniger in Docker selbst als vielmehr im Speicherdruck, der durch die Templates entsteht. Auf seinem Rechner – einem MacBook Pro M2 Max mit 32 GB RAM – scheint ein Template theoretisch noch zu funktionieren, wird aber in der Praxis unbrauchbar, sobald es tatsächlich aufgerufen wird. Philippe betont einen wichtigen Punkt: Eine Kompatibilitätsschätzung ist keine Garantie für eine komfortable Nutzung. Ein Template startet möglicherweise, antwortet einmal und bringt den Rechner dann schnell an seine Grenzen, sobald die Last steigt. Fügt man ein zweites, anderes Template oder einfach weitere Anfragen hinzu, verschlechtert sich die Situation noch schneller. Seine praktische Erfahrung ist fast schon brutal einfach: Was er lange Zeit für ein Docker-Problem hielt, war in Wirklichkeit ein Speicherproblem.

Seine Demonstration basierte auf einem relativ einfachen Stack: Docker Model Runner, Docker Compose und einer Reihe lokaler Modelle, die als Bausteine für ein größeres System dienten. In der anschließenden Fragerunde erklärte er, dass Docker Model Runner aktuell auf Engines wie llama.cpp und vLLM setzt, mit der Möglichkeit einer zukünftigen Integration mit MLX. Er unterschied zudem klar zwischen verschiedenen Anwendungsfällen: vLLM schien besser für den Produktiveinsatz geeignet, während llama.cpp weiterhin relevanter für lokale oder experimentelle Zwecke sei. Der Kernpunkt ist, nicht ein einziges, übergreifendes Backend zu propagieren, sondern zu erkennen, dass die Modelllaufzeit selbst ein architektonisches Problem darstellt.

Die Präsentation ist jedoch nicht nur eine einfache Warnung vor RAM. Philippe demonstriert auch, was trotz dieser Einschränkungen möglich ist, vorausgesetzt, man ist bereit, mit kleinen, spezialisierten und lokalen Modellen zu arbeiten. Sein Beispiel ist ein textbasiertes Spielprojekt, eine Art Dungeon Crawler, der von mehreren Komponenten gesteuert wird. Diese Wahl mag spielerisch wirken, dient aber in erster Linie dazu, eine interessante Architektur zu präsentieren: ein MCP-Server zur Verwaltung von Dungeon, Räumen, Monstern und Regeln; ein Dungeon Master als Hauptakteur; mehrere NPC-Agenten mit eigenen APIs; und ein Endgegner, der ebenfalls als völlig autonome Einheit agiert. Dies ist keine einfache Demo mehr, sondern der Versuch einer Mehrkomponentensimulation, in der jede Rolle ihren eigenen Handlungsbereich hat.

Dieser Abschnitt ist besonders nützlich, weil er zeigt, dass lokale Modelle nicht nur eine Frage von Kosten oder Souveränität sind. Sie implizieren eine andere Denkweise über das System. Philippe erklärt beispielsweise, dass er dasselbe Modell für mehrere Agenten wiederverwendet, um eine Speicherüberlastung zu vermeiden, anstatt heterogene Instanzen zu vervielfältigen. Dieser Ansatz ist wichtig: In einer ressourcenbeschränkten Umgebung besteht gutes Design nicht unbedingt darin, für jeden Agenten das beste Modell auszuwählen, sondern manchmal darin, den gesamten Workflow so zu gestalten, dass er einen akzeptablen Hardware-Kompromiss ermöglicht. Das System muss dann auf Basis der verfügbaren Maschine und nicht nur der idealen Funktionalität entworfen werden.

Sein Projekt „Compose and Dragons“ veranschaulicht diese Logik perfekt. Die Dungeon-Karte wird im Voraus generiert, und weitere Komponenten bereichern das Spielerlebnis anschließend mit Beschreibungen, NPCs und Interaktionen. All dies basiert auf einer Orchestrierung aus lokalen Modellen, Docker-Diensten und spezialisierten Agenten. Es ist zwar noch kein Beweis für industrielle Robustheit, aber ein interessanter Machbarkeitsnachweis: Selbst mit begrenzten Ressourcen lässt sich ein relativ umfangreiches, autonomes System erstellen, sofern man dessen Einschränkungen hinsichtlich Latenz, Speicher und Komplexität akzeptiert. Philippe selbst spricht dies während der Demo offen an: Bei kleinen Modellen bleiben manche Interaktionen langsam, manche Übergänge schlagen fehl, und das System erfordert noch Anpassungen. Genau das macht das Feedback glaubwürdig.

Zum Schluss der Diskussion kristallisierte sich ein subtilerer, aber dennoch sehr hilfreicher Punkt heraus: Diese lokale Architektur lässt sich auch mit Docker-Sandboxes kombinieren, vorausgesetzt, die entsprechenden Ports werden explizit geöffnet, um aus der isolierten Umgebung eine Verbindung zum Modell-Runner herzustellen. Hier zeigt sich erneut das zentrale Thema des Abends: Agenten, Modelle und Tools sind nur so gut wie die Laufzeitumgebung, die sie korrekt verbindet. Lokale Modelle sind daher keine „einfache“ Alternative zur Cloud; sie verlagern das Problem lediglich auf eine andere Ebene, auf der ein Kompromiss zwischen Autonomie, Leistung, Speicherbedarf und Ausführungsarchitektur gefunden werden muss.

Zusammenfassend erinnert uns Philippe Charrières Demonstration an eine wesentliche Sache:

Lokale Modelle sind nützlich, aber sie beseitigen die Komplexität nicht; sie machen sie lediglich sichtbarer.

☸️ Sébastien Blanc – Produktionsagenten – Kubernetes & Knative

Die jüngste Intervention zielt eindeutig auf einen produktionsreifen Ansatz ab. Nach Agenten, Modellen und Sandboxes stellt sich nun die einfache Frage:

Wo und wie können diese Systeme skaliert werden?

Die vorgeschlagene Antwort ist unkompliziert: Java + Kubernetes + Knative.

🚀 Ein bewusster Stapel

Die Wahl ist bewusst eindeutig:

Java (Quarkus) für die Anwendungsschicht
Docker für die Verpackung
Kubernetes als primäre Laufzeitumgebung
Knative führt serverloses Arbeiten ein

Auch während des Gesprächs wird eine klare Position bezogen:

Agenten-Workflows werden industrialisiert, und Kubernetes wird ihr Betriebssystem bleiben.

🔥 Von der lokalen Demo zur Produktion

Die Demonstration folgt einem sehr konkreten, fast schon pädagogischen Ansatz:

Erstellung eines lokalen Chatbots, der über Docker Model Runner mit einem Modell verbunden ist.
Bereitstellung über eine einfache HTTP-API
Containerisierung der Anwendung
Bereitstellung auf Kubernetes
Ausführung in einem Pod… der mit dem lokalen Modell interagieren kann

👉 Interessanter Punkt: Das Modell bleibt über eine OpenAI-kompatible API zugänglich, was die Wiederverwendung jeder bestehenden Bibliothek ohne großen Anpassungsaufwand ermöglicht.

⚡ Knative – der wahre Gamechanger

Sobald die Anwendung auf Kubernetes bereitgestellt ist, verändert der Wechsel zu Knative das Ausführungsmodell grundlegend.

Anstatt kontinuierliche Pods zu verwalten, wechseln wir zu einem nativen serverlosen Kubernetes Modell:

Kein Verkehr → 0 Pods
Eingehende Anfrage → Automatische Pod-Erstellung
Spitzenlast → massive automatische Skalierung
Ende der Aktivität → Rückkehr zu Null

👉 Einfache, aber effektive Demonstration:

Ein curl-Befehl löst die Erstellung eines Pods aus. Die Anfrage wurde bearbeitet.
Wenige Sekunden später → verschwindet die Kapsel

Wir verwalten keine Maschinen mehr, sondern nur noch auf Abruf fällige Arbeitslasten.

🧠 Das eigentliche Problem: das Gedächtnis der Agenten

Dieses Modell wirft unmittelbar eine entscheidende Frage auf:

Was passiert mit dem Speicher, wenn alles gegen Null skaliert?

Die vorgeschlagene Lösung ist pragmatisch:

Agenten erklärungsfrei machen
den Staat in ein dediziertes System auslagern

👉 Verwendete Lösung:

Redis als gemeinsam genutzter Speicher
Speichern des Status von Konversationen/Agenten außerhalb von Pods

Ergebnis :

Agenten können spontan neu erstellt werden.
Der Speicher bleibt unabhängig von der Infrastruktur erhalten.
Das System bleibt mit Knatives aggressiver Skalierung kompatibel

🧩 Hin zu verteilten agentenbasierten Systemen

Die Schlussfolgerung eröffnet eine interessante Richtung:

Agentenbereitstellung über Kubernetes CRDs
Kommunikation zwischen Agenten
groß angelegte Orchestrierung
Auslösung über Ereignisse (Kafka, HTTP…)

👉 Mit nur wenigen Zeilen YAML können Sie Folgendes erreichen:

Mehrere Agenten einsetzen
um sie zur Kommunikation zu bringen
ihren Lebenszyklus automatisch verwalten

💡 Zum Mitnehmen

Dieser Abschnitt ändert die Perspektive völlig:

Ein Agent ist kein Skript oder lokales Tool mehr. Es handelt sich um eine verteilte, kurzlebige Recheneinheit, die von Kubernetes orchestriert wird.

Und mit Knative + Redis erhalten wir eine Architektur, in der:

Die Ausführung ist flexibel
Der Staat ist ausgelagert
und Agenten werden in der Produktion wirklich skalierbar

🧭 Globale Vision

Die Gespräche laufen in dieselbe Richtung:

🔁 Vorher

LLM = Assistent
gelegentliche Verwendung

🚀 Jetzt

autonome Agenten
Multiagentensystem
Orchestrierung
tatsächliche Ausführung

🧩 Die wichtigsten Bausteine

| Domäne | Lösung | | ------------- | -------------------- | | Agenten | Docker-Agenten | | Sicherheit | Docker-Sandbox | | Modelle | Docker Model Runner | | Orchestrierung | YAML / Multiagentensystem | | Infrastruktur | Kubernetes / Knative | | Speicher | Wiederholen |

🎯 Fazit

Das eigentliche Problem ist nicht die Begrenzung der Anzahl der Agenten, sondern:

Geben Sie ihnen maximale Autonomie innerhalb eines streng kontrollierten Rahmens

Schlüsselkonzepte:

Sandboxing
Netzwerkrichtlinien
sichere Einschleusung von Geheimnissen
Multiagenten-Orchestrierung
infrastrukturskalierbar

🚀 Zum Mitnehmen

Wir bewegen uns von Folgendem weg:

👉 „Ich frage eine KI“ hat 👉 „Ich delegiere an ein autonomes System“