Found by the sprint agents during the AX audit. Verified directly against production with a live runtime token.
GET /api/agents/runtime/pods/:podId/messages caps at 50 and silently discards every pagination parameter:
limit=5 -> 5 honoured
limit=200 -> 50 clamped, fine
limit=5&before=2026-08-01T00:00:00Z -> 5 same 5 newest — before IGNORED
limit=5&offset=10 -> 5 same 5 newest — offset IGNORED
An agent asking "what happened before this point?" receives a plausible answer to a different question, with nothing indicating anything was dropped. On the sprint pod (247 messages) an agent can reach 50, back to 2026-07-30T10:57.
Why this blocks the sprint spine. Attention routing's judge compares an action to the intent the agent accepted. Finding that intent means reading back to where it was stated — roughly four hours on this pod, and unreachable. The feature cannot work on top of this route.
The underlying model already supports it. PGMessage.findByPodId(podId, limit, before) takes a cursor and the human-facing /api/messages/:podId uses it (see #767, which added the frontend half). The agent route simply never passes it through — so this is wiring, not new capability.
The generalizable defect, and the agents' framing of it: silently ignoring an unsupported argument is worse than rejecting it, because the caller gets a plausible answer to a different question. An agent has no human to ask whether before is supported; it can only infer from the response, and the response lies. That belongs in the AX audit as a class, not just this instance — a 400 naming the unsupported parameter would have cost one request and saved the inference.
Fix shape
- Pass
before through to findByPodId, as the human route does.
- Reject unknown/unsupported query params explicitly rather than dropping them.
- Return whether more history exists, so a caller can tell "end of history" from "end of page" — the human route infers this from a short page, which works but is implicit.
Same defect class as #767 (pagination missing on the human side) but nastier: there the capability was absent, here it appears present and lies.
Found by the sprint agents during the AX audit. Verified directly against production with a live runtime token.
GET /api/agents/runtime/pods/:podId/messagescaps at 50 and silently discards every pagination parameter:An agent asking "what happened before this point?" receives a plausible answer to a different question, with nothing indicating anything was dropped. On the sprint pod (247 messages) an agent can reach 50, back to
2026-07-30T10:57.Why this blocks the sprint spine. Attention routing's judge compares an action to the intent the agent accepted. Finding that intent means reading back to where it was stated — roughly four hours on this pod, and unreachable. The feature cannot work on top of this route.
The underlying model already supports it.
PGMessage.findByPodId(podId, limit, before)takes a cursor and the human-facing/api/messages/:podIduses it (see #767, which added the frontend half). The agent route simply never passes it through — so this is wiring, not new capability.The generalizable defect, and the agents' framing of it: silently ignoring an unsupported argument is worse than rejecting it, because the caller gets a plausible answer to a different question. An agent has no human to ask whether
beforeis supported; it can only infer from the response, and the response lies. That belongs in the AX audit as a class, not just this instance — a 400 naming the unsupported parameter would have cost one request and saved the inference.Fix shape
beforethrough tofindByPodId, as the human route does.Same defect class as #767 (pagination missing on the human side) but nastier: there the capability was absent, here it appears present and lies.