05 — KI- und Multi-Agenten-Systeme
Eine funktionierende Multi-Agenten-Infrastruktur
Die Infrastruktur, die den Rest der Arbeit möglich macht.
Ein maßgeschneidertes, bidirektionales Multi-Agenten-Betriebssystem läuft kontinuierlich auf dedizierter Hardware. Es wurde von Grund auf entworfen und gebaut — nicht aus Open-Source-Frameworks zusammengesetzt.
Dies ist der Schwerpunkt der aktuellen Arbeit. Alles andere auf dieser Website wird durch sie ausgeliefert oder von ihr koordiniert.
Eine Multi-Agenten-Betriebsinfrastruktur läuft kontinuierlich auf einem dedizierten Server. Sie ist bidirektional und stets aktiv: Die Agenten halten persistenten Speicher und eine persistente Runtime, sodass sie nicht jedes Mal kalt starten, wenn ich auf sie zurückgreife. Das System wurde von Grund auf entworfen und gebaut — nicht aus Open-Source-Agenten-Frameworks zusammengesetzt — weil die Anforderungen spezifisch waren und die Koordination meine sein musste, von Anfang bis Ende kontrollierbar.
Es gibt unterschiedliche Agentenklassen, jede mit einer definierten Rolle. Ein zentrales Orchestrierungsgehirn interpretiert die Absicht und leitet die Arbeit weiter. Botschafter übersetzen diese Absicht in das jeweils eigene Protokoll jedes Anbieters und Systems. Auditoren verifizieren, was andere Agenten erzeugen. Boten bewegen Information verlustfrei zwischen den Schichten. Forscher sammeln Kontext und spielen ihn zurück. Senior-Executoren leisten Arbeit voller Leistungsfähigkeit, bis zu sechzehn auf einmal; unter ihnen fächern sich engere Sub-Agenten auf — mehr als dreihundert parallel, wenn die Last es verlangt.
Ich kommandiere die Flotte von mehreren Oberflächen aus. Von der Workstation über VSCode und die Linux-CLI; von Mobilgeräten in Echtzeit; über bidirektionale Verbindungen auf Socket-Ebene, die offen bleiben statt zu pollen; und über Echtzeit-Sprachanrufe mit laufenden Instanzen. Der Sinn der Breite ist nicht Neuheit — es ist, dass dieselbe Infrastruktur von dort erreichbar ist, wo die Arbeit gerade anfällt.
Senior-Executor-Instanzen, volle Leistungsfähigkeit, gleichzeitig laufend
engere Sub-Agenten parallel, wenn die Last es erfordert
gleichzeitig orchestrierte LLM-Anbieter — Anthropic, OpenAI, Google, xAI, Moonshot
immer aktiv, auf dedizierter Hardware, mit persistentem Speicher und Runtime
Die Zahlen, mit denen sie tatsächlich läuft.
Infrastruktur / Dauerbetrieb
- Senior-Executor-Instanzen
- bis zu 16 gleichzeitig
- Sub-Agenten
- 300+ parallel
- LLM-Anbieter
- 5, gleichzeitig orchestriert
- Transport
- auf Socket-Ebene, bidirektional, geringe Latenz
- Befehlsoberflächen
- Workstation · Mobil · Sprache
- Runtime-Host
- dedizierter Dell-Server, immer aktiv
- Betriebszustand
- persistent — die Agenten starten nie kalt
- Agent zu Agent
- protokollvermittelt, auditiert
- Kontextschnittstellen
- Function Calling · MCP · RAG
- Ursprung
- von Grund auf gebaut — kein Framework-Zusammenbau
Ein Gehirn, mehrere Klassen, viele Arbeiter.
Die Absicht tritt am Zentrum ein. Sie wird zerlegt, an die für die Aufgabe geeignete Klasse weitergeleitet, ausgeführt und verifiziert — dann kehrt das Ergebnis ins Zentrum zurück, das das einzige vollständige Bild hält.
Schema. Die Klassenrollen sind fest; die Instanzanzahl skaliert mit der Last.
Wofür jede Schicht verantwortlich ist.
Das zentrale Gehirn hält das gesamte Problem.
Ein Orchestrierungsgehirn sitzt im Zentrum. Es interpretiert die Absicht, zerlegt eine Mission in Aufgaben, leitet diese Aufgaben an die dafür am besten geeigneten Agenten weiter und hält den globalen Kontext, den kein einzelner Arbeiter für sich allein sehen kann.
Es löst außerdem Konflikte zwischen Agenten und erhält den Betriebszustand über den gesamten Lauf hinweg. Wenn zwei Pfade uneinig sind, wird die Entscheidung hier getroffen, mit dem vollständigen Bild — nicht am Rand durch einen Arbeiter, der nur seinen eigenen Ausschnitt kennt.
- Interpretiert die Absicht und zerlegt sie in einzelne Aufgaben
- Leitet die Arbeit an die für jede Aufgabe geeignete Agentenklasse weiter
- Hält den globalen Kontext und löst Konflikte
- Erhält den Betriebszustand über den gesamten Lauf hinweg
Übersetzung und Transport zwischen den Schichten.
Botschafter übersetzen die Absicht in das jeweils eigene Protokoll jedes Anbieters, jeder CLI und jedes Systems. Eine einmal im Zentrum ausgedrückte Aufgabe erreicht jeden Endpunkt in der Form, die dieser Endpunkt tatsächlich erwartet, sodass die Orchestrierungsschicht nicht an die Schnittstelle eines einzelnen Anbieters gekoppelt ist.
Boten bewegen Information verlustfrei zwischen den Schichten. Ihre Aufgabe ist Treue: Was eine Schicht erzeugt hat, ist das, was die nächste Schicht erhält, unversehrt, statt durch wiederholtes Paraphrasieren verschlechtert zu werden.
- Botschafter sprechen das Protokoll jedes Anbieters, jeder CLI und jedes Systems nativ
- Boten wahren die Treue beim Bewegen von Information zwischen den Schichten
- Gemeinsam halten sie den Kern anbieterneutral
Die Arbeit anderer Agenten wird geprüft, bevor sie zählt.
Auditoren inspizieren, validieren und verifizieren die Arbeit, die andere Agenten erzeugen — auf Korrektheit, auf Sicherheit und auf Kohärenz mit dem Rest des Systems. Sie sind bewusst eine eigene Klasse: Der Agent, der die Arbeit macht, ist nicht der Agent, der sie bestätigt.
Das ist dasselbe Prinzip wie Code-Review und Funktionstrennung, innerhalb der Flotte angewandt. Eine Ausgabe wird nicht akzeptiert, weil ein Agent behauptet, sie sei fertig; sie wird akzeptiert, weil ein anderer Agent sie gegen die Anforderung verifiziert hat.
- Inspizieren und validieren die Ausgabe anderer Agenten
- Prüfen Korrektheit, Sicherheit und Kohärenz
- Funktionstrennung — der Macher ist nie der Prüfer
Kontext vorher gesammelt, Erkenntnisse währenddessen zurückgespielt.
Forscher sammeln Kontext, untersuchen offene Fragen und spielen Erkenntnisse ins System zurück. Wenn eine Mission Information braucht, die die Flotte noch nicht besitzt, geht diese Klasse sie holen, statt zu raten.
Ihre Ausgabe fließt zurück ins Orchestrierungsgehirn und in den Arbeitsspeicher, sodass eine einmal festgestellte Tatsache jedem Agenten zur Verfügung steht, der sie danach braucht.
- Sammeln Kontext und untersuchen offene Fragen
- Spielen Erkenntnisse in den geteilten Arbeitsspeicher zurück
- Verwandeln Unbekanntes in Eingaben, die der Rest der Flotte nutzen kann
Leerlaufkapazität wird zu Vorbereitungskapazität
Wenn es keine Aufgabe gibt, studiert die Flotte.
Wenn keine Aufgabe zugewiesen ist, bleiben die Agenten nicht untätig. Sie treten in eine Schleife aus selbstgesteuertem Studium und Cross-Training ein: Sie arbeiten Material durch, vergleichen Ansätze und lehren einander über die Klassen hinweg.
Dieses Lernen wird nicht als Transkript belassen. Implementierer-Agenten nehmen das Studierte, feintunen das studierte Modell damit und injizieren das resultierende Wissen für den künftigen Betrieb zurück ins System. Die Flotte, die die Arbeit von morgen erledigt, ist messbar vorbereiteter als jene, die die von heute beendet hat.
- Selbstgesteuertes Studium und Cross-Training während der Leerlauffenster
- Implementierer-Agenten feintunen das studierte Modell anhand des Gelernten
- Wissen wird für den künftigen Betrieb zurückgespielt, nicht nur protokolliert
Anbieterneutral — und in der Lage, Gewichte direkt zu modifizieren.
Anbieter-Routing
- Anthropic
- OpenAI
- xAI
- Moonshot
Eine Aufgabe, das Modell, das zu ihr passt. Keine Anbieterbindung.
Fine-Tuning · LoRA · eine Forschungsrichtung
Nicht an einen Anbieter gebunden — und nicht auf das Prompting beschränkt.
Die Infrastruktur orchestriert mehrere LLM-Anbieter zugleich — Anthropic, OpenAI, Google, xAI, Moonshot — und leitet jede Aufgabe an das Modell, das zu ihr passt. Sie ist nicht an einen einzelnen Anbieter gebunden. Wo es hilft, gehe ich unter den Prompt: Fine-Tuning, LoRA und fortgeschrittene Gewichts- und Bias-Modifikation an Modellen mit offenen Gewichten.
Es gibt außerdem eine aktive Forschung, die ich nur auf hoher Ebene beschreiben werde. Sie nutzt kleine Modelle mit offenen Gewichten im Bereich von vier bis zwanzig Milliarden Parametern, mit einem proprietären Verfahren, das nur einen minimalen Teil — im Speicher — sehr viel größerer Modelle im Bereich von hundert bis sechshundert Milliarden aktiviert und das in die kleinen Modelle integriert. Die Methode wird zurückgehalten; die Richtung hat großes Potenzial, und mehr werde ich hier nicht sagen.
- Fünf Anbieter gleichzeitig orchestriert, pro Aufgabe weitergeleitet
- Fine-Tuning, LoRA, Gewichts-/Bias-Modifikation an Modellen mit offenen Gewichten
- Forschung an kleinen Modellen (~4–20B), die selektive Aktivierung größerer (~100–600B) integriert — Methode zurückgehalten
Dies ist die Infrastruktur, die den Rest der Arbeit möglich macht.
Was sie erreichen kann und wie sie solide bleibt.
Function Calling
Die Agenten handeln über typisierte Werkzeugschnittstellen — lesen, schreiben, abfragen, ausführen — statt Prosa auszugeben, die ich von Hand interpretieren muss.
MCP
Das Model Context Protocol verbindet Agenten über einen gemeinsamen Vertrag mit Werkzeugen und Datenquellen, sodass eine einmal hinzugefügte Fähigkeit der gesamten Flotte zur Verfügung steht.
RAG
Die Abrufung versorgt die Agenten mit dem spezifischen Kontext, den eine Aufgabe aus einem Arbeitsspeicher braucht, statt sich darauf zu verlassen, worauf ein Modell zufällig trainiert wurde.
Persistenter Speicher
Zustand, frühere Entscheidungen und angesammelter Kontext überdauern zwischen den Sitzungen. Die Infrastruktur erinnert sich; nichts muss jeden Morgen neu erklärt werden.
Observability
Was jeder Agent getan hat, warum und gegen welche Eingaben, wird aufgezeichnet — damit das Verhalten im Nachhinein inspiziert und nicht nur im Moment vertraut werden kann.
Sicherheits-Selbstaudit
Kontinuierliches, autorisiertes Selbstaudit mit BlackArch Linux über lokale und Cloud-Server. Bis heute: keine offenen Sicherheitslücken und kein Informationsleck.
Wie aus einem Ziel koordinierte Arbeit wird.
Eine Anfrage geht nicht direkt an einen Arbeiter. Sie wird als ein einziges Ziel gelesen, in geordnete Aufgaben zerlegt, nach Klasse weitergeleitet, ausgeführt, verifiziert und ans Zentrum zurückgegeben. Jede Stufe hat einen definierten Verantwortlichen.
Vom Eingang zur Rückgabe
- 01 Eingang Die Absicht trifft von einer Befehlsoberfläche ein und wird als ein einziges Ziel gelesen, noch nicht als Plan.
- 02 Zerlegen Das Orchestrierungsgehirn bricht das Ziel in einzelne, geordnete Aufgaben mit expliziten Abhängigkeiten auf.
- 03 Weiterleiten Jede Aufgabe wird der dafür geeigneten Agentenklasse zugewiesen — einem Senior-Executor oder einem Aufgebot von Sub-Agenten.
- 04 Ausführen Die Arbeit läuft parallel, wo der Abhängigkeitsgraph es erlaubt, gegen typisierte Werkzeugschnittstellen.
- 05 Auditieren Ein separater Agent verifiziert jedes Ergebnis auf Korrektheit, Sicherheit und Kohärenz, bevor es zählt.
- 06 Zurückgeben Die verifizierte Ausgabe fließt zurück ins Zentrum, das als Einziges das vollständige Bild des Laufs hält.
Verbindungen bleiben in beide Richtungen offen.
Die Verbindung zwischen einer Befehlsoberfläche und einer laufenden Instanz ist auf Socket-Ebene und bidirektional. Sie bleibt offen, statt zu pollen, sodass ich in eine Instanz pushen kann und sie zurückpushen kann — mitten in der Aufgabe, nicht nur bei Abschluss.
Bidirektionaler Socket
Eine Leitung, offen gehalten, in beide Richtungen genutzt.
Auf Socket-Ebene · bidirektional · geringe Latenz
Kein Anfragen-und-Warten. Eine offen gehaltene Leitung.
Die meiste Automatisierung spricht mit einem Modell, indem sie eine Frage stellt und auf eine Antwort wartet. Diese nicht. Der Transport ist ein persistenter Socket in beide Richtungen: Ich sende Anweisung oder Kontext in eine lebende Instanz, und die Instanz sendet Fortschritt, Fragen und Ergebnisse auf derselben offenen Leitung zurück.
Weil die Verbindung gehalten statt pro Nachricht neu aufgebaut wird, bleibt die Latenz gering und ein Austausch kann fortlaufend sein. Ein Agent kann mich mitten in einer Aufgabe etwas fragen und auf die Antwort hin handeln, ohne den Kanal abzubauen und neu aufzubauen.
- Persistenter Socket — kein Reconnect-Overhead pro Nachricht
- Beide Enden können initiieren — hineinpushen, zurückpushen
- Fortlaufender Austausch mitten in der Aufgabe, kein Anfragen-und-Warten
Erreichbar von dort, wo die Arbeit ist.
Dieselbe Infrastruktur antwortet drei Oberflächen. Die Breite dient nicht der Neuheit — sie bedeutet, dass die Flotte von der Workstation, von einem Telefon und per Sprache erreichbar ist, ohne ein eigenes System für jede.
Alle drei Oberflächen nutzen denselben bidirektionalen Transport in einen Kern.
Leerlauf, studieren, feintunen, injizieren — dann wiederholen.
Die Vorbereitung der Flotte ist beim Deployment nicht festgelegt. Zwischen den aktiven Aufgaben studiert sie, konsolidiert das Studierte zu einer Modelländerung und spielt das Ergebnis zurück. Die Schleife ist es, die die Flotte von morgen vorbereiteter macht als die von heute.
- Aktive Aufgabe Die Flotte arbeitet gegen eine Mission. Die Absicht wird zerlegt, weitergeleitet, parallel ausgeführt, auditiert und zurückgegeben. Der persistente Zustand wird im Laufe der Ausführung aktualisiert.
- Leerlauffenster Selbstgesteuertes Studium und Cross-Training. Ohne zugewiesene Aufgabe arbeiten die Agenten Material durch, vergleichen Ansätze und lehren einander über die Klassen hinweg, statt untätig zu sein.
- Konsolidierung Studiertes Material wird zu einer Modelländerung. Implementierer-Agenten feintunen das studierte Modell mit offenen Gewichten anhand des Gelernten — LoRA und direkte Gewichts- und Bias-Modifikation, wo es hilft.
- Injektion Wissen wird für den künftigen Betrieb zurückgespielt. Das Ergebnis wird ins System injiziert, nicht als Transkript belassen, sodass der nächste Lauf vorbereiteter beginnt, als der vorherige geendet hat.
Was die Flotte weiß und wie sie es erreicht.
Ein Agent verlässt sich nicht darauf, worauf ein Modell zufällig trainiert wurde. Der Kontext wird für die anstehende Aufgabe geholt, der Zustand überdauert zwischen den Sitzungen, und jede Aktion läuft durch einen typisierten Vertrag. Nichts muss jeden Morgen neu erklärt werden.
Kontextschnittstellen
- Arbeitsspeicher-Store
- aufgabengebundener Kontext, auf Abruf geholt
- Abrufung
- RAG — der spezifische Kontext, den eine Aufgabe braucht, nicht die Trainingsvermutung eines Modells
- Persistenter Zustand
- Entscheidungen und angesammelter Kontext überdauern zwischen Sitzungen
- Werkzeugvertrag
- MCP — eine einmal hinzugefügte Fähigkeit ist flottenweit erreichbar
- Aktionsschnittstelle
- Function Calling — typisiertes Lesen / Schreiben / Abfragen / Ausführen
- Herkunft
- was jeder Agent getan hat, warum und gegen welche Eingaben, wird aufgezeichnet
Die Infrastruktur prüft sich selbst.
Dieselbe Flotte, die die Arbeit macht, wird einem nach innen gerichteten Sicherheitsaudit unterzogen. Es läuft kontinuierlich, mit Autorisierung, gegen meine eigenen Server — lokal und Cloud — unter Verwendung des BlackArch-Werkzeugsatzes.
Autorisierter Umfang
Das Selbstaudit läuft gegen meine eigenen lokalen und Cloud-Server, kontinuierlich und mit ausdrücklicher Autorisierung. Es ist eine nach innen gerichtete Übung, keine nach außen gerichtete.
BlackArch-Werkzeugsatz
BlackArch Linux liefert die Werkzeuge, mit denen das Audit läuft — dieselben Instrumente, mit denen man ein System sondiert, werden auf die Infrastruktur gerichtet, die die Flotte beherbergt.
Aktuelles Ergebnis
Bis heute meldet das Audit keine offenen Sicherheitslücken und kein Informationsleck. Es ist eine wiederkehrende Prüfung, daher ist das Ergebnis ein aktueller Zustand und kein einmaliges Zertifikat.
Open to the right work
Wenn Ihr Problem eine derart bewusst gestaltete Betriebsschicht braucht, ist das das Gespräch.
If you are holding a problem that doesn't fit inside one field, that is the conversation I want.