[bug] Agent detail endpoint omits event_count and worst_mad returned by the agents list

[d180]

What went wrong

The agent detail endpoint /api/agents/{agent_id} returns event_count = 0
and worst_mad = "" even when the same agent is shown with non-zero event
activity and a populated worst MAD value in /api/agents.

This makes the backend response inconsistent across two endpoints describing
the same agent.

The current agent detail page does not visibly render these two top-level
fields yet, so this is primarily an API/data-consistency issue at the moment.
However, it is already frontend-facing through the detail endpoint response
and could surface directly in the UI if those fields are used there later.

---

Reproduction steps

1. Start Adrian locally and sign in to the dashboard.
2. Ensure there is an agent with at least one event and one verdict.
3. Query /api/agents and note the event_count and worst_mad values for
   that agent.
4. Query /api/agents/{agent_id} for the same agent.
5. Observe that the detail response returns event_count = 0 and worst_mad = "" even though the list response returned populated values.

---

Expected behaviour

The agent detail endpoint should return the same top-level agent stats as the
agents list for the same agent, including:

• event_count
• worst_mad

---

Actual behaviour

For the same agent:

• /api/agents returns populated event_count and worst_mad
• /api/agents/{agent_id} returns event_count = 0 and worst_mad = ""

---

Environment

• Adrian version / commit: stub-local-dev-mode locally for reproduction
• OS: macOS arm64
• Docker version: Docker version 29.4.3, build 055a478
• GPU model (if relevant): not relevant

---

Logs

Click to expand

GET /api/agents

{
  "data": {
    "agents": [
      {
        "id": "agent-row-test-1",
        "agent_id": "agent-test",
        "agent_profile_id": "",
        "agent_profile_name": "",
        "first_seen": "2026-05-16T10:00:00.000Z",
        "last_seen": "0001-01-01T00:00:00.000Z",
        "event_count": 1,
        "worst_mad": "M3.a"
      }
    ],
    "total": 1,
    "page": 1,
    "per_page": 20
  }
}

GET /api/agents/agent-test

{
  "data": {
    "id": "agent-row-test-1",
    "agent_id": "agent-test",
    "agent_profile_id": "",
    "agent_profile_name": "",
    "first_seen": "2026-05-16T10:00:00.000Z",
    "last_seen": "0001-01-01T00:00:00.000Z",
    "event_count": 0,
    "worst_mad": "",
    "sessions": [
      {
        "session_id": "sess-test-1",
        "started_at": "2026-05-16T10:05:00.000Z",
        "ended_at": "2026-05-16T10:05:00.000Z",
        "event_count": 1
      }
    ]
  }
}

---

Relevant code paths

backend/internal/store/agents.go

The list query used by ListAgents(...) computes both:

• event_count
• worst_mad

The single-agent query used by GetAgent(...) does not select either of those
fields.

backend/internal/api/handlers_agents.go

The detail handler still serializes the result through agentRowToEntry(...),
which includes event_count and worst_mad in the response shape. Because
GetAgent(...) never populated them, they are returned with zero values.

frontend/app/(dashboard)/agents/page.tsx

The agents list uses the populated values from /api/agents.

frontend/app/(dashboard)/agents/[agent_id]/page.tsx

The detail page currently consumes /api/agents/{agent_id}. It does not
currently render event_count or worst_mad, which is why this is presently an
API/data-consistency issue rather than a direct visible rendering bug.

---

Likely fix

Update GetAgent(...) to compute and return the same top-level aggregate fields
as ListAgents(...), so the detail endpoint stays consistent with the list
endpoint for the same agent.

---

Offer to contribute

I’d be happy to open a PR for this if that approach sounds right.

[shahtajkhalid]

Thanks for the report, @d180 !

Confirmed, GetAgent doesn't SELECT event_count or worst_mad, so they come back as zero values from /api/agents/{agent_id}. The dashboard itself is rendering correct data today since the detail page doesn't read those fields and the list page uses ListAgents, but the API response is still inconsistent and worth fixing.

Please feel free to raise a PR, we'd be happy to review and merge it.

[d180]

Sure, will work on that and raise a PR as soon as possible.