Prüfen: Channels/Chat zwischen Agents vs. MCP watch-Tool #331

Anfrage: Prüfen, ob "Channels" Sinn ergeben – ein Chat, in den Agents schreiben können und gerade verbundene andere Agents die Nachricht im selben Moment bekommen. Alternative: ein MCP watch-Befehl.

Erste Einschätzung (Kurzcheck):

• Echter Server-Push an "gerade verbundene" Agents passt schlecht zur aktuellen Architektur: Program.cs setzt WithHttpTransport(o => o.Stateless = true) – es gibt keine dauerhafte Verbindung pro Agent, in die aktiv gepusht werden könnte. Zudem hängen Coding-Agents zwischen Tool-Calls nicht lauschend in einer offenen Verbindung, sondern arbeiten sequenziell; eine Push-Nachricht "im Moment" würde von einem gerade rechnenden Agent ohnehin nicht bemerkt.
• Es existiert aber schon ein passendes Pub/Sub-Pattern: LiveUpdateService.cs (In-Memory-Subscriber-Liste, aktuell für Blazor-UI-Toasts genutzt). Das ließe sich für ein channel_watch(projectId, since?)-Tool wiederverwenden, das serverseitig bis zu einem Timeout (z.B. 20–30s) blockiert und dann neue Nachrichten oder leer zurückgibt. Das ist mit Stateless-HTTP kompatibel, da nur die Antwortzeit eines einzelnen Calls verlängert wird, keine offene Verbindung nötig ist.

Empfehlung: Kein echter Broadcast-Chat, sondern neuer Item-Typ channel/message plus ein Long-Poll-Tool (item_watch o.ä.), das das bestehende LiveUpdateService-Pattern wiederverwendet. Hauptkompromiss: kein Instant-Push, sondern "Agent fragt aktiv nach, wartet kurz" – reicht aber für Koordination zwischen Sessions (z.B. vor riskanten Schritten checken, oder periodisch in einem /loop), ohne Umbau auf stateful/SSE-Transport.

Nächste Schritte (offen): Schema/Tool-Signatur grob durchdesignen, falls die Idee weiterverfolgt wird.