Snowflake announced Agent Observability for Observe, a product coming soon to private preview that will trace AI-agent workflows and expose performance, quality, and cost signals. For engineering teams, the important shift is treating agent quality and spend as observable production behavior—not just checking whether requests complete without errors.
Source: Improve AI Performance, Quality and Cost with Agent Observability — September 22, 2026.
What’s coming
Agent Observability is designed to help teams inspect how interactions unfold, find where problems start, and relate agent behavior to cost and business outcomes. Snowflake says the capability is coming soon to private preview; it is not described as generally available.
| Area | Planned capability |
|---|---|
| Instrumentation | An optional OpenTelemetry-compliant SDK, or existing instrumentation sent through an OTLP endpoint, can capture prompts, completions, retrievals, tool calls, token usage, and session IDs. |
| Framework support | The SDK includes tested and verified support for LangChain, the Anthropic Agents SDK, and the OpenAI Agents SDK. Teams can also instrument custom frameworks. |
| Investigation | Agent Explorer will let teams search traces, sessions, and conversations, then inspect tool calls and the point where a failure or unexpected response began. |
| Monitoring | Metrics derived from traces include latency, errors, and estimated cost. |
| Quality evaluation | Online LLM-as-judge evaluations will assess production traffic; results can be connected to the underlying spans and traces. Existing offline evaluation results can also be sent in as traces or metrics. |
| Programmatic access | APIs will allow queries of traces, metrics, and online evaluation results from third-party agents and automated workflows. |
These are planned capabilities, not a statement that every evaluation or integration will work automatically for every system. Teams will still need suitable instrumentation and evaluation workflows.
Why agent observability is different
A successful request can still produce a wrong or low-quality answer. Traditional request-level signals such as latency and errors do not establish whether an answer was accurate, relevant, or useful. For agents, engineers need enough context to examine what the system retrieved, which tools it called, how it retried, and how intermediate outputs shaped the final response.
That detail creates a retention challenge. Agent traces can run longer and contain more spans than traditional application traces because they capture model calls, retrievals, tool invocations, retries, and intermediate outputs. Sampling or dropping telemetry may reduce storage pressure, but it can also leave gaps when a team needs to investigate a particular interaction.
Observe’s approach stores spans as events and queries them by trace ID and conversation ID, with the aim of keeping late-arriving spans and long gaps within the complete interaction. Snowflake also points to its support for semi-structured data to retain prompts, responses, retrieved context, and tool inputs and outputs, and to cloud object storage and separated storage and compute as ways to manage telemetry economics. These are architectural claims about the product’s design; teams should evaluate retention costs and query performance against their own workloads.
Cost, quality, and business outcomes belong together
Token totals alone do not tell a team whether AI spend is worthwhile. The factors behind consumption—model choice, prompt size, retrieved context, tool use, retries, and workflow design—also affect performance and quality. Trace-derived usage and estimated-cost signals can help engineers locate inefficient execution paths, such as retries or expensive model choices that do not improve evaluation results.
The more consequential step is connecting those operational signals to outcomes. Snowflake describes correlating agent behavior with business data, including customer experience, resolution rates, conversion, revenue, task completion, and employee productivity. That can help teams assess whether a cheaper model’s quality trade-off is acceptable, or whether a more expensive model delivers enough improvement to justify its cost. The article does not specify how these outcome measures will be configured for each organization.
Where Dataonia fits
The connection to financial diagnostics is relevant when teams need to interpret technology spend alongside business performance. AI agents for FP&A and diagnostics is a way to explore that analytics context; it does not replace instrumenting or tracing agent workflows in Observe.
What to do
- Map the workflow before choosing signals. Identify the agent’s model calls, retrievals, tool invocations, retries, and supporting services so investigations have a useful path through the interaction.
- Check instrumentation coverage. Decide whether to use the optional SDK, existing instrumentation, or custom instrumentation sent through OTLP. Confirm that the captured fields are sufficient to reconstruct the interactions you need to debug.
- Define quality measures. Decide which failures matter for your use case, then assess whether online LLM-as-judge evaluations and existing offline evaluations can help monitor them.
- Attribute cost beyond token totals. Examine model choice, prompt and retrieval size, tool use, and retries alongside latency and quality signals.
- Connect operational measures to outcomes. Determine which business measures can help distinguish lower spend from better value; the relevant measures will depend on the application.
- Review telemetry economics. Estimate what detail you need to retain and query, and test whether the proposed retention and compute approach fits your cost and investigation requirements. For a broader cloud-spend review, use Where Cloud Bills Hide Their Waste: A Practical Audit Checklist.
FAQ
Is Agent Observability available now?
The article says it is coming soon to private preview. Teams interested in access are directed to contact their Observe account team.
Does it require Snowflake’s SDK?
No. The article describes an optional OpenTelemetry-compliant SDK, existing instrumentation, custom frameworks, and sending properly instrumented traces through an OTLP endpoint.
Can it determine whether an agent is useful?
It can support that assessment by connecting quality evaluations and operational signals with business data. The usefulness of the result depends on the evaluations and outcome measures a team brings to the analysis.