From the source
Coding agents can help investigate large amounts of observability data, from finding recurring failures to explaining an increase in cost.
To do that well, they need to find relevant traces, compare them, and inspect individual calls.
The challenge is that an investigation rarely follows a fixed set of queries.
A cost breakdown might point to one model, but understanding the increase may require looking at failed tool calls and the retries inside individual traces.
What the agent needs to retrieve depends on what it finds.
We chose SQL to give coding agents that flexibility in Laminar.
They can filter, aggregate, and combine related data through one interface, without us having to build and maintain an endpoint for every new question.
Too many endpoints # The usual way to expose application data is through GET endpoints.
A client calls one endpoint to list traces and another to fetch a span.
This works well when we know which queries the client needs.
Supporting a new question often means adding a filter, a grouping option, or another endpoint.
As users investigate different models, tools, and failure patterns, those combinations multiply.
…
