Katkat

Trace and Debug Agent Tool-Call Failures

ByteDanceSoftware Engineer · Technical Screen

Last updated

Design a distributed observability and tracing system to monitor, debug, and diagnose multi-step agent tool-call failures across retries and execution stages without leaking sensitive data.

Scenario

Modern LLM-powered autonomous agents rely heavily on tool execution—such as querying internal databases, triggering web searches, running sandboxed code, or calling external partner APIs. In production, these tool calls frequently fail due to malformed tool arguments generated by the model, transient network timeouts, rate limits, schema mismatches, or downstream service errors. When an agent enters retry loops or multi-turn fallback paths, debugging the root cause becomes extremely challenging without rich, contextual telemetry.

Design a distributed tracing and telemetry system tailored specifically for debugging agent tool-call failures at ByteDance scale.

Functional Requirements

  • Hierarchical Trace Context: Correlate events using a strict hierarchy: AgentSessionID -> TurnID -> ToolCallID -> AttemptID. Every retry must produce an independent child attempt span linked to the parent tool invocation.
  • Failure-Stage Attribution: Categorize errors into explicit lifecycle stages:
    • Pre-call: Argument generation failure, JSON schema validation error.
    • Execution: Network transport timeout, 4xx/5xx HTTP responses, sandbox crash.
    • Post-call: Response parsing/truncation errors, post-execution guardrail violations.
  • Safe & Efficient Payload Logging: Capture actionable debugging payloads (input parameters, raw error messages, partial outputs) while masking PII/API secrets and preventing storage bloat from large payloads.
  • Retry Outcome Tracking: Explicitly record retry policies, attempt numbers, backoff delays, and final outcomes (e.g., succeeded_after_retry, budget_exhausted, unrecoverable_failure).
  • Debugging & Query Interface: Allow developers to query traces by error stage, tool name, user session, or latency threshold.

Non-Functional Requirements & Scale

  • Throughput: Peak volume of 50,000 tool executions per second.
  • Overhead: Telemetry collection must add less than 5ms of P99 latency to any individual tool call and must never block agent progress if the telemetry pipeline degrades.
  • Retention: Full debug payloads retained for 7 days; aggregated error rates and metadata retained for 90 days.

What to Cover

  1. Data Model & Span Schema: Define the schema for a tool-call trace span, highlighting context propagation and error classification.
  2. Architecture: Detail client-side SDK interceptors, asynchronous buffering/transport, collector pipeline, and storage engine choices (e.g., OpenTelemetry, Kafka, ClickHouse/Elasticsearch).
  3. Data Protection & Sanitization: How to redact secrets and handle large outputs (e.g., hashing, field-level masking, offloading large blobs to object storage).
  4. Trade-offs: Discuss head-based vs. tail-based sampling for high-frequency successful calls versus guaranteed capture for failed calls.

Hints

Hint 1

Establish a clear parent-child context model where each retry creates a distinct attempt span inheriting from the tool-call span rather than overwriting it.

Hint 2

Use tail-based sampling or dual-path emission so that 100% of failed or retried tool calls are retained with full payloads while successful calls are sampled aggressively.

Hint 3

Decouple payload sanitization and payload storage using an asynchronous sidecar or background worker to keep critical-path execution latency under 5ms.

Follow-up questions

  • How would you detect and alert on 'silent failures,' where a tool technically returns HTTP 200 OK but the returned content is an error message or hallucinated refusal?
  • If an agent enters an infinite retry loop or generates cyclic tool calls, how should your tracing system detect, throttle, and surface this behavior?
  • How would you design the storage layout in ClickHouse or an equivalent columnar store to ensure sub-second search times across billions of tool-call spans?