Your AI Agent Is Failing – You Just Can’t See Where

How Deepchecks Know Your Agent suite pinpoints exactly which component is broken and why – in minutes, not weeks.

When a multi-step AI agent produces a bad output, it doesn’t tell you which step went wrong. Was it the planning? A bad tool call? A hallucinated retrieval? With 20+ steps chained together, any one of them can silently corrupt the rest, and traditional evaluation gives you no way to isolate the cause.

This is the core problem of agentic evaluation, and it’s fundamentally different from evaluating a single LLM call. It requires tooling that understands the structure of agentic workflows – not just the final answer.

In this post, we walk through how Deepchecks Know Your Agent (KYA) suite evaluates a real multi-agent application end to end: from a single overview screen that identifies the underperforming component, down to categorized failure modes with concrete examples and actionable fixes.

The application under evaluation is an Academic Research Agent built with Google ADK – a multi-agent system using a coordinator/sub-agent pattern:

• Academic Coordinator: orchestrates the workflow, interacts with the user, and delegates tasks to two specialized sub-agents.
• Academic Web Search Agent: searches the web for recent papers citing a given research work.
• Academic New Research Agent: synthesizes findings and proposes future research directions.

It supports multi-turn conversations. A typical session: the user asks to analyze a deep learning paper, follows up with “find recent papers citing it,” then requests suggested research directions. Each user turn triggers a full pipeline run (a trace), and each trace contains multiple spans – LLM calls, tool invocations, agent delegations.

44 multi-turn sessions were logged to Deepchecks via the Google ADK integration – a few lines of instrumentation code that captures every span, tool call, and LLM interaction, and automatically logs them to Deepchecks. No manual logging required.

from deepchecks_llm_client.data_types import EnvType
from deepchecks_llm_client.otel import GoogleAdkIntegration

# Register the Deepchecks exporter

GoogleAdkIntegration().register_dc_exporter(
    host="https://app.llm.deepchecks.com/",  # Deepchecks endpoint
    api_key="dc_api_key",         # API key from Deepchecks
    app_name="app_name",          # Application name in Deepchecks
    version_name="version_name",  # Version name for this run
    env_type=EnvType.EVAL,        # Environment: EVAL, PROD, etc.
    log_to_console=True,          # Optional: also log spans to console
)

The Deepchecks overview screen presents a single aggregated score for the entire version – in this case, 16%. But the real value isn’t the number itself. It’s the component-level breakdown underneath it:

The critical insight: the tool works – the agent using it doesn’t.

What does that mean technically? The web search tool returns results every time it’s called – HTTP 200, valid JSON, real papers. But the agent wrapping the tool is where things break down: it formulates vague or overly narrow search queries, calls the tool once when it should iterate with refined queries, or receives a rich set of results but fails to synthesize them into a complete answer. The tool executes flawlessly; the LLM reasoning that drives when to call it, what to ask, and how to use what comes back is where 76% of interactions fall short.

This is a distinction that conventional evaluation approaches miss entirely. Check “did the API call succeed?” and everything looks green. Check “did the user get a good answer?” and you know something is wrong but have no idea what. Deepchecks evaluates every layer of the agent architecture independently, making it possible to isolate the problem to a specific component within seconds.

The overview tells you where the problem is. The next question is why – and getting there requires evaluating the agent at every level of granularity.

Every span, scored and explained

Drilling into any session reveals the full trace hierarchy – coordinator delegates to web search agent, which calls its LLM, invokes the search tool, processes results, returns. One session had 30 spans across 3 traces, each span independently evaluated on both quality metrics (Instruction Following, Reasoning Integrity, Tool Coverage – each with natural-language reasoning, not just a number) and system metrics (latency, tokens, cost per span). If any score falls below a configurable threshold, the span is automatically flagged – no manual review needed.

But here’s what makes this more than observability: the platform also evaluates at the session level. A metric like Intent Fulfillment looks at the entire multi-turn conversation holistically. In several sessions, individual spans scored fine, but the session-level metric showed that the agent never actually delivered on the user’s request. Span-level and session-level evaluation together surface problems that either one alone would miss.

Agent-aware sub-component analysis

Back on the overview, drilling into the web search agent reveals its sub-components: 300 web search tool executions (performing well) and 172 LLM calls – out of 478 total LLM calls across all agents. The platform tracks which calls belong to which agent, so analyzing this agent’s LLM performance means looking at only its 172 calls, not all 478. That scoping is what makes the analysis actionable.

The system metrics view at the trace level also caught two operational failures no quality metric would find: a trace that took 5,000 seconds (likely a tool-calling loop) and a trace with zero input tokens (the LLM was never invoked – a silent failure).

One-click failure mode analysis

With the underperforming agent and property identified, clicking “Analyze Failures” on Tool Coverage generates a structured report in ~15 seconds – categorized failure modes, each with a description, concrete examples from the data, and click-through to the exact span:

• Incomplete retrieval: the agent called the search tool once with a broad query like “papers citing [title],” got back a partial list, and stopped – never issuing follow-up searches with alternate keywords, author names, or date ranges that would have surfaced additional relevant work.
• Dropped context on handoff: the coordinator delegated to the web search agent but passed only the paper title, losing the user’s specific angle of interest (e.g., “applications in medical imaging”), so the search agent returned generic results that didn’t address the actual request.

The built-in Insights feature adds targeted recommendations: not “improve your prompts” but specific suggestions like tightening the agent’s role description or adjusting search query formulation – derived from the actual failure patterns.

From “16% overall” to “here are the categorized failure modes with examples and suggested fixes for your web search agent” – in minutes.

This depth comes from evaluation built in layers. Research-backed properties form the foundation – each scoring a single quality dimension using proprietary SLMs or LLM judges with sophisticated context engineering. The Swarm aggregates these into a single thumbs-up/thumbs-down per span. Session-level scoring rolls everything into a holistic multi-turn assessment. And system metrics at every level catch operational failures alongside quality issues.

All of this works out of the box. For domain-specific needs, custom evaluation properties can be added and appear in the same overview, failure analysis, and version comparisons.

The math is simple: 20 steps at 95% accuracy each yields 0.95^20 = 36% end-to-end accuracy. With production agents running 10-50+ steps per session and consuming 10-100x more tokens than traditional RAG, the failure surface is massive.

You can’t fix what you can’t isolate. Agentic evaluation needs to understand the structure of the workflow – which agent called which tool, which LLM call belonged to which sub-agent, where planning failed versus where tool invocations failed. That’s the difference between “my agent doesn’t work well” and “here’s the specific component, the specific failure pattern, and five examples to start fixing it.”

The gap between a stalled agent project and a shipped product is rarely a better model. It’s knowing exactly where the problems are. It’s Knowing Your Agent.