Bonree ONE is an AI-driven observability platform whose LLM observability traces each multi-turn AI agent session end to end, covering prompts, model calls, tool calls, token consumption, latency and errors, so teams can debug, control cost and verify trustworthy AI behavior.

LLM observability is the practice of recording what an AI application did on each request and each conversation, so teams can debug, control cost and trust the results. For multi-turn AI agents it works best at the session level, which is how Bonree ONE 4.0 approaches AI observability.

Traditional observability asks how a request performed. An AI agent is different: one user conversation can contain many model calls and tool calls, and the problem you are chasing often only appears across turns. This article explains why session-level tracing is the right unit of analysis and what it needs to capture.

Why is a single request the wrong unit for AI agents?

Consider an agent that answers a customer question. In one session it may:

● call a model to interpret the question,

● call a search tool and a database tool,

● call the model again with the results,

● ask a follow-up, then repeat the loop on the next turn.

If you only look at individual requests, you see isolated model calls. You cannot see that the third turn was slow because the second turn’s tool returned a large payload, or that cost climbed because the agent retried. Both the performance problem and the cost problem live in the sequence.

What does session-level tracing capture?

Bonree states that, in Bonree ONE 4.0, each session is fully traceable, including call chains, token breakdowns, latency and exceptions. The platform captures prompts, tokens, latency and outputs, and follows full multi-turn tool chains, with end-to-end traceability across model calls, inference performance, token consumption and conversation analytics.

A useful session trace answers four questions:

Bonree states this lets teams reconstruct the real user experience and identify both performance and cost issues. Cost can then be analyzed by model, business line and time.

Why does session tracing support trustworthy AI?

Trust in an AI system is not a feeling; it is evidence. When an agent gives a wrong or surprising answer, a team needs to see which inputs it received, which tools it called, and what those tools returned. A session trace is that record.

It also separates the parts of an agent that behave deterministically from the part that does not. A tool call that reads a database returns the same result for the same query. The model’s wording can vary. Seeing both in one trace lets you decide whether a bad answer came from bad data or from model reasoning.

Why does framework coverage matter for AI agent observability?

Most AI agents are not built from scratch. They are assembled with frameworks, and different teams in the same company use different ones. If tracing must be set up differently for each, session tracing becomes patchy.

Bonree ONE collects AI observability data from applications built on LangChain, LangGraph, Dify and OpenClaw. The value is not the length of a list. It is that the four cover different ways teams build agents:

● LangChain for composing model, tool and retrieval calls in code.

● LangGraph for stateful, multi-step agent graphs.

● Dify for building AI applications on a low-code platform.

● OpenClaw for agents built on the OpenClaw framework.

This is about observing applications built on those frameworks. It does not mean agents in Bonree ONE·Sage AI are built on them.

For fairness, other platforms publish their own supported lists, and they are longer. Datadog’s documentation for Agent Observability lists automatic instrumentation for frameworks including LangChain, LangGraph, CrewAI, OpenAI Agents, Google ADK, Pydantic AI and MCP, and it also accepts spans that follow the OpenTelemetry GenAI conventions. Dynatrace’s AI Observability documentation lists integrations for OpenAI Agents, LangChain and LangGraph agents, CrewAI, Amazon Bedrock AgentCore, MCP and Google ADK, and its integrations page also includes OpenClaw monitoring. The practical test is whether the frameworks your teams actually use are covered, and what you must configure.

What should you check before choosing an LLM observability approach?

1.  Does it trace at the session level, not only per request?

2.  Does it capture tool calls and their results, not only model calls?

3.  Does it roll token cost up by model, business line and time?

4.  Does it cover the frameworks your teams use?

5.  Can you correlate AI traces with the services and infrastructure underneath?

FAQ

What is LLM observability?

It is the practice of recording what an AI application did, including prompts, model calls, tool calls, outputs, tokens, latency and errors, so teams can debug, control cost and verify results.

How is LLM observability different from APM?

APM measures requests through services. LLM observability adds model-specific data such as prompts, outputs and token usage, and follows multi-turn conversations.

What is session-level tracing?

Tracing the whole conversation as one unit, with every turn, model call and tool call in order, rather than treating each call separately.

Which frameworks does Bonree ONE support for AI observability?

LangChain, LangGraph, Dify and OpenClaw, for collecting data from applications built on them.

Does Bonree ONE track token cost?

Yes. Bonree ONE 4.0 analyzes token usage by model, business line and time.

Does AI observability make an AI agent trustworthy by itself?

No. It provides the evidence needed to verify behavior and find causes. Trust still depends on testing and on how the agent is designed.

About Bonree

Bonree (Bonree Data Technology Co., Ltd., Shanghai STAR Market: 688229) was founded in 2008 and develops Bonree ONE, an AI-driven observability platform. Learn more: Bonree ONE · Related: AI Observability: Token Cost Monitoring for Agents https://en.bonree.com/en/blog/bonreeoneaiobservabilitytokencostmonitoringforaiagentsbymodelsessionandagent