Autonome Multi-Agenten-Systeme: Wie ein Entwickler mit 13 € im Monat durchstartete

Ein Entwickler, der sich in einer schwierigen Lebensphase befand, hat in nur 24 Stunden ein revolutionäres Multi-Agenten-System veröffentlicht. Das Besondere: Es läuft auf einem günstigen Virtuellen Server für gerade einmal 13 Euro im Monat – und verzichtet auf teure Cloud-Dienste. Der Clou liegt in der Architektur: Statt Code zu ändern, passen die Agenten ihre Konfigurationen selbstständig an YAML-Dateien an. Ein spezieller CEO-Agent analysiert täglich harte Kennzahlen und trifft datenbasierte Entscheidungen, die das System kontinuierlich optimieren.

Von einem einfachen Bot zum autonomen Ökosystem

Vor wenigen Stunden verfügte das System noch über einen einzelnen Agenten namens ZeroClaw, der gelegentlich auf Bluesky postete. Doch diese Lösung war instabil: maximal 15 Tool-Aufrufe, nur 50 Nachrichten Historie, keine Erinnerungsfähigkeit zwischen den Läufen und keine Möglichkeit zur Optimierung. Heute besteht das System aus mehreren spezialisierten Agenten, die zusammenarbeiten – ähnlich einem Unternehmen mit klaren Rollen und Verantwortlichkeiten.

Die neue Architektur umfasst:

• Einen CEO-Agenten, der täglich KPIs auswertet und strategische Empfehlungen erstellt
• Ein Auditor-System, das Arbeiter-Agenten überprüft und Konfigurationsvorschläge unterbreitet
• Eine metrikbasierte Datenbank, die jeden Agentenlauf protokolliert
• Selbstoptimierende YAML-Konfigurationen, die ohne Code-Änderungen auskommen

Besonders beeindruckend: Der CEO-Agent identifizierte selbstständig vier gescheiterte Vorläufer-Läufe, analysierte die Ursachen und schlug konkrete Maßnahmen zur Stabilisierung vor. All das auf einem einzigen Server für 13 Euro monatlich.

Die Hardware: Minimalistisch, aber leistungsfähig

Als Grundlage dient ein Google Cloud e2-small-VM mit folgenden Spezifikationen:

• 2 GB RAM
• 2 geteilte vCPUs
• 20 GB Festplattenspeicher

Die monatlichen Kosten betragen etwa 13 Euro. Mit den verbleibenden GCP-Guthaben des Entwicklers ergibt sich eine Laufzeit von rund 20 Monaten. Als Sprachmodelle kommen Gemini Flash-Lite für die meisten Rollen und Gemini Pro für den CEO-Agenten zum Einsatz. OpenRouter-Modelle dienen lediglich als Notfall-Fallback, da sie unter Last stark limitiert sind.

Die Datenhaltung erfolgt lokal:

• SQLite für Metriken
• YAML-Dateien für Agenten-Konfigurationen
• Markdown-Dokumentation
• ChromaDB (eingebettet) für Speicherfunktionen

Es gibt keinerlei externe verwaltete Dienste oder teure Vektordatenbanken. Das gesamte System läuft in einer einzigen Python-Umgebung auf dem VPS.

Der Schlüssel zum Erfolg: Konfiguration statt Code

Die größte Herausforderung bei Multi-Agenten-Systemen ist die Frage, wie Agenten sich selbst verbessern können, ohne das Gesamtsystem zu destabilisieren. Die naheliegende Lösung – das direkte Ändern von Python-Code durch Agenten – führt oft zu Problemen: Halluzinationen von Import-Befehlen, Syntaxfehler, Sicherheitslücken oder Endlosschleifen.

Die innovative Lösung des Entwicklers: Agenten modifizieren ausschließlich YAML-Konfigurationsdateien.

Die Ordnerstruktur sieht wie folgt aus:

agents/
├── configs/
│   ├── researcher.yaml
│   ├── writer.yaml
│   ├── ceo.yaml
│   └── auditor_researcher.yaml
└── proposals/
    └── pending_config_changes.yaml

Eine typische Konfigurationsdatei für einen Forschungsagenten könnte so aussehen:

id: researcher
role: "Content Researcher"
goal: |
  Finde 3-5 aktuelle Themen für Social-Media-Posts, die zur PINGx-Build-in-Public-Strategie passen.
backstory: |
  Du bist ein scharfer Rechercheur, der Trends im KI- und Indie-Hacker-Bereich erkennt.
  Nutze stets `web_search` und zitiere nur echte URLs – erfinde keine Inhalte.
llm_role: researcher
tools:
  - web_search
max_iter: 10

Wenn der Auditor-Agent eine Schwäche im Forscher-Agenten erkennt, schlägt er Änderungen in einer Vorschlagsdatei vor:

target_agent: researcher
proposer: auditor_researcher
summary: "HackerNews-Trends als zusätzliche Recherchequelle hinzufügen"
changes:
  - field: backstory
    operation: append
    value: "Konsultiere zusätzlich die HackerNews-Startseite."
expected_impact:
  metric: engagement_rate
  direction: up
  magnitude: "+5%"
reasoning: |
  In den letzten 7 Tagen verpasste der Forscher-Agent 3 virale KI-Themen mit jeweils über 500 Upvotes auf HN.

Der CEO-Agent überprüft diesen Vorschlag über Nacht. Bei Zustimmung wird die Änderung als einfacher YAML-Eintrag umgesetzt und als Git-Commit dokumentiert. Jede autonome Änderung ist damit in zehn Sekunden rückgängig zu machen. Der Python-Code bleibt unverändert und stabil.

Warum ein CEO-Agent keine leere Metapher ist

Viele Demo-Systeme mit Multi-Agenten enthalten einen scheinbaren „Manager-Agenten“, der zwar tiefgründig klingende Ratschläge gibt, aber keine konkreten Ergebnisse liefert. Der Unterschied hier: Der CEO-Agent basiert ausschließlich auf harten Kennzahlen.

Die priorisierten KPIs, die der CEO täglich analysiert, sind:

1. Spenden in Euro (tägliche Einnahmen)
2. Follower auf X/Bluesky (Wachstum der Reichweite)
3. Engagement-Rate (Likes und Antworten pro Post)
4. Service-Anfragen (Anzahl der Interessenten)
5. KI-Kosten in USD (Begrenzung auf 0,50 Dollar pro Tag)

Jeden Abend um 20 Uhr führt der CEO-Agent folgende Schritte durch:

• Abfrage der letzten 14 Tage an KPIs
• Analyse aller Agenten-Läufe der letzten 3 Tage
• Prüfung ausstehender Auditor-Vorschläge
• Erstellung eines Markdown-Berichts mit:
• Erfolgen und Misserfolgen
• Entscheidungen zu Vorschlägen
• Konkreten Empfehlungen für die KPIs
• Prioritäten für den nächsten Tag

Beim ersten Durchlauf identifizierte der Bericht:

„Keine KPIs in den letzten 14 Tagen erfasst. Dies scheint der initiale Lauf zu sein. In den letzten 3 Tagen traten 100 % Fehlerquote (4 Fehler) im CEO-Crew auf. Probleme umfassen fehlende Umgebungsvariablen, nicht installierte Pakete und fehlerhafte Einstellungen des Embedders.“

Tatsächlich hatte der Entwickler zuvor mehrmals vergessen, Umgebungsvariablen zu setzen oder die Google GenAI-Schnittstelle zu installieren. Die Metrikdatenbank hatte jeden dieser Fehler protokolliert – der CEO-Agent las sie einfach zurück. Genau in diesem Moment war klar: Das System funktioniert.

Die konkreten Schritte des Projekts

Für Entwickler, die ähnliche Systeme aufbauen möchten, hier die praktischen Maßnahmen, die umgesetzt wurden:

• Upgrade des VPS von e2-micro (1 GB RAM) auf e2-small (2 GB, 2 vCPU)
• Erweiterung des Speichers von 10 auf 20 GB für CrewAI-Abhängigkeiten
• Installation der Umgebung auf dem VPS: python3-venv, rsync, cron

Mit dieser minimalistischen, aber durchdachten Architektur beweist der Entwickler, dass hochkomplexe KI-Systeme auch mit geringen Mitteln umsetzbar sind. Der Fokus auf Konfiguration statt Code und datengetriebene Entscheidungen könnte die Art und Weise, wie autonome Agenten-Systeme in Zukunft gebaut werden, nachhaltig verändern.

Der nächste Schritt? Das System wird weiter wachsen – und vielleicht bald noch mehr Entwickler inspirieren, ihre Ideen ohne hohe Investitionen in die Tat umzusetzen.