Extreme Observability in Agentic Systems: Answering "Why Did the AI Say That?"

At some point, every enterprise AI system faces a stakeholder with a question the engineering team cannot answer just by looking at logs. It might be a compliance lead asking what the system was thinking when it gave a certain answer. It could be a business owner forwarding a screenshot and asking why a user got a wrong response to a simple request like "show me data." Sometimes, a manager wants detailed stats on what is being queried and by whom, or a domain expert wants a single, approved list of prompts that the business can review and edit without waiting for a new release. In our experience, these four questions come up in nearly every agentic project. If a system cannot answer them, it loses business trust long before any technical debate even starts.

We call the ability to answer all four of these questions for any request at any time extreme observability. In this article, we explain how we achieved this using Langfuse with our FastAPI AI engines and our full-stack Next.js platform.

What makes it so difficult to explain agentic systems?

Traditional applications usually behave the same way every time they get the same input, so a log line and stack trace are often enough to explain a problem. Agentic systems are different. One user question can lead to a planning step, several model calls, document retrieval, one or more generated SQL queries, running those queries, and finally turning the results into an answer. The path through these steps can change from one request to another. Each step’s behavior also depends on prompts that might have changed recently, the model version, and the data in the database at that time.

When something goes wrong in these systems, the important question is not just "what did the model return," but also "what did the system believe at each step, what instructions was it following, and what did it see?" Regular application logs rarely capture this information because they are built for predictable code, and most monitoring tools do not track prompts, completions, tokens, or model parameters.

What is our setup like?

Our AI engines run as FastAPI services in Python, and the user-facing platform is a full-stack Next.js application in TypeScript. Langfuse sits across both. Every request that a user makes in the platform becomes one trace in Langfuse, and every meaningful step inside the AI engine becomes an observation nested inside that trace: the planning step, each model call with its prompt and completion, each tool call, each generated query with its parameters and the shape of its result, and the final response. Langfuse records token usage, latency, and cost for model calls, and its SDKs send data asynchronously in batches, so instrumentation doesn't slow the response the user is waiting for.

Two choices made the biggest impact. First, we attached the user's identity and session to the trace at the platform level and passed them through every step in the engine. This lets Langfuse group usage, cost, feedback, and traces by user, so later questions about a specific person are easy to answer. Second, we named observations based on their business meaning, like interpreting the question, choosing the data source, or generating the query, instead of adopting technical function names. This way, even non-engineers can read a trace and understand the system’s reasoning.

How do we answer the four questions?

"What was the system reasoning?" We open the trace for that request and read it from top to bottom. Each observation shows its input and output, so we can see how the agent interpreted the question, which plan it chose, which tools it called with which arguments, and what came back at each step. In our experience this alone changes the character of conversations with the business, because the answer stops being "the model decided" and becomes a sequence of visible steps that people can discuss.

"Why did this user get an incorrect response to 'show me data'?" We go to that user's view in Langfuse, find the trace, and check three things in order: which version of which prompt was used, how the agent interpreted an ambiguous question, and which query it ran against which data. Most incorrect answers we have investigated came from one of those three places, rather than from the model itself. When a user marks an answer as wrong, we store that feedback as a score on the trace, and we can collect problematic traces into datasets so we can replay the same question against the next prompt version before it goes live.

"What is being queried, and by whom?" Since every trace includes the user's identity, Langfuse can show usage, trace counts, cost, and feedback for each user. Custom dashboards and a metrics API provide the same data for reports outside the tool. Tags and metadata let us group requests by question type or business area, which helps answer the common sponsor question: who uses the system, for what, and at what cost.

"Can we have one approved list of prompts that the business can edit?" Langfuse prompt management handles this. Prompts are stored in Langfuse, not in code. Each change creates a new version, and the production version is simply the one with the production label. This lets a domain expert edit a prompt in the UI and promote it without needing a code deployment. Rolling back is just moving the label to the previous version. The SDKs cache prompts on the client side, so fetching them does not add latency. On enterprise plans, labels like production can be protected so only admins and owners can change what is live, while others can still suggest and test new versions. Since each trace links to the prompt version it used, we can compare quality, cost, and feedback between versions instead of debating them.

What about sensitive data?

Extreme observability creates an obvious risk: a system that records everything also records things it should not keep. We take two measures. Langfuse SDKs allow a masking function that redacts sensitive values from span data before it is exported, which we use for personal data and anything a client classifies as confidential. And because Langfuse is open source under the MIT license and can be self-hosted, clients with tight data residency requirements can keep all traces inside their own infrastructure. It is also worth knowing that Langfuse runs on ClickHouse as its analytical backend, and in January 2026 ClickHouse acquired Langfuse, with an obligation to keep it open source and self-hostable, which matters to clients who already run ClickHouse or are planning to.

What would we recommend if you are starting now?

Instrument from the first prototype, not after the first incident, and treat traces as part of the same AI-ready data foundation as the data your agents query, because a trace structure designed early is much easier to keep consistent than one added under pressure.Attach user and session identity at the edge and propagate it everywhere. Move prompts out of code and into versioned, labeled storage before the first business stakeholder asks to change one. Give every important step a business-readable name. And agree, together with the business, which questions the system must always be able to answer, because those questions, more than any tool, define what observability means for your organization.

In our view, the real value of extreme observability is not the dashboards but the conversations it makes possible: when a compliance officer, a product owner and an engineer can open the same trace and agree on what happened, an agentic system stops being a black box and starts being something the organization can govern. So the question we would ask any team putting agents in front of business users is this: if a stakeholder asked you tomorrow why one user got a wrong answer last Tuesday, how long would it take you to show them?

Sources: Langfuse documentation, Observability overview, User tracking, Prompt version control and Masking (langfuse.com/docs); ClickHouse, ClickHouse welcomes Langfuse: The future of open-source LLM observability, 16 January 2026

‍