Skip to main content
This page traces one investigation end to end, so you can see what an agent actually does with the REST API — and judge whether its conclusions are grounded. The prompt:
Explain why traces in the past 24 hours have been having more errors, and tell me where to investigate.
Every request below is plain GET against https://api.mirador.org with a server key. An agent briefed with llms.txt composes these itself; nothing here is special to AI — you could run the same requests by hand.

​
Step 1 — Quantify the spike

First, is there actually a spike? The agent counts error traces in the last 24 hours and in the 24 hours before that. Setting per_page=10 makes pagination.total do the counting — two cheap requests, exact numbers.
The agent also counts all traces in both windows (drop the filter) to rule out “more errors because more traffic”: total volume is flat, so the error rate is genuinely up ~3.5×.

​
Step 2 — Discover the dimensions

Before slicing, the agent asks the project what fields exist, so its filters use real names rather than guesses:

​
Step 3 — Find where errors concentrate

Now the agent re-runs the error count from Step 1, once per slice, and compares totals. Each slice is one request:
Three requests in, the shape of the answer exists: the spike is bridge traces involving Polygon. The agent can also narrow when it started by bisecting since — errors were flat until ~22:40 UTC, then jumped.

​
Step 4 — Read the evidence

Counts say where; event timelines say why. The agent lists a few recent matching traces and pulls their full timelines:
In each timeline, the same pattern: a bridge_detected event on the source chain, then no bridge_matched within the expected window, then an error_event_added like:
Consistent story across all sampled traces: destination legs on Polygon stopped being observed — pointing at the Polygon ingestion path or the bridge itself, not user error or a code regression in the app.

​
Step 5 — Report with pointers

The agent’s answer, grounded in the requests above:
Errors are up ~3.5× (61 → 214) over the last 24h, and 171 of the 214 are bridge traces with attribute.chain="polygon". The spike began around 22:40 UTC on July 14. Sampled event timelines (e.g. traces 4bf92f35…, 9a1e6c0b…, 7b3d4f88…) all fail the same way: the source-chain leg is detected, but no destination transaction is observed on Polygon within the 900s window, producing a bridge-leg timeout. Where to investigate:
  1. The Polygon ingestion path (WebSocket endpoint health, ingestor logs) from ~22:40 UTC onward — if Mirador stopped seeing Polygon transactions, everything downstream times out.
  2. The bridge’s Polygon-bound deliveries in the same window, in case the bridge itself degraded.
  3. Open the sampled traces in the dashboard to confirm the pattern holds beyond the sample.
That’s the whole loop: two counts to confirm the spike, three counts to localize it, a handful of timelines to explain it — roughly a dozen read-only requests.

​
Adapting the pattern

The same count → slice → read timelines → report loop answers most investigative questions; only the filters change:

​
Next Steps

Connect an agent

Set up Claude Code or a custom agent to run this loop

Filter syntax

The AIP-160 grammar behind every slice above