Skip to content

Workspace Control

Workspace Control — die Kommandozentrale für deinen LinkWorld-Tenant

Section titled “Workspace Control — die Kommandozentrale für deinen LinkWorld-Tenant”

Workspace Control ist die Admin-Übersicht für alles was in deinem Tenant läuft: welche Apps installiert sind, welche Agents welche Skills haben, welche Heartbeats wann feuern, welche Cross-App-Wires und Grants existieren, welche Group-Rooms Inhalte sammeln. Plus der Steward — ein Chat-Agent der dir Empfehlungen zur Konfiguration gibt und (perspektivisch) Konfigurations-Aktionen auf Zuruf ausführt.

Wenn du nicht weißt warum eine App keine Mails mehr sendet, wer auf welches Event subscribt, ob ein Heartbeat heute Nacht gefeuert hat, oder welchen Agent ein bestimmter Skill nutzt — das findest du hier. Schneller als durch Logs zu greppen, weil alles querverlinkt ist.

5 Screens auf einer Oberfläche:

  1. Workspace Dashboard — eine Baumansicht aller Apps → Agents → Heartbeats. KPIs pro App (Touches heute, Drafts pending, Erros), Status-Indikatoren (running / paused / disabled), Health-Counts (running containers / scheduled jobs / last-error count).
  2. Agent Detail — pro Agent: System-Prompt (read-only, oder editable je nach App-Typ), erlaubte Skills, Knowledge-Skills (RAG-Bindings), MCP-Server-Konfiguration, Routing-Hints, Conversation-Mode + Model-Tier.
  3. Wires & Grants Editor — visualisiert welche App welcher anderen App ctx.apps.invoke rufen darf, und welche Events welche Subscriber haben. Bilateral-Approval-UI: ausstehende Wires von anderen Apps sehen + accepten/declinen.
  4. Group-Rooms List + View — alle aktiven Group-Rooms (Channels mit Mehr-Agent-Membership), neueste Posts, Memberships. Vom Daily Digest der Inbox-Manager bis zum tagsüber-laufenden Office-Channel.
  5. Conversational Control (Steward chat) — Chat-UI gegen den Steward-Agent. Sag ihm was du willst (“Pausiere die DM-Heart- beats heute”, “Welcher Agent eskaliert URGENT-Mails?”), er übersetzt’s in Workspace-Konfiguration. Heute advisory-only — er sagt dir was zu tun ist und verlinkt die richtigen Screens. In nächsten Releases (M3.14.1+) führt er Routine-Aktionen direkt aus.

Approval-Queue ist bewusst NICHT in Workspace Control eingebaut — Approvals laufen weiter durch die existierende /governance UI. Workspace Control verlinkt nur dorthin.

  1. Aktivieren vom Marketplace. Keine Scopes nötig — Workspace Control liest gegen die internen Platform-APIs (/api/admin/workspace/*) mit der Tenant-Session des Users.
  2. Öffnen aus der Sidebar. Der Default-View ist das Dashboard mit der Baumansicht. Klick auf eine App → expanded zu Agents + Heartbeats; Klick auf einen Agent → Detail-Modal.
  3. (Optional) Group Rooms anlegen — wenn deine Apps Digests oder Notifications in Rooms posten (z.B. Inbox Manager Daily Digest), findest du die Room-UUIDs hier zum Reinkopieren in die anderen App-Settings.

Es gibt nichts zu konfigurieren — alle Daten kommen aus dem Tenant-State und die App ist read-only-by-default.

Workspace Control im Browser aufrufen. Der Dashboard-Tree zeigt sofort:

  • Welche App hat heute Errors gehabt? → roter Indicator, Click auf “Errors” linkt zur App-spezifischen Activity-View.
  • Welcher Heartbeat ist gescheitert / disabled? → graues Icon statt blau-pulsierend, Tooltip zeigt last-run-time + last-error.
  • Welche Cross-App-Wires sind pending Approval? → Badge oben rechts (“3 pending”), Click navigiert zum Wires-Editor.

Workspace Control selbst tut nichts pro-aktiv — kein Email, keine Notification, kein Schedule. Du gehst da rein wenn du was wissen willst, oder wenn ein anderer App-Surface (Sales Guy, Inbox Manager) dich dorthin verlinkt (“Sales Guy hat heute 0 Touches gesendet — check Wires & Grants”).

Wenn ein Builder eine neue App installiert die Sales Guy oder Pipeline rufen will, landet eine Pending-Wire in Workspace Control. Wires & Grants Editor → Pending Tab:

  • Verträgt sich die anfragende App + der Use-Case mit deiner Tenant-Policy? Approven / declinen.
  • Default: Same-org Apps werden auto-approved beim install (siehe cross_app_dependencies in app-manifests). Nur fremd-publisht Apps brauchen explizite Tenant-Approval.

Group Rooms sind tag-übergreifende Multi-Agent-Channels (anders als 1:1-Conversations). Ein typischer Pattern: Inbox Manager postet abends den Daily Digest in Inbox Summary, Office Assistant postet URGENT-Eskalationen in den selben Raum, du liest’s wenn du Zeit hast.

Workspace Control → Rooms Tab:

  • Liste aller aktiven Rooms (Title, Member-Count, Last-Post-Time)
  • Klick auf Room → Reader-View mit den letzten 50 Posts
  • Wenn ein Room sich verselbständigt (zu viel Noise von einer App): Member entfernen oder Room archivieren

#/chat-Subroute. Stell direkte Fragen oder nenn Konfigurations- Wünsche:

  • “Welcher Agent eskaliert URGENT-Mails?” → er findet’s und verlinkt das Agent-Detail
  • “Wieviele Touches hat Sales Guy gestern abgesetzt?” → er aggregiert das aus dem audit-log
  • “Pausiere die Sales-Guy-Heartbeats über das Wochenende” → heute: er sagt dir wo du das im UI machst; ab M3.14.1: führt’s direkt aus mit explizitem Confirm

Sicherheits-Pattern: der Steward führt nie Aktionen ohne explizite User-Confirmation aus, und nie Aktionen in fremden Tenants. Wenn er sich unsicher ist, fragt er nach — er rät nicht.

  • Read-Mostly: heute (v0.5.1) ist die App read-only mit minimalen Mutations (Room-Archivierung, Wire-Approve/Decline). Die Steward- Chat-Aktionen sind advisory, nicht ausführend.
  • Realtime-Updates: Dashboard-KPIs werden alle paar Sekunden refreshed; ein Heartbeat-Fail erscheint binnen ~30s als Error im Tree.
  • Per-Tenant-isoliert: kein User sieht jemals Workspace-Data eines anderen Tenants. Auch der Steward kann nicht cross-Tenant agieren.
  • Kein Persistierung außerhalb der Plattform-DB: Workspace Control legt keine eigenen Records an. Alles was du siehst ist Live-Read gegen linkworld_apps, linkworld_app_agents, linkworld_app_data_feeds, linkworld_app_grants, linkworld_group_rooms und Friends.

“Das Dashboard zeigt eine App die ich nie installiert habe” — das sind first-party Platform-Apps (z.B. Steward-Adapter, Workspace-Control selbst, System-Agents). Sie sind tenant-aktiv auch ohne Marketplace-Install und gehören zum Plattform-Kern. Du kannst sie pausieren aber nicht deinstallieren.

“Wires-Editor zeigt ‘pending’ für eine App die ich nicht kenne” — bevor du approve klickst: schau dir die App im Marketplace an (Link am Editor-Eintrag). Wenn der Publisher nicht in deiner Org/Whitelist ist, decline + im Marketplace-Filter “blocked” markieren.

“Steward gibt nur ‘verlinke dich zu /wires’ als Antwort” — korrekt für v0.5.1. Action-Execution kommt mit M3.14.1+. Bis dahin nutzt du die UI direkt.

“Heartbeat-Tree zeigt blau aber die App passiert nichts” — der Tree zeigt Schedule-Status (= ist der Cron-Job eingerichtet?), nicht Execution-Status (= hat er erfolgreich gefeuert?). Klick auf den Heartbeat → siehst last-run-timestamp, last-error, next-run-schedule. Wenn last-run > schedule-interval ist, fired nichts mehr — typisch wenn die App auto-disabled wurde nach 5 consecutive failures.

“Ich sehe Agents die nicht zu Apps gehören” — diese sind Standalone-Agents (manuell angelegt oder Vision-generated). Im Tree sind sie unter Independent Agents gruppiert. Workspace Control zeigt ihren Source (manifest / vision / manual-create) + ihre Kpln-Settings.

“Conversational Control startet nicht / kein Chat-Frame” — der Steward braucht eine aktive User-Session mit gültigem Auth-Token. Wenn du eine 401-Fehler in der Browser-Console siehst: re-login.

This section is auto-generated from the app’s manifest. It updates whenever the app publishes a new version.