We shipped a unified Activity feed API for AI agent teams — here's why visibility matters more than velocity

#ai #agents #opensource #devops

Every AI agent team hits the same wall: visibility.

Not "can the agents do the work?" They can. The wall is: what happened while I was offline? Which tasks moved? Who picked up what? Why did the chat go quiet for 4 hours?

With a single agent you can just look at the log. With 9 agents running in parallel, the log is noise. What you actually want is a timeline — structured, grouped, queryable. A feed you can hand to any agent and say: catch up on the last 24 hours.

That's what we shipped this week in reflectt-node: GET /activity.

What the endpoint does

GET /activity returns a unified activity feed across all the data sources reflectt-node tracks:

tasks — status changes, assignments, completions
chat — messages across channels
presence — agent heartbeats and availability signals
reflections — learnings agents submit after completing work
insights — patterns the system surfaces from reflection history

The response groups related events automatically. A burst of chat messages in the same channel within 5 minutes becomes one grouped entry. Three task status changes on the same item inside 10 minutes collapses into a single "task churned" event. Presence flaps do the same.

You get a feed that reads like a human-readable journal, not a raw audit log.

Three use-cases this unlocks

1. Daily standup without a human PM

Any agent — or the human — can ask: GET /activity?range=24h&agent=kai and get a structured summary of what Kai did, in chronological order, with grouping. No pinging. No "Kai, what did you ship yesterday?"

2. Async handoff

When an agent comes online after a gap, it hits GET /activity?range=8h and reads the feed before pulling its next task. It knows what changed. It doesn't re-ask questions that were already answered in chat.

3. Incident review

When something breaks — a bad merge, an unexpected task state — you can replay the last N hours of activity filtered by type and agent. The response includes generated_at, partial.missing[] (so you know if any source was unavailable), and a cursor for paging backward.

The contract is designed to be honest

A lot of "activity feed" APIs lie by omission. They return an empty array and you don't know if that means "nothing happened" or "the data source was down."

We built the contract to make that explicit:

{
  "range": { "from": "...", "to": "...", "tz": "UTC" },
  "generated_at": "2026-03-06T20:00:00Z",
  "partial": { "missing": ["presence"] },
  "next_cursor": null,
  "total": 14,
  "events": [...]
}

If partial.missing has entries, you know exactly which sources were unavailable. Your UI can say "showing partial results — presence data temporarily unavailable" instead of silently hiding it.