LLM Digest
Subscribe

Agent Know-How

Agent engineering · know-how

에이전트의 행동 근거를 알 수 없는 이유

🧱 Obstacle·observability·active·25 entries·25 sources·updated 2026-10-16

When an agent does the wrong thing, the run behind it is a long, non-deterministic chain of model calls, tool results, and intermediate decisions, and most of it is invisible afterwards. Unlike a stack trace, an agent's "why" is spread across a trajectory you didn't log in enough detail, can't replay deterministically, and can't easily diff against a working run.

Latest updates
State of the art

Observability for agents is trace-first. The unit captured is the full trajectory: prompts, tool calls, results, retries, and subagent handoffs. Harnesses and serving platforms now emit these spans natively over OpenTelemetry, and capture extends to voice agents and plain CLIs.

The bottleneck has moved from capture to reading. Teams run a model over the traces to surface recurring failure patterns, debug many coding agents in one console, and read a session as a single thread instead of a span tree. Loops and runaway spend show up in the same trace, so trace and cost views are merging.

Agentic root-cause analysis works with guardrails, not alone. Production systems pair pre-correlated telemetry with LLM analysis and keep a human approving changes. Evidence suggests models can reason about a failure once the context is assembled. The best frontier agent on a realistic oncall benchmark still gets only about a quarter of root causes right, so the pipeline, not the model, is the open problem.

Ownership is a design choice. Enterprises want traces and spend data in their own network, through a self-hosted gateway or a managed platform deployed into their cloud. Payload privacy defaults differ by framework, and traces can be truncated.

The trace has limits. Offline monitoring covers agents you can't watch live, and agents can coordinate through hidden states a transcript never records. Evaluating the monitors is itself an evaluation problem.

Why it matters for platform engineers

You cannot operate what you cannot explain. Without trajectory-level traces, a regression after a model upgrade, a silent tool failure, or a runaway loop stays invisible until it shows up as cost or a user complaint, and you can't reproduce it.

Observability is the precondition for the rest of the stack: evaluation needs traces to grade, cost control needs per-step attribution, and incident response needs a replayable run. The build-vs-buy choice is whether to standardize on a trace format and own the analysis, or adopt a managed platform. Either way, check payload retention and truncation defaults: the trace is the new log line, and it carries secrets.

Developments 25

Capturing the full trajectory

7 entries · latest Oct 10, 2026

Harnesses, serving platforms, and CLIs now emit agent spans natively over OpenTelemetry, across text and voice, but payload defaults, truncation, and retention vary by tool.

Cloudflare Traces emits proxy-layer steps as OpenTelemetry spans that join your agent traces

Cloudflare put Traces into open beta, extending automatic tracing beyond Workers to security rules, transformations, cache, routing, and origin handling, all as OpenTelemetry spans. It accepts and forwards W3C traceparent headers, so edge spans attach to the trace your agent harness already started. Trace Rules sample selectively.

For builders, tool calls and model-gateway traffic that cross the edge no longer break the trace at the proxy. Pricing moves to ingestion and retention volume from December 1, so budget for span volume from agent loops before enabling it broadly.

Cloudflare adds native agent tracing, with truncated payloads and opposite privacy defaults

Cloudflare added agent spans to existing Workers traces: invoke_agent, chat/execute_tool, and tool_approval, keyed by agent name, agent ID, and conversation ID, so a session replays turn by turn.

The gotchas are concrete:

  • Payload recording defaults differ by framework: off under Vercel's AI SDK, on under Flue. Those payloads often carry personal data or secrets.
  • Traces are not lossless; payloads may be truncated, dropping the arguments a debug session needs.
  • From October 1, 2026, every span is a billable event.
Show 4 earlier entries

Simon Willison's LLM 0.32 logs visible reasoning traces in redesigned SQLite logs

LLM 0.32, the biggest release of the CLI since launch, adds visible reasoning traces, server-side provider tools, and redesigned content-addressable SQLite logs, plus features from the OpenAI Responses API.

Trajectory capture is available in a widely used, framework-agnostic command-line tool, not only in hosted platforms.

Making traces readable and analyzable

6 entries · latest Sep 24, 2026

Capture is no longer the bottleneck; models now read traces to surface failure patterns, and viewers present a session as one readable thread instead of a span tree.

LangSmith Trajectories shows an agent session as one readable thread, not a span tree

LangSmith's Trajectories renders a whole agent session as a conversational thread: user turns, tool calls, and subagent handoffs read top to bottom, instead of the nested span tree a generic OpenTelemetry viewer shows.

It trades completeness of the tree for the job that bottlenecks debugging long-running agents: scanning a session fast enough to spot where it went wrong.

OpenSearch MCP Apps return trace waterfalls and service maps inline in the agent chat

Amazon OpenSearch Service's MCP Apps return an interactive visualization alongside each tool call's text response. A local MCP server authenticates with AWS credentials, queries the same OpenSearch and Prometheus sources behind existing dashboards, and renders the result inline in the IDE.

One conversation moves from alert to log clustering, trace waterfalls, and service maps without opening a separate tool. MCP carries the observability payload itself.

Show 3 earlier entries

HALO runs a model over agent traces to find recurring harness-level failure modes

HALO is an open-source local debugger that ingests Langfuse, Arize/OpenInference, or JSONL traces and uses an RLM-based engine to find recurring harness-level failure modes. It produces reports you can feed into Cursor or Claude Code to patch the agent, and a desktop app answers questions over the traces.

The engineer stops reading every span: a model reads the traces and the human reviews the patterns.

Agents doing root-cause analysis and on-call

6 entries · latest Sep 7, 2026

Production RCA and triage agents work when telemetry is pre-correlated and a human approves changes; benchmarks show end-to-end oncall accuracy is still low.

Figma's security agents resolve complex alerts 70% faster, with memory as the main lever

Figma built alert-triage agents on a Panther SIEM foundation, querying 100+ data sources (AWS, Okta, GitHub, GCP, osquery) and scoped to the tools an on-call engineer uses. The team reports memory, not model choice or tool count, as the biggest quality lever.

Reported results: 70% faster resolution on complex alerts, 20% fewer on-call pages from re-tuned severity, and 100+ previously unknown vulnerabilities found. Agent-authored PRs default to draft and every fix needs human approval.

ORCA-bench: the best frontier agent gets 25.3% of realistic oncall root causes right

ORCA-bench pairs an OpenTelemetry-instrumented microservice testbed (six days of metrics, logs, and traces) with 1,079 oncall RCA tasks, graded by an LLM judge that human SREs re-scored (κ=0.90). Across five frontier agents, the best accuracy is 25.3% on realistic-input tasks and 10.0% on hard ones. The weakest model invents an implausible root cause on 40% of reports.

The authors read this as a lower bound on the real-world gap. The reasoning may be there, but the end-to-end oncall pipeline is mostly unsolved.

Show 3 earlier entries

Expedia's STAR turns live telemetry into root-cause assessments with engineers in the loop

Expedia's STAR, built on FastAPI, Datadog, Celery, Redis, and Langfuse, ingests service telemetry during incidents, runs structured workflows to generate root-cause assessments, and keeps engineers in the loop for the final call.

It is the trace-plus-LLM-analysis pattern built on infrastructure a platform team already runs, not a new observability product.

A multi-dataset benchmark grades how LLM agents reason through microservice failures

A new benchmark for AgentOps evaluates LLM agents on microservice failure diagnosis over multimodal observability data. It adds two large datasets because existing benchmarks score only the final answer and ignore the reasoning process.

Grading whether an agent diagnosed a failure correctly is a trajectory-grading problem, so agent observability and evaluation converge on the trace.

Where agent telemetry lives

3 entries · latest Aug 12, 2026

Enterprises want traces and spend data inside their own network, answered either by self-hosted gateways or by managed platforms deployed into the customer's cloud.

LangSmith Bring Your Own Cloud reaches GA on AWS

LangSmith's Bring Your Own Cloud option is generally available on AWS, giving enterprise teams managed observability, evaluation, and deployment inside their own VPC.

It meets the "keep traces in our network" requirement from the vendor side: the Claude Apps Gateway answers it by self-hosting, BYOC by deploying the managed product into the customer's cloud.

AWS's Claude Apps Gateway relays telemetry and enforces spend caps from a self-hosted container

AWS and Anthropic released the Claude Apps Gateway, a single stateless container an organization runs in front of Claude Code and Claude Desktop. It centralizes identity, policy, routing, and telemetry, relays per-request usage metrics to the team's own OpenTelemetry collector (CloudWatch, Prometheus), and enforces YAML-defined spend caps by org, group, or user.

Telemetry relay and cost policy live in one customer-owned layer instead of a vendor dashboard.

When the trace is not enough

3 entries · latest Oct 16, 2026

Offline monitoring covers agents you cannot instrument live, and latent-channel work shows a complete transcript can still miss how agents coordinated.

Grafana turns agent behaviour into SLOs with error budgets

Latency, error rate, and token counts say nothing about whether an answer was grounded or useful. Grafana proposes running evaluations per interaction (grounded, request fulfilled, toxic, PII exposed, injected) and treating each result as an SLI. Checks can be an LLM judge or deterministic rules such as regexes.

Each behaviour gets its own objective instead of one "quality score". Example: 95% of conversations judged fulfilled over 30 days; the other 5% is the error budget. While budget remains, teams can change prompts or models. Once it burns, effort shifts to quality.

For builders, budget burn surfaces slow drift (a prompt, model, or retrieval change costing a fraction of a point per day) that error-rate alerts miss. Grafana-described proposal, not a measured result.

Also relevant to Measuring whether an agent actually worked is hard

Agents can coordinate through hidden states a full transcript never shows

Language-model agents can communicate through continuous hidden states invisible in public transcripts. Verifiable Latent Alignments (VLA) links each private latent-state record and channel status to the resulting public action through a shared event identifier, and layers representation anomaly detection on top.

A complete trace of what agents said can still miss what they communicated. In multi-agent systems, message-and-tool-call spans are the wrong unit when coordination happens below the message layer.

From related topics
  1. Sandboxing, scoped credentials, and guardrailsA parallel subagent's test escaped an unsandboxed Mac and spoke aloud on the host
Evidence · 25 sources
All sources behind this page