{"slug": "your-agent-is-working-so-why-cant-you-explain-what-it-did", "title": "Your Agent Is Working. So Why Can’t You Explain What It Did?", "summary": "Langfuse v4 introduces an observations-first model for tracing agentic AI systems, treating LLM calls, tool executions, and agent steps as first-class queryable objects grouped by a shared trace_id, with support for sessions, user tracking, agent graphs, evaluation, and OpenTelemetry-based ingestion. The update addresses the challenge of explaining autonomous agent behavior by enabling queries like 'Show me failed tool observations' or 'Which agent step is expensive?' rather than relying on opaque chain-of-thought logs.", "body_md": "The uncomfortable part of building agentic systems is not making them act. It is figuring out what happened after they did.\n\nI had one of those debugging sessions where the logs make you feel better for about thirty seconds.\n\nThe agent had completed the request.\n\nNo exception. No timeout. No crashed service. The tool calls had succeeded. The model had returned a response.\n\nAnd the answer was wrong. So I opened the logs.\n\n```\nplanner startedresearch agent startedtool call succeededresearch agent completedfinal agent completedstatus = success\n```\n\nWonderful.\n\nExcept I still couldn’t answer the simplest question:\n\nWhy did the system produce this answer?\n\nThat was the moment I stopped thinking about observability as “logs for LLM calls” and started thinking about something bigger:\n\n**observability for autonomous behavior.**\n\nTraditional distributed systems are complicated, but they are usually predictable. A request comes in, a service calls another service, a database is queried, and a response comes back.\n\nAgents break that assumption.\n\nThe code gives an agent capabilities. The model helps decide which capability to use and what to do next.\n\nFor the same request, one run might search the web and stop. Another might call a specialist agent. A third might retry a tool, retrieve more context, or ask for human approval.\n\nThere’s a temptation to solve this by capturing every bit of the model’s chain of thought.\n\nI don’t think that’s the right abstraction.\n\nThere are obvious privacy and security reasons not to turn private reasoning into a permanent telemetry stream. There’s also a technical problem: a generated explanation isn’t necessarily a faithful causal explanation of the model’s internal computation.\n\nAs an engineer, I want something more concrete.\n\nI want to know what context was available, which decision was made, what action followed, what came back, and what happened next.\n\n```\ndecision = delegatetarget = financial-agentreason_code = FINANCIAL_ANALYSIS_REQUIREDaction = tool_calltool = market_datastatus = successevaluation = rejectednext_action = retry\n```\n\nThat tells me how the system behaved without pretending I can inspect a model’s private mind.\n\nOnce you have multiple agents, tools, retrieval, memory and protocols, a trace can’t just be “prompt in, answer out.”\n\nThis is also why I care about **versioning**. If yesterday’s agent scored 92% and today’s scores 74%, I want the trace to tell me which agent version, prompt version, model, tool version and policy version were involved.\n\nI’ve been looking at Langfuse because it solves a large part of this problem without requiring a team to build an observability product from scratch.\n\nLangfuse v4 uses an observations-first model: LLM calls, tool executions and agent steps are first-class queryable objects, while a trace groups observations using a shared trace_id. It also supports sessions, user tracking, agent graphs, evaluation and OpenTelemetry-based ingestion.\n\nThat changes how you can investigate a system.\n\nYou don’t just ask, “Show me trace 123.”\n\nYou can ask, “Show me failed tool observations,” or “Which agent step is expensive?” or “Which observations are associated with poor evaluation scores?”\n\nAnd if you’re using LangGraph, Langfuse has a dedicated integration and can render the graph for the trace.\n\nIf I am building a platform, I do not want every agent to know how Langfuse works.\n\nI want the application to emit standard telemetry, and I want the observability layer to decide where that telemetry goes.\n\nThat is where OpenTelemetry fits.\n\nOpenTelemetry gives you common semantic conventions for describing operations and telemetry across traces, metrics and logs. Its GenAI conventions are evolving in a separate repository, and already cover concepts such as agent identity, model information, token usage, retrieval and evaluation-related attributes.\n\nThis is where many “LLM tracing” designs become too shallow.\n\nSuppose the final answer is wrong. You look at the model call and see a perfectly reasonable response to the context it received.\n\nSo the real question becomes: *why did it receive that context?*\n\nI want references to prompt and policy versions, memory records, retrieved documents, retrieval scores, context size, truncation and state transitions. I do not necessarily want every raw piece of data copied into the telemetry store.\n\nThat distinction matters. Observability is not an excuse to create a second uncontrolled copy of your production data.\n\nThis is another thing I would change in a serious agent platform.\n\nAn agent calling another agent is not the same operation as an agent calling a tool server.\n\nFor A2A, I want delegation, target agent, task lifecycle, status, latency and authorization context.\n\nFor MCP, I want server, tool, arguments, result, schema/version, authorization and failure details.\n\nThe exact attributes can evolve with the protocols. The important part is not losing those boundaries in a generic “tool call” span.\n\nStateful agents make this even more interesting.\n\nWith a framework such as LangGraph, execution can be persisted and resumed. A workflow can pause for human input, continue later, or recover from an error. LangGraph’s persistence is explicitly designed to support state recovery and human-in-the-loop workflows.\n\nSo I want to know not only what happened inside a run, but which state checkpoint it started from, what changed, and whether the run was a fresh execution, retry or resume.\n\nOtherwise you can end up with a perfectly detailed trace that still doesn’t explain the current state of the agent.\n\nProduction agents will eventually encounter actions that require policy checks or human approval.\n\nThat should be visible as part of the execution, not hidden in another system.\n\n```\nAgent  ↓Policy check  ↓Approval required  ↓Human approves  ↓MCP action  ↓Continue\n```\n\nThe trace should tell us which policy version ran, why the action was blocked or approved, who approved it, and how long the workflow waited.\n\nThat last number matters more than it looks. A five-second model call and a nine-hour human approval are both “latency”, but they mean very different things operationally.\n\nThis is probably the biggest conceptual difference from infrastructure monitoring.\n\nYour CPU can be fine while your agent is terrible.\n\nYour API can return 200 while the customer receives a useless answer.\n\nYour tool can return 200 while returning stale information.\n\nSo I want evaluation tied directly to execution.\n\nThere are two loops here.\n\n**Offline:** run controlled datasets against different prompts, models, tools or agent versions.\n\n**Online:** evaluate production executions using deterministic checks, model-based evaluators, user feedback and human review.\n\nLangfuse already supports evaluation workflows, datasets, experiments, scores and feedback around traces.\n\nThe important part is connecting the score back to the execution. A score of 0.72 is much less useful than “0.72 because retrieval failed for these queries after version 14 of the retriever.”\n\nAgents can fail economically without failing technically.\n\nA task that normally needs three model calls can suddenly need fifteen because a planner keeps delegating, a tool keeps timing out, or a context window keeps growing.\n\nNothing crashes. The answer eventually arrives.\n\nBut the cost has gone from cents to dollars.\n\nThat is an observability problem.\n\nI want to be able to ask: *Why was this run 12x more expensive than normal?*\n\nToken usage, latency, retries, model routing and tool calls should all be visible in the same trace. Langfuse supports token and cost tracking as part of its tracing model.\n\nWhen an agent gives a bad answer, “hallucination” is often just the symptom.\n\nThe actual cause might be bad retrieval, stale memory, context truncation, a wrong tool choice, an A2A delegation problem, an MCP schema mismatch, a prompt regression, model routing, a policy decision or an agent loop.\n\nThat is why I want the trace to be navigable from symptom to evidence to cause.\n\nConsider:\n\n```\nResearcher → Analyst → Researcher → Analyst → Researcher → ...\n```\n\nNothing technically fails.\n\nThe system is just working forever.\n\nYour infrastructure dashboard might look perfectly healthy.\n\nYour token bill won’t.\n\nSo agent observability needs behavioral signals: unusual step counts, repeated calls, abnormal delegation patterns, retry storms, growing context and execution depth.\n\nThose aren’t proof of failure. They’re signals that should trigger investigation or runtime limits.\n\nGenAI telemetry can contain prompts, completions, tool arguments and tool results. OpenTelemetry’s GenAI guidance treats content capture carefully because it can be sensitive and expensive to store.\n\nSo I would put a deliberate telemetry boundary between the application and the backends:\n\n```\napplication   ↓instrumentation   ↓classify / redact / enrich   ↓sampling + tenant policy   ↓OpenTelemetry Collector   ↓observability backends\n```\n\nSome environments may allow raw content for a tightly controlled debugging team. Others may prohibit it. The architecture should support both without forcing the same retention policy everywhere.\n\nIf I were starting an enterprise agent platform today, I would not build another Langfuse.\n\nI’d build on standards and specialize where agent behavior creates genuinely new problems.\n\n**OpenTelemetry : **The common telemetry foundation and semantic vocabulary across the application.\n\n**Langfuse : **AI-native observations, traces, agent graphs, evaluation, prompts, cost and feedback.\n\n**Agent telemetry contract : **A platform-level semantic layer for identity, decisions, state, A2A, MCP, policy and outcomes.\n\n**AgentOps : **Behavioral alerts, quality trends, anomaly detection, governance and continuous improvement.\n\nThe thing I’d build myself isn’t another trace viewer.\n\nIt’s the **semantic contract**.\n\nEvery agent should speak the same language:\n\n**Identity. Context. State. Decision. Action. Protocol. Policy. Economics. Outcome. Evaluation.**\n\nOnce those concepts are consistent, you can change models, frameworks, agents and observability backends without losing the story of what happened.\n\nI started this with a wrong answer and a pile of green logs.\n\nThe lesson wasn’t “we need better logs.”\n\nIt was that we were monitoring the wrong thing.\n\nFor traditional applications, we mostly ask:\n\nIs the system working?\n\nFor agentic systems, that is only the beginning.\n\nWe need to ask:\n\nWhat did it do?\n\nWhat information did it have?\n\nWhich path did it take?\n\nWhich agents and tools were involved?\n\nWhat state did it change?\n\nHow much did it cost?\n\nDid a policy or human intervene?\n\nDid it actually accomplish the task?\n\nAnd finally:\n\nCan I trust the result?\n\nThat’s why I don’t think agent observability is simply “LLM logging with a nicer UI.”\n\nThe software itself has changed.\n\nWhen the system can decide what to do next, observability has to evolve from watching services to understanding behavior.\n\nWe’re getting very good at making agents do things.\n\nNow we need to get equally good at understanding what they did.\n\nMy current mental model:OpenTelemetry gives the platform a common telemetry language; Langfuse gives engineers an AI-native place to explore and evaluate that telemetry; and AgentOps turns those signals into operational decisions.\n\n**Technical references**\n\n• Langfuse v4 — observations-first architecture:[langfuse.com/docs/v4]\n\n• Langfuse agent graphs:[langfuse.com/docs/observability/features/agent-graphs]\n\n• Langfuse observability overview:[langfuse.com/docs/observability/overview]\n\n• Langfuse LangGraph integration:[langfuse.com/guides/cookbook/integration_langgraph]\n\n• OpenTelemetry GenAI semantic conventions:[opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai]\n\n• OpenTelemetry semantic conventions:[opentelemetry.io/docs/concepts/semantic-conventions]\n\n[Your Agent Is Working. So Why Can’t You Explain What It Did?](https://pub.towardsai.net/your-agent-is-working-so-why-cant-you-explain-what-it-did-5981c692c98d) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/your-agent-is-working-so-why-cant-you-explain-what-it-did", "canonical_source": "https://pub.towardsai.net/your-agent-is-working-so-why-cant-you-explain-what-it-did-5981c692c98d?source=rss----98111c9905da---4", "published_at": "2026-08-20 15:01:03+00:00", "updated_at": "2026-08-20 15:14:05.774377+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Langfuse", "OpenTelemetry", "LangGraph"], "alternates": {"html": "https://wpnews.pro/news/your-agent-is-working-so-why-cant-you-explain-what-it-did", "markdown": "https://wpnews.pro/news/your-agent-is-working-so-why-cant-you-explain-what-it-did.md", "text": "https://wpnews.pro/news/your-agent-is-working-so-why-cant-you-explain-what-it-did.txt", "jsonld": "https://wpnews.pro/news/your-agent-is-working-so-why-cant-you-explain-what-it-did.jsonld"}}