Agent activity

A long generation can hold the inference server for minutes. Without a shared view, it is visible only on the screen that started it. The agent activity card fixes that. It is fed by ActivityService.SubscribeAgentActivity.

What you see

Each run shows its agent (for example pulse:whitepaper), its status (running, done, or failed), and its steps. PULSE has no multi-step reasoning loop, so one generation is usually one step. The useful parts are the model, the token count, and the latency.

A step can also carry provenance: whether the answer is fresh or reused from a cache, and whether it was produced in a degraded mode. A healthy, fresh answer shows nothing extra. The card calls out only reused, offline, or degraded answers.

Whose runs you see

By default you see your own session’s runs. The server uses the session field of the request, or, when that is empty, the caller’s x-agent-trace-id header.

Work started without a request behind it (a schedule, a WhatsApp message, an A2A call, a background engine) has no session. A scoped subscriber does not see those runs. Only a subscriber that sends neither a session nor a trace ID gets the ambient view of everything. An operator console does that on purpose.

Opening the page mid-run

When you subscribe, the server first replays every run in progress, with the steps recorded so far. Then it sends snapshot_complete, and after that live events. So a page opened halfway through a run still shows that run.

The featured strip

ActivityService.ListFeaturedMessages returns operator-written sponsor and partner cards for the rotating strip. The server reads them from a file named by FEATURED_MESSAGES_PATH. When that is unset, it looks for a file named featured_messages.json in /app, the working directory, data, and /app/data, in that order. No file means an empty strip, not an error. You can change the cards without rebuilding the app.