Agent observability is based on similar primitives as regular observability (OTEL), but is wildly different. Trace payloads are huge, and errors are much more subtle, they are not increased latency or elevated 500 response rate. We recommend tracing everything in detail, and reading a few traces manually at the beginning while you iterate. At scale, the answer is almost always use another LLM look at your traces, which is what this post is all about.

Evals are critical. I really recommend adopting the Anthropic's capability / regression eval model [1]. We also deeply believe that agent evals should be end-to-end, and as high-level as possible. This again often involves a quality LLM-as-a-judge, tuned on a set of manually labelled data.

With this idea in mind (to answer your question), we think that, for eval datasets, the most crucial bit is to be able to store input of what your agent was asked about in production. Collect a certain distribution of inputs for happy and unhappy cases, and then run evals on those inputs. That's why Laminar went great lengths to help our users automatically get actual inputs their users send to their agents [2].

[1] https://www.anthropic.com/engineering/demystifying-evals-for...

[2] https://laminar.sh/blog/extracting-tasks-from-agent-runs

Also, some of what you describe sounds expensive. Do you find these techniques + cheaper models better than single-shot with larger models?

[1] https://laminar.sh/blog/2025-12-03-claude-agent-sdk-instrume...