Projekte

Großformatige Hero- und Hintergrundgrafiken für eine moderne Website aufbereitet und für den produktiven Einsatz optimiert. Wichtig war dabei das Verhältnis zwischen sichtbarer Bildqualität und Dateigröße. PNG-Ausgangsmaterial wurde für WebP-Auslieferung vorbereitet, damit visuell aufwendige Bereiche nicht unnötig die Ladezeit und Core Web Vitals verschlechtern. Schwierigkeit: Bei sehr großen Grafiken (über 2MB als PNG) führt jeder zusätzliche Ladezeit-Anteil direkt zu schlechteren LCP-Werten. Geprüft wurden verschiedene Komprimierungsstufen, um den Sweet Spot zwischen Dateigröße und visueller Qualität zu finden, ohne dass Artefakte in flächigen Farbverläufen sichtbar werden.

Internationale Website technisch für Suchmaschinen vorbereitet. Neben Canonical-URLs wurden hreflang-Verweise für Deutsch und Englisch korrekt gesetzt und anschließend direkt mit einem Googlebot-User-Agent geprüft, was tatsächlich ausgeliefert wird. Hauptaugenmerk lag darauf, Duplicate Content zwischen den Sprachversionen zu vermeiden und sicherzustellen, dass Suchmaschinen die richtige Sprachversion indexieren. Schwierigkeit: SvelteKit rendert die Seiten serverseitig, aber die hreflang-Tags müssen dynamisch je nach Request-Language gesetzt werden. Geprüft wurde, dass der Googlebot die korrekten Tags erhält und keine Canonical-Konflikte zwischen den Sprachvarianten bestehen.

Fehlerhafte TrueNAS-ZFS-Replikationen analysiert. Ursache waren unter anderem fehlende gemeinsame Snapshot-Basen zwischen Quelle und Ziel, wodurch keine normale inkrementelle Replikation mehr möglich war. Untersucht wurden Full Filesystem Replication, Replication-from-Scratch sowie die Frage, wann ein vollständiger Neuabgleich notwendig ist und wann anschließend wieder inkrementell gearbeitet werden kann. Schwierigkeit: Ohne gemeinsame Snapshot-Basis bricht die inkrementelle Replikation ab, und ein naives Löschen der Ziel-Datasets würde Daten verlieren. Geprüft wurde der Snapshot-Verlauf, um den letzten gemeinsamen Punkt zu identifizieren und von dort aus die Replikation wieder aufzunehmen.

Aufbau einer API-gestützten Projekt-Chronik mit SvelteKit, Strapi und Go-Backend. Einträge werden über eine REST-API mit API-Key-Authentifizierung, Validierung und Rate-Limiting gepusht und erscheinen öffentlich unter /de/projekte. Die Datenhaltung erfolgt in einer JSON-Datei, Editierung ist über die Admin-UI möglich. Implementiert wurden Deduplication-Logik, Tag-Filterung, Format-Spezifikation als Self-Description und ein mehrstufiges Validierungssystem für Heading, Wortzahl, Datum und erlaubte Tags. Die API unterstützt GET, POST, PUT und DELETE mit differenzierten Fehler-Responses.

Upgrade- und Migrationspfad für bestehende Shopware-6-Systeme untersucht. Besondere Aufmerksamkeit galt individuellen Plugins, Themes, Composer-Abhängigkeiten und Änderungen zwischen älteren 6.x-Versionen und aktuellen Releases. Bei solchen Migrationen ist nicht das eigentliche Update der kritische Punkt, sondern die Prüfung, welche kundenspezifischen Erweiterungen nach einem Versionssprung angepasst werden müssen. Schwierigkeit: Shopware ändert zwischen Minor-Versionen interne APIs und Event-Signaturen, was zu stillen Breakages in individuellen Plugins führt. Geprüft wurden Composer-Locks, Datenbank-Migrationen und die Kompatibilitätsmatrix aller installierten Erweiterungen.

Namensauflösung und Netzwerkverhalten zwischen LXD-Host und Containern analysiert. Dabei wurde geklärt, wann /etc/hosts-Einträge am Host ausreichend sind und wann sie direkt innerhalb eines Containers benötigt werden. Wesentlich ist, dass ein Container einen eigenen Netzwerk- und Userspace besitzt und Host-Konfigurationen deshalb nicht automatisch innerhalb des Containers verfügbar sind. Schwierigkeit: Symptome wie lokale Erreichbarkeit ohne Container-Zugang führen oft zu Fehldiagnosen, wenn die Isolation zwischen Host- und Container-Namespace nicht verstanden wird. Geprüft wurden Bridge-Netzwerke, DNS-Forwarding und die korrekte Platzierung von Host-Einträgen.

Bestehende FreePBX-Installation auf einer veralteten CentOS-basierten Plattform bewertet und Migrationspfad auf ein aktuelles System untersucht. Relevant waren insbesondere Export und Wiederherstellung von Extensions, SIP-Trunks, Routing-Regeln und der kompletten PBX-Konfiguration. Hauptziel ist eine Migration ohne unnötigen Neuaufbau der gesamten Telefonie-Infrastruktur. Schwierigkeit: CentOS-EOL bedeutet keine Sicherheitsupdates mehr, aber ein naives Neu-Setup würde alle individuell konfigurierten Anrufregeln, Warteschlangen und IVR-Strukturen verlieren. Geprüft wurde, welche Konfigurations-Exporte vollständig sind und wo manuelle Nacharbeit nötig ist.

API-basierte Kommunikation zwischen eCommerce-System und einer separaten Plattform für Lizenz- und Instanzverwaltung konzipiert. Bestellungen und Tarifänderungen sollen automatisiert an einen zentralen Dienst weitergegeben werden. Zu beachten waren Idempotenz, eindeutige Instanzzuordnung und die Trennung zwischen Shop-System, Lizenzlogik und eigentlicher Anwendung. Schwierigkeit: Bei Webhook-basierter Kommunikation können Ereignisse doppelt zugestellt werden oder in falscher Reihenfolge eintreffen. Implementiert wurden Idempotenz-Keys, eine ereignisbasierte Zustandsmaschine für Instanzen und klare Verantwortlichkeiten: der Shop kennt nur Bestellungen, der Lizenz-Dienst nur Tarife und Instanzen.

Individuelle Shopware-Erweiterung mit eigenen Produktmetadaten, Validierung und automatischer Plan-Zuordnung entwickelt. Beim Kauf bestimmter Produkte werden zusätzliche Daten verarbeitet und anschließend einer Instanz bzw. einem Tarif zugeordnet. Besonderes Augenmerk lag darauf, Shopware-Events und Validatoren zu verwenden, anstatt zentrale Core-Prozesse zu verändern und damit zukünftige Updates zu erschweren. Schwierigkeit: Shopwares Bestellprozess ist stark ereignisgesteuert, und die richtige Hook-Position ist entscheidend dafür, dass die Plan-Zuordnung vor dem Checkout abgeschlossen ist. Geprüft wurden die Event-Reihenfolge, Validierungs-Callbacks und die saubere Trennung zwischen Produktkonfiguration und Bestellverarbeitung.

ZFS-Replikationsstrategie für virtualisierte Workloads untersucht. Gerade bei iSCSI-Volumes und VM-Storage muss darauf geachtet werden, welche Child-Datasets bzw. ZVOLs Bestandteil eines Snapshots sind. Außerdem wurde bewertet, wann ein vollständiger Filesystem-Transfer sinnvoll ist und welche Daten wie beispielsweise temporäre Clones bewusst von Replikationen ausgeschlossen werden sollten. Schwierigkeit: Bei VMs mit mehreren Disks und Snapshots ist die ZFS-Dataset-Hierarchie komplex. Ein falscher Replikationsumfang führt entweder zu inkonsistenten VM-Zuständen oder zu unnötig großen Transfers. Geprüft wurden die Dataset-Struktur, die Snapshot-Namenskonventionen und die korrekte Auswahl der zu replizierenden ZVOLs.

Netzwerkproblem zwischen TrueNAS, Reverse Proxy und weiteren Infrastrukturkomponenten eingegrenzt. Obwohl einzelne Systeme lokal erreichbar waren, fehlten funktionierende Routen zwischen verschiedenen Netzen. Analysiert wurden Interface-Status, Routingtabellen, SSH-Erreichbarkeit und Reverse-Proxy-Verbindungen. Besonders wichtig war die Trennung zwischen lokalem Funktionieren und tatsächlicher Erreichbarkeit aus dem benötigten Netz. Schwierigkeit: Bei mehreren VLANs und Subnetzen ist es leicht, eine scheinbar funktionierende Verbindung zu haben, die nur im lokalen Segment funktioniert. Geprüft wurden statische Routen, Gateway-Zuordnungen und die Firewall-Regeln zwischen den Segmenten.

Architektur für eine Plugin-Lizenzierung im Marketplace: Trennung von PLAN-Tiers (Abonnement-Ebenen) und individuellen Plugins. Implementiert wurden Plan/Instance-Ownership-Modelle, FREE-Tier-Einschränkungen mit Enforcement auf API-Ebene und eine Plugin-Registry als zentrale Lizenzquelle. Herausforderungen: saubere Trennung von Abonnement- und Plugin-Berechtigungen, Enforcement-Gaps beim FREE-Tier und konsistente Ownership-Zuordnung bei mehreren Instanzen. Die Architektur wurde iterativ über Agent-Läufe ausgearbeitet und gegen Edge-Cases wie Plan-Wechsel, Downgrades und parallele Instanzen validiert.

Mehrere Coding-Agenten an eine lokale OpenAI-kompatible KI-Infrastruktur angebunden. Die Konfiguration wurde so angepasst, dass große Context-Fenster sowie Text- und Bild-Input genutzt werden können. Hauptaugenmerk lag auf einer zentralen API, über die unterschiedliche Entwicklungswerkzeuge dasselbe lokale Modell verwenden können, ohne an einen einzelnen Cloud-Anbieter gebunden zu sein. Schwierigkeit: Verschiedene Tools sprechen die OpenAI-API mit leicht abweichenden Implementierungen an. Einige erwarten bestimmte Response-Formate, andere nutzen Streaming, wieder andere senden zusätzliche Parameter. Geprüft wurde die Kompatibilität jedes einzelnen Clients mit dem lokalen Server und dass die Context-Limit-Einhaltung konsistent über alle Tools funktioniert.

Lokales llama.cpp-Inferenzsystem auf ein neueres 27B-Modell migriert und für eine einzelne GPU optimiert. Getestet wurden unterschiedliche Quantisierungen, GPU-Offloading, KV-Cache, Flash Attention und sehr große Context-Fenster. Hauptaugenmerk lag darauf, möglichst hohe Modellqualität zu erhalten, ohne VRAM-Grenzen oder Stabilität des dauerhaft laufenden API-Servers zu gefährden. Schwierigkeit: Bei 27B-Parametern mit Q4-Quantisierung benötigt das Modell bereits über 16GB VRAM, und der KV-Cache für lange Contexts frisst zusätzlich Speicher. Geprüft wurden verschiedene Layer-Offloading-Strategien, um die Balance zwischen Inferenzgeschwindigkeit und Stabilität zu finden.

Self-hosted KI-Infrastruktur auf ein neueres multimodales Modell aktualisiert. Das lokale LLM wurde über eine OpenAI-kompatible API für Coding-Agenten und andere Tools bereitgestellt. Neben Text sollte auch Bild-Input funktionieren. Zu beachten waren Context-Länge, GPU-Speicher, Cache-Format, Vision-Unterstützung und die Kompatibilität unterschiedlicher Clients mit Chat-Completions-APIs. Schwierigkeit: Nicht alle Clients unterstützen dieselben Extensions der OpenAI-API, und Vision-Modelle benötigen zusätzliche VRAM für die Bild-Encoder. Geprüft wurde, dass alle angebundenen Agenten das neue Modell korrekt ansprechen und dass der KV-Cache bei großen Context-Fenstern nicht zum VRAM-Overrun führt.

Speicherproblem auf einem Virtualisierungs- und Managementserver analysiert, dessen Root- und Var-Dateisystem zunehmend vollgelaufen war. Mit du und Log-Analyse wurden große Audit-, System- und Application-Logs identifiziert. Wichtig war, nicht einfach Dateien zu löschen, sondern zunächst festzustellen, welcher Dienst das Wachstum verursacht und ob Logrotation bzw. Retention korrekt eingestellt ist. Schwierigkeit: Auf Virtualisierungsservern können Audit-Logs und VM-Konsolen-Logs extrem schnell wachsen, besonders bei fehlerhaften VMs oder häufigen Reboots. Geprüft wurden die Logrotate-Konfiguration, die Retention-Fristen und ob bestimmte Dienste unnötig im Debug-Modus laufen.

Berechtigungskonzept für KI-Agenten entwickelt, die auf produktive Unternehmenssysteme zugreifen. Standardmäßig sollen Agenten nur Leserechte besitzen; Schreibzugriffe werden separat und bewusst aktiviert. Hauptaugenmerk liegt darauf, technische Möglichkeiten eines Agenten nicht nur durch dessen Prompt oder Memory einzuschränken, sondern zusätzlich über echte Credentials und Berechtigungen auf Systemebene. Schwierigkeit: Ein Agent mit zu breiten Rechten kann unbeabsichtigt Daten verändern oder löschen. Die Einschränkung über Prompts allein ist unzuverlässig, da der Agent durch Prompt-Injection oder eigene Schlussfolgerungen davon abweichen kann. Implementiert wurde ein Least-Privilege-Prinzip mit separaten Credentials pro Agent und expliziter Freigabe von Schreiboperationen.

KI-Agenten mit strukturiertem Zugriff auf ein ERP-System getestet. Aus einer vorhandenen Rechnungs- bzw. Dokumentvorlage konnte der Agent notwendige Geschäftsdaten ableiten und passende ERP-Objekte anlegen. Interessant war dabei weniger reine Texterkennung als das Verständnis der Beziehungen zwischen Partei, Adresse, Steuerdaten, Positionen und Buchhaltungskonten. Schwierigkeit: Ein Rechnungs-Dokument enthält verschachtelte Strukturen, die nicht linear lesbar sind. Der Agent muss verstehen, welche Daten zu welchem ERP-Objekt gehören und wie die Beziehungen zwischen Kunden, Positionen und Konten aufgebaut sind. Geprüft wurde die Korrektheit der erzeugten ERP-Objekte gegen die Quelldokumente.

Entwicklung eines Kalender-Plugins mit Datenbank-Schema, REST-API und Frontend-Integration. Das Schema deckt Events, Wiederholungen, Zeitzonen und Berechtigungen ab. Die API stellt CRUD-Operationen, Konflikterkennung und Serien-Expansion bereit. Das Frontend wurde iterativ über mehrere autonome Agent-Läufe gebaut, mit Bead-basierter Aufgabenverwaltung und automatischer Validierung. Herausforderungen: Zeitzonen-Handling bei wiederkehrenden Events, Konflikt-Erkennung bei Überlappungen und saubere Migration des Schemas. Abgeschlossen über die Orchestrierungs-Pipeline mit automatischer Reconciliation der Aufgaben und Validierungsschleifen.

Nextcloud für einen kontrollierten Zugriff durch KI-Agenten vorbereitet. Dafür wurde ein eigener Benutzer sowie eine eigene Gruppe mit ausschließlich lesendem Zugriff auf ausgewählte Dokumentbereiche eingerichtet. Die technische Anbindung erfolgt über WebDAV. Wichtig war dabei, dass der Agent nur jene Dateien sehen kann, die explizit freigegeben wurden, statt Zugriff auf das gesamte Unternehmensarchiv zu erhalten. Schwierigkeit: Nextclouds Berechtigungssystem ist granular, aber die Kombination aus Benutzern, Gruppen und Ordner-Freigaben muss genau abgestimmt sein. Geprüft wurde, dass der WebDAV-Zugriff nur die freigegebenen Pfade auflistet und dass keine Meta-Daten oder Versionshistorien außerhalb des Freigabe-Umfangs zugänglich sind.

Nextcloud- und OnlyOffice-Integration nach einem Systemneustart untersucht. Tabellen wurden plötzlich heruntergeladen anstatt direkt im Browser geöffnet. Die Verbindung zwischen Nextcloud und Document Server wurde geprüft und der Office-Connector wieder korrekt initialisiert. Solche Fehler zeigen, dass nicht jeder funktionierende Dienst automatisch bedeutet, dass auch die komplette Integrationskette funktioniert. Schwierigkeit: Nach einem Neustart können Umgebungsvariablen oder Session-Daten verloren gehen, die für die Connector-Initialisierung nötig sind. Geprüft wurden die API-Verbindung zwischen Nextcloud und Document Server, die Token-Generierung und die korrekte Registrierung der Datei-Typen für den Browser-Editor.

PostgreSQL-Konfiguration eines ERP-Servers an die vorhandenen Hardware-Ressourcen angepasst. Optimiert wurden unter anderem shared_buffers, effective_cache_size, work_mem und maintenance_work_mem. Entscheidend war dabei, Speicher nicht einfach maximal zu vergeben, sondern parallele Queries und mehrere Sessions zu berücksichtigen, damit vermeintliche Performance-Optimierungen nicht zu RAM-Überbelegung führen. Schwierigkeit: Bei mehreren gleichzeitigen Sessions multipliziert sich der work_mem-Bedarf schnell. Eine zu hohe Einstellung führt zu OOM-Kills oder Swap-Nutzung, die die Performance weiter verschlechtert. Geprüft wurden die tatsächlichen Query-Muster, die maximale gleichzeitige Session-Zahl und das Verhältnis zwischen shared_buffers und dem OS-Page-Cache.

KI-Agent für österreichische Buchhaltung und EKR-Pflichten: Workspace-Setup mit Tryton-Anbindung, Verifikation der Buchungsperioden und Kontenrahmen-Analyse. Implementiert wurden Analysen zu EKR-20/21-Abrechnungen, B5422-Buchungen und E1a-Steuererklärungs-Kontext sowie die Auswertung von Bewertungserklärungen des Vorjahres. Der Agent arbeitet mit einem eigenen Memory-System und beantwortet Buchhaltungs-Fragen kontextbezogen auf Basis der Tryton-Daten. Herausforderungen: korrekte Zuordnung von Buchungssätzen zu EKR-Transaktionen, Umgang mit mehrperiodigen Daten und saubere Trennung von Analyse- und Buchungsvorschlägen. Die Integration in das Tryton-ERP erfolgt über API-Endpunkte mit Berechtigungsmanagement.

Verschlüsselungs- und Wiederherstellungsszenario bei Matrix-Element analysiert. Nach einem Gerätewechsel konnten neue Nachrichten verwendet werden, während ältere verschlüsselte Nachrichten ohne vorhandenen Recovery-Key nicht mehr verfügbar waren. Schwerpunkt war die praktische Bedeutung von Key-Backup und Recovery-Verfahren bei Ende-zu-Ende-verschlüsselten Kommunikationsplattformen. Schwierigkeit: Bei E2E-Verschlüsselung liegen die Schlüssel nur auf den Geräten. Ein Gerätewechsel ohne vorheriges Key-Backup bedeutet den unwiderruflichen Verlust aller historischen Nachrichten. Geprüft wurden die Recovery-Key-Generierung, die Sicherung auf einem sicheren Medium und die Wiederherstellung auf dem neuen Gerät.

Entwicklung einer autonomen Orchestrierungs-Pipeline, die OpenCode-Coding-Agenten über Cron-Läufe koordiniert. Hunderte autonome Runs mit Bead-basiertem Task-Tracking: Epic-Dekomposition, Dependency-Resolution, Pipeline-Idle-Erkennung und automatische Reconciliation abgeschlossener Beads. Implementiert wurden u. a. eine Plugin-Registry, CRUD-APIs für TODO- und Kalender-Module sowie eine Lizenzarchitektur für Marketplace-Plugins. Die Pipeline wechselt Modelle dynamisch (Qwen 27B lokal) und verarbeitet Blocker-Situationen durch Status-Reporting statt harter Abbrüche. Läuft als dauerhafter Hintergrundprozess mit täglicher Auswertung. Orchestriert werden OpenClaw, Hermez, Beads und Agentmemory als spezialisierte Agenten mit eigenen Skills und Memory-Schichten.

Tägliches automatisiertes SSL-Zertifikats-Monitoring als Cron-Job: Prüfung von Ablaufdaten und Gültigkeit aller relevanten Zertifikate, mit Warnungen bei Restlaufzeit unter Schwellwert. Zusätzlich implementiert ist ein Cleanup-Lauf, der verarbeitete Zertifikats-Snapshots (certs.json, latest.json) in ein Archiv-Verzeichnis verschiebt und alte Dateien nach Retention-Fristen bereinigt. Die Ergebnisse werden protokolliert und bei Auffälligkeiten proaktiv gemeldet. Der Lauf dient als Frühwarnsystem vor Zertifikats-Abläufen in der eigenen Infrastruktur und läuft zuverlässig im Hintergrund.

Automatisierte tägliche Job-Suche als Cron-Job mit Skill-basierter Implementierung. Abgefragt werden Jobportale (Karriere.at, Stepstone) sowie Direkt-Checks auf Karriereseiten ausgewählter Unternehmen. Der Qualitätsfilter priorisiert Remote-first-Positionen in Linux/DevOps, PHP, Golang, Shopware-Plugin-Entwicklung und E-Commerce in der Nahrungsergänigungs- und Wellness-Branche. Behandelte Robustheits-Probleme: Rate-Limits (429), CAPTCHAs, geänderte Portal-URLs und 403-Blockaden, jeweils mit Fallback-Strategien pro Quelle. Output nur bei echten Treffern, sonst stille Bestätigung. Ergebnisse werden mit Links und Kurzprofil je Position gemeldet.

Agent-Skill zur Extraktion kompletter Zammad-Tickets als strukturiertes Markdown oder Plain Text. Das Python-Skript nutzt die Zammad-API v6.4: Ticket-Metadaten, alle Articles inkl. HTML-zu-Markdown-Konvertierung und Anhangs-Referenzen. Behandelte API-Spezialitäten: buggy Ticket-Nummern-Suche (umgangen über interne IDs aus der URL) und eingeschränkte Token-Permissions (ticket.agent) mit Graceful-Degradation für 403- und 404-Endpunkte. Unterstützt werden Markdown-, Text- und JSON-Output sowie Dateispeicherung. Das Skill ist als wiederverwendbares OpenClaw-Skill mit .env-basierter Konfiguration paketiert.

Aufbau einer Multi-Agent-Infrastruktur auf Basis von OpenClaw mit mehreren spezialisierten KI-Agenten für Assistance, Buchhaltung, Monitoring, Orchestrierung und Audit. Jeder Agent besitzt eigene Skills, Workspaces und LLM-Modelle und wird über Matrix-Räume, Cron-Jobs und ein Signal-System koordiniert. Implementiert wurden u. a. tägliche E-Mail-Checks, automatisierte Job-Suchen, SSL-Zertifikats-Monitoring und Berichtsläufe. Die Agenten teilen eine gemeinsame Langzeit-Memory-Schicht mit Sessions, Lessons und Insights, während Heartbeat-Mechanismen proaktive Aufgaben ermöglichen. Die Matrix-Synapse-Integration stellt den Kommunikationskanal zwischen OpenClaw-Agenten bereit, mit dedizierten Räumen pro Agent und automatischer Routing-Logik. Läuft vollständig lokal ohne Cloud-Abhängigkeiten.

Betrieb einer lokalen LLM-Infrastruktur mit zwei GPU-Servern: RTX 5090 mit llama.cpp für GGUF-Modelle und RTX 3090 mit vLLM für optimierte Inferenz. Deployed wurden Qwen-27B-Modelle mit Autoround-Quantisierung für mehrere KI-Agenten. Behoben wurden u. a. Timeout-Probleme in der Nginx-vLLM-Proxy-Kette, SSE-Streaming-Interrupts und Timeout-Hierarchien zwischen Agent- und Provider-Konfiguration. Optimiert wurden Modell-Configs für Kontextlänge und Parallelität. Zusätzlich eingerichtet: GPU-Monitoring mit nvidia_gpu_exporter und Grafana-Dashboards für Auslastung, VRAM und Token-Raten. Alle drei OpenCode-Hosts wurden auf die lokale 27B-Instanz umgestellt. Die Infrastruktur dient als Backend für agentenbasierte Software-Entwicklung in VSCode mit Opencode, vLLM und llama.cpp.

Self-Hosted-Matrix-Homeserver im privaten Netzwerk als Kommunikationskanal für KI-Agenten. Jeder Agent besitzt eigene Matrix-Benutzer und dedizierte Räume. Gelöst wurden Konfigurations-Probleme für Homeserver im privaten Netzwerk: die OpenClaw-Konfiguration benötigt die explizite Freigabe privater Netzwerke (dangerouslyAllowPrivateNetwork), da Agent-Traffic über interne IPs läuft. Differenziert wurde zwischen 1:1-Räumen (kein autoReply nötig) und Gruppen-Räumen (autoReply erforderlich). Zusätzlich implementiert: Token-Management über CLI, Raum-Zuordnung pro Agent und saubere Trennung von Agent- und Mensch-Kommunikation. Die Anbindung von Agentzero an den Matrix-Synapse-Server erfolgt über dedizierte Benutzerkonten mit automatischer Raum-Zuweisung.