# WorldIP Tagesbericht – 24. Juni 2026
Der 24. Juni 2026 begann operativ erfolgreich: Auf worldip.de wurde ein neuer KI-Artikel über autonome KI-Agenten im Marketing veröffentlicht. Der Beitrag nutzte das MoEngage-Beispiel, wurde inklusive Titelbild erstellt und direkt in WordPress publiziert. Die Umsetzung war effizient: 43 Tool-Calls in rund 7 Minuten, inklusive Media-ID 404 für das Titelbild und erfolgreicher Veröffentlichung.
Der Schwerpunkt des Tages verschob sich danach auf eine deutlich größere technische Untersuchung: Aus einer ursprünglich einfachen IndoPilot-Statusprüfung wurde ein systematischer Agenten-Audit mit anschließender Konfigurationsreparatur.
## Kernthema: Agenten-Audit und Konfigurationsreparatur
Im Verlauf der Analyse zeigte sich, dass mehrere Agenten-Profile nicht mit dem tatsächlich funktionierenden System synchronisiert waren. Drei Profile, coder, repair und fiscus, verwendeten noch den Provider openrouter/auto. Diese Konfiguration stammte aus einem Template-Kopiervorgang vom 16. Juni 2026 und war nie funktionsfähig eingerichtet worden. Alle API-Aufrufe gegen diese Profile scheiterten mit HTTP 401 Unauthorized.
Die Konfigurationsdateien waren zwar vorhanden, entsprachen aber nicht dem produktiven Setup. Das funktionierende System nutzt den Provider custom mit dem Ollama-Cloud-Proxy als Base-URL. Genau diese Abweichung war die Ursache dafür, dass Teile des Agentensystems scheinbar vorhanden, praktisch aber nicht einsatzfähig waren.
## Analyseverlauf
Die Untersuchung begann mit einem Modellvergleich zwischen dem aktuell genutzten Kimi k2.6 und GLM-5.2. GLM-5.2 wurde als neuer custom_provider in die Root-Konfiguration aufgenommen. Vorher wurde die bestehende Konfiguration gesichert, anschließend wurden erfolgreiche API-Tests durchgeführt. Damit steht GLM-5.2 nun als Alternative mit großem Kontextfenster zur Verfügung.
Anschließend folgte die Bestandsaufnahme aller Agenten-Profile. Eine erste Einschätzung ging fälschlich davon aus, dass alle neun Agenten aktiv und produktiv seien. Diese Annahme wurde in einer Folgesession korrigiert: Die erste Analyse hatte Konfigurationseinträge als Fakten übernommen, ohne die tatsächliche Erreichbarkeit über API-Tests zu prüfen.
Die evidenzbasierte Nachprüfung ergab ein anderes Bild: Nur 6 von 9 Agenten waren tatsächlich erreichbar. Drei Profile lieferten reproduzierbar 401 Unauthorized.
## Kritischer Fund: Fiscus-Agent
Besonders kritisch war der Zustand des Fiscus-Agenten. Der Buchhaltungsagent war seit dem 14. Juni 2026 inaktiv, also seit 10 Tagen ohne Lauf, Log oder Prozess. Zusätzlich war seine Profil-Identität kein fachlicher Buchhaltungsprompt, sondern ein generischer Standard-Prompt ohne Dolibarr- oder Accounting-Kontext.
Damit wurde ein struktureller Widerspruch sichtbar:
– Die Chronicle beschrieb Fiscus als aktiven Buchhaltungsagenten.
– Der Skill fiscus-buchhaltungsagent enthielt detaillierte Dolibarr-Integrationen.
– Das eigentliche Profil war jedoch nur ein generisches Template.
Diese drei Ebenen waren nicht synchron. Fiscus existierte damit dokumentarisch und konzeptionell, aber nicht als korrekt konfigurierter produktiver Agent.
## Ursache
Die Ursache lag im Agent-Rename vom 16. Juni 2026. Dabei wurden Profile aus einem Template kopiert, ohne die Provider-Konfiguration an das funktionierende System anzupassen. Fünf Profile enthielten identische openrouter/auto-Einträge, ein klares Copy-Paste-Artefakt. Drei Profile, recherche, seo und texter, hatten hingegen von Anfang an den korrekten custom-Provider.
## Reparatur
In einer größeren Synchronisationsaktion wurden die betroffenen Profile bereinigt und angepasst. Die repair-Profile wurden von openrouter/auto auf kimi-k2.6:cloud/custom umgestellt, coder wurde aktiviert, und beide Konfigurationsstandorte wurden synchronisiert. Der Repair-Agent wurde wieder aktiviert und läuft erneut über seinen stündlichen Cronjob. Insgesamt wurden 10 Agenten synchronisiert. Danach bestanden keine bekannten Diskrepanzen mehr zwischen den Profilstandorten.
## Tests und Validierung
Die Reparaturen wurden nicht nur dateibasiert geprüft, sondern aktiv getestet:
– API-Tests per curl für die einzelnen Agenten
– hermes profile list zur Bestätigung der Synchronisation
– YAML-Validierung der geänderten Konfigurationsdateien
– GLM-5.2-Test über die Chat-Completions-API
Das Ergebnis: Alle 10 Agenten sind synchronisiert. Der Repair-Agent läuft wieder stündlich, der Coder-Agent ist aktiviert, und GLM-5.2 steht als Modellalternative zu Kimi k2.6 bereit.
## Weitere Aktivitäten
Neben dem Agenten-Audit liefen zwei Business-Projektstränge weiter.
Das IndoPilot Daily Project generierte das dritte Projekt: UMKM Landing Page Kit Indonesia. Dabei handelt es sich um ein Zero-Investment-Projekt für rund 64 Millionen indonesische Kleinunternehmer. Das Konzept sieht branchenspezifische HTML-Templates vor und erhielt eine Go-Empfehlung.
Außerdem erstellte das WorldIP Daily Business Project einen Vergleichs-Guide zum Thema eSIM Connectivity Hub.
## Offene Punkte
Der Fiscus-Agent ist weiterhin nicht vollständig wiederhergestellt. Die Provider-Konfiguration allein reicht nicht aus. Es müssen auch die Profil-Identität, Rollenbeschreibung und Dolibarr-Integration korrekt mit Skill und Chronicle synchronisiert werden.
Zusätzlich scheiterte der WorldIP Daily Report Cronjob zweimal am Tagesende. Ursache ist vermutlich ein PATH-Problem im Gateway: Das Codex-Binary ist im Wrapper-PATH verfügbar, aber offenbar nicht im Gateway-PATH. Die genaue Ursache des Daily-Report-Abbruchs muss noch behoben werden.
## Fazit
Der 24. Juni 2026 war ein Infrastruktur-Tag mit hohem Erkenntniswert. Neben einer erfolgreichen WordPress-Veröffentlichung wurde ein tiefer Konfigurationsfehler im Agentensystem offengelegt und weitgehend behoben. Die wichtigste Lehre des Tages: Konfigurationseinträge sind keine Betriebsnachweise. Erst aktive API-Tests, Logs und Prozessprüfung zeigen, ob ein Agent wirklich produktiv läuft.
Das System ist nach der Synchronisation deutlich robuster: Repair läuft wieder, Coder ist aktiviert, alle Agentenprofile sind konsistent, und GLM-5.2 steht als zusätzliche Modelloption bereit. Der größte verbleibende technische Blocker ist die vollständige Wiederherstellung des Fiscus-Agenten sowie die Behebung des Daily-Report-Cronjob-Problems.