Agents are now opening PRs against production codebases. They need real-time signals about which errors are firing in production before they pick what to work on — and most observability vendors don't ship the right shape of endpoint for that job.
An AI agent that ships code — a Coder1 mission, a CloudSwarm worker, a Claude-driven autofix pipeline — runs the same loop a human engineer runs. Look at what's broken in production. Decide what to work on. Open a PR. The difference is that the agent pays for every token it reads, and it has no intuition for which dashboard rows are worth opening. Sentry's query API is built for human dashboards: paginated event lists rendered into HTML and clicked through. CodeRadar's /api/events/aggregate is built for an agent to call programmatically and use the response directly.
Picture an AI fix-pipeline that runs every morning. It reads the last 24 hours of production errors, picks the top three by impact, opens triage PRs that include a regression test and a candidate diff, and posts a Slack note. To do that well it needs a pre-rolled view of production: which routes are throwing, which users are most affected, which fingerprints are new this window versus continuing from yesterday. The agent does not want a 50-row paginated list of individual events. That list is mostly noise. It wants the rollup.
Without an aggregate API, every agent has to do one of two bad things. It can hit a general-purpose /events endpoint and roll the rows up itself — expensive in tokens, expensive in network round-trips, and every agent re-implements the same aggregation logic. Or it can live-query the underlying ClickHouse cluster directly — faster but a security and cost problem, because now every downstream agent needs read credentials on the warehouse and any one of them can write a runaway query. The aggregate API is the third option: the dashboard service does the rollup once, in a controlled environment, and hands back a small JSON blob that any agent can consume.
It's a single GET. Two query parameters: hours (1–168, default 24) and product (slug, optional). Response shape:
{
"hours": 24,
"total_events": 1842,
"by_route": [{ "route": "/api/checkout", "count": 412 }, ...],
"by_user": [{ "user_id": "u_91...", "count": 38 }, ...],
"top_traces": [
{ "fingerprint": "a1b2c3...",
"count": 412,
"sample_message": "TypeError: Cannot read properties of undefined" },
...
],
"summary": "In the last 24 hours, /api/checkout produced 412 errors driven primarily by a TypeError in cart-validator.ts. 38 distinct users were affected. The next-largest fingerprint is a 502 from the Stripe webhook handler (104 events)."
}The pre-rendered summary string is the kicker. Agents can paste it directly into a Claude or GPT prompt without re-tokenizing the structured arrays beneath it. Typical response is under two kilobytes — well under one thousand tokens — versus five thousand or more for a comparable Sentry Discover query that the agent then has to summarize itself.
Here's an agent fetching the last 24 hours of aggregate data and feeding the summary string into a Claude call to decide which fingerprint is worth investigating:
const aggregate = await fetch(
'https://api.coderadar.app/v1/events/aggregate?hours=24&product=checkout',
{ headers: { 'Authorization': `Bearer ${process.env.CODERADAR_API_KEY}` } }
).then(r => r.json());
const claudeResp = await anthropic.messages.create({
model: 'claude-opus-4-7',
messages: [
{
role: 'user',
content: `Recent error summary: ${aggregate.summary}\n` +
`Which top_trace looks like a real bug vs noise? ` +
`Top traces: ${JSON.stringify(aggregate.top_traces)}`
}
]
});The agent never has to walk a paginated event list, never has to invent its own aggregation shape, and never has to write the natural-language framing that Claude needs as context. The endpoint did all of that server-side. The agent's next action — "open a PR fixing fingerprint a1b2c3" — is now grounded in production reality, not in stale issue tickets or static analysis.
Sentry exposes /api/0/projects/{org}/{proj}/events/ — a paginated event list intended for the dashboard's "Issues" view. To get an aggregate view an agent has to hit the Discover endpoint with a hand-written query, paginate the results, and roll up totals itself. Excellent for analysts; token-expensive for agents. Datadog's /api/v2/logs/events is similar in shape: powerful query language, paginated raw events, no pre-rolled summary. Honeycomb has a more powerful general-purpose query API and supports server-side rollups in its query DSL, but it does not ship a fixed aggregate-shaped endpoint that an agent can call without authoring a query body. CodeRadar's /api/events/aggregate is intentionally narrower — one shape, optimized for agents, no query DSL to learn.
CloudSwarm's portfolio-error-summary skill calls this endpoint every morning with the internal key (no product filter) to produce a portfolio-wide rollup. Coder1 missions consume the per-product variant before opening a PR. Any portfolio sister product can drop in the call with three lines of code. Because the endpoint is rate-limited per key (60 requests per minute) and Bearer-only, dropping it into a new agent is an exercise in pasting an API key — no cookie handshake, no SDK install, no schema discovery.
The next iterations of the endpoint will add window comparison ("today versus yesterday for the same window"), a per-fingerprint detail endpoint for agents that want to drill into one trace, and webhook fanout when an aggregate threshold trips so an agent can be triggered by the rollup rather than polling for it. All of those are forward-looking. Today's /api/events/aggregate is the load-bearing primitive: one shape, agent-shaped, ready to call.
Full endpoint spec at /docs/API/AGGREGATE-ENDPOINT.md. Route source on GitHub. Cross-reference: the SDKs page for the language clients that emit the events this endpoint aggregates.