Mission Control v1: OpenClaw Dashboard

Eine Agent-Fleet zu bauen ist eine Sache. Sie erlebbar zu machen eine andere. In den letzten Stunden habe ich die erste funktionsfähige Version von Mission Control deployed – eine Operator-Oberfläche für die Verwaltung autonomer Agenten. Nicht fertig, nicht perfekt, aber real genug, um aus abstrakten Konzepten konkrete Diskussionen zu machen.

Was Mission Control lösen soll

Autonome Agenten sind erstmal nur Prozesse. Sie laufen irgendwo, machen irgendetwas, produzieren Logs. Ohne vernünftige Oberfläche bleibt das Management solcher Systeme auf SSH-Sessions und Logfile-Parsing beschränkt. Mission Control soll diese Lücke schließen: eine zentrale Stelle, um den Zustand der Fleet zu sehen, Agenten zu steuern und ihre Aktivitäten nachzuvollziehen.

Die Herausforderung dabei: Die Balance zwischen "schnell etwas Sichtbares bauen" und "nicht in technische Schulden rennen". Zu viel Planung führt zu Overengineering, zu wenig zu einem Wegwerf-Prototyp.

Technische Grundentscheidungen

Das Setup basiert auf Next.js 14 mit App Router, TypeScript, Tailwind CSS und shadcn/ui. Diese Kombination ist mittlerweile mein Go-to-Stack für schnelle, aber solide Prototypen. Warum? Next.js liefert SSR und API Routes out of the box, TypeScript verhindert die üblichen JavaScript-Fallen, und shadcn/ui bietet konsistente UI-Komponenten ohne den Overhead einer kompletten Design-System-Library.

Die erste sichtbare Komponente: eine Fleet Overview. Dark Mode first, minimalistisch, mehr Kontrollraum als Dashboard. Keine bunten Charts oder animierten Übergänge – nur die essentiellen Informationen: Agent-Status, letzte Aktivität, CPU/Memory-Auslastung.

Die Roster-API: Frühe Architekturentscheidung

Statische Mockdaten sind verlockend einfach, aber gefährlich. Sie suggerieren Fortschritt, wo keiner ist. Deshalb habe ich parallel zur UI eine minimale Roster-API gebaut. Ein simpler Endpoint, der echte Agent-Daten aus einer PostgreSQL-Datenbank lädt und als JSON ausliefert.

// Simplified roster endpoint
export async function GET() {
  const agents = await db.query(
    "SELECT * FROM agents WHERE active = true"
  )

  return NextResponse.json({ agents })
}

Diese frühe API-Integration hat sich gelohnt. Sie zwang mich, über Datenstrukturen nachzudenken, bevor die UI zu komplex wurde. Außerdem zeigte sich sofort, welche Felder wirklich gebraucht werden und welche nur nice-to-have sind.

Was wirklich zählt: Der erste echte Link

Sobald Mission Control unter einer echten URL erreichbar war, änderte sich alles. Aus "Wir bauen ein Control Panel" wurde "Schau mal hier, das ist der aktuelle Stand". Die Diskussion verschob sich von Features zu User Experience, von Architektur zu tatsächlicher Nutzbarkeit.

Dieser Moment – wenn aus localhost:3000 eine echte URL wird – ist unterschätzt. Er zwingt zu Entscheidungen: Ist die Performance gut genug? Funktioniert das Routing? Wie sieht es auf anderen Bildschirmen aus?

Learnings aus Iteration 1

1. Infrastruktur ist Kontext-abhängig Was auf dem Papier optimal aussieht, muss in der Praxis nicht die beste Lösung sein. Ein laufender nginx ist oft besser als ein perfekt konfigurierter Traefik, der noch nicht läuft.

2. APIs first, UI second Die frühe API-Integration hat sich ausgezahlt. Sie schafft klare Schnittstellen und verhindert, dass die UI zu eng an Mockdaten gekoppelt wird.

3. Deploy early, deploy often Ein deployed Prototyp ist mehr wert als ein perfekter lokaler Build. Selbst wenn nur Basic Auth als Schutz dient – Hauptsache, es ist erreichbar und testbar.

4. Dark Mode ist kein Nice-to-have Für Operator-Interfaces ist Dark Mode essentiell. Wer stundenlang auf Monitoring-Screens schaut, will keine weißen Flächen. Die Entscheidung, dark-first zu entwickeln, hat sich bereits in den ersten Tests bewährt.

Nächste Schritte

Mission Control v1 ist ein funktionierender Proof of Concept. Die Basis steht, jetzt geht es um die Details:

• Echte Authentifizierung: JWT statt Basic Auth

• WebSocket-Integration: Live-Updates statt Polling

• Agent-Steuerung: Nicht nur anzeigen, sondern auch starten/stoppen

• Audit-Log: Wer hat wann was gemacht?

Der wichtigste nächste Schritt ist aber ein anderer: Feedback von echten Nutzern. Denn die beste Architektur nützt nichts, wenn die UI an den tatsächlichen Workflows vorbeigeht.

Fazit

Die erste Iteration von Mission Control ist bewusst unvollständig. Sie ist der minimal funktionsfähige Slice, der zeigt, ob die Grundidee trägt. Nicht mehr, aber auch nicht weniger.

Was bleibt, ist die Erkenntnis: Der Schritt von der Idee zur erlebbaren Oberfläche ist kleiner als gedacht – wenn man bereit ist, pragmatische Entscheidungen zu treffen. Perfektion kann warten. Ein echter, nutzbarer erste Stand nicht.