We have traces and logs—why are agent failures still hard to reproduce across multi-step workflows?

Most teams ship their first agent thinking traces and logs will be enough to debug whatever goes wrong. Then a customer hits a bizarre edge case—an agent takes the wrong tool action on step 3 of 7, silently ignores a guardrail, or hallucinates around a missing field—and you can’t get it to misbehave the same way again. You have the data. You still can’t reproduce the failure. Why?

In multi-step workflows, traces and logs are necessary, but they’re not sufficient. What you’re missing is a system that can: (1) reconstruct the full decision context, (2) encode “correct behavior” as reusable evaluators, and (3) turn those evaluators into always-on guardrails.

This is where Galileo’s approach—eval engineering plus Luna-2 powered guardrails—changes the equation.

---

Why multi-step agent failures are so hard to reproduce

Let’s name the failure modes you actually see in production:

• An agent selects the wrong tool in a chain of tool calls and never recovers.
• A RAG step uses the right document but extracts the wrong field and propagates the error.
• A guardrail that worked yesterday starts silently letting PII slip because the data shape or prompt changed.
• A multi-turn conversation drifts off-policy only after specific back-and-forth patterns.

You go to the logs. You search. You “chat with your traces.” You can often see what went wrong in hindsight—but you still can’t reliably recreate the error in a test harness.

That’s because:

1. You’re missing the full environment snapshot.
   Model version, prompt version, tool schema, external system state, and feature flags all interact. Your traces show what happened, not the total configuration that made it happen.

2. Agent behavior is path-dependent, not just input-dependent.
   By step 6 of an agent run, the context window contains: prior tool results, intermediate reasoning, user corrections, and subtle timing differences. Tiny divergences in earlier steps change later behavior even if the “input” looks the same.

3. Logs are raw facts, not expectations.
   Traces tell you what the agent did, not whether each step was correct under your policies. You don’t have an explicit, machine-checkable definition of “this workflow ran cleanly” or “this was a failure.”

4. Failures are rare, multi-factor outliers.
   The worst bugs involve a specific user segment, a particular tool, a partial outage, and a new prompt all colliding. You can’t brute-force your way back to that exact combination.

5. Traditional observability is request-centric, not workflow-centric.
   Classic logging tools treat each request in isolation. Agents operate as sessions → traces → spans with branching paths and internal state. Without that structure, your logs are just a big pile of tokens and timestamps.

It’s not that your traces are bad. It’s that you’re trying to solve a detection and governance problem with search and replay tools.

---

Why “chat with your logs” can’t fix this

Most “AI observability” pitches boil down to: dump your traces into a vector store, then query them with an LLM. That’s useful for forensics and one-off debugging, but it fails you in three key ways when it comes to reproducibility:

• You only find what you already know to ask for.
  Hallucination cascades, tool selection drift, and timestamp issues are not obvious until they’ve hit enough users to form a pattern. By then, you’re already in incident mode.

• You don’t get a reusable asset.
  Each investigation starts from scratch. You might write a postmortem, but you don’t get a live evaluator that can detect and prevent the same pattern in the future.

• You can’t run it on 100% of traffic.
  “LLM-as-judge over all logs” is too slow and too expensive to run continuously. That means you’re sampling. Sampling plus rare, multi-step failures is a terrible combo.

You don’t need better search. You need a system that can turn what you learn from logs into evals and then into guardrails that run under tight latency and cost budgets.

---

From traces to reproducible failures: the eval engineering workflow

To make agent failures reproducible, you need to do more than capture logs. You need to:

1. Instrument for sessions → traces → spans
   First, you need structured visibility into the workflow, not just raw tokens.

   • A session represents the full user-agent interaction.
   • A trace represents a single end-to-end task or run.
   • Spans represent each step: tool calls, model invocations, retrieval, post-processing, external API calls.

   Galileo ingests this structure so you can see, for each step:

   • Prompt and model version
   • Tool inputs/outputs and schema
   • Latency and cost
   • Derived metrics (e.g., hallucination score, policy compliance, PII risk)

   This structure is what makes multi-step failures visible as paths, not just as isolated broken responses.

2. Capture ground truth and “golden paths”
   Reproducible bugs require a definition of “correct.”

   With Galileo, you:

   • Seed synthetic and dev scenarios for key workflows (e.g., “refund request with ambiguous policy,” “multi-account billing correction,” “cross-region data update”).
   • Add subject matter expert annotations to mark:
     • Acceptable tool sequences vs. dangerous ones
     • Allowed vs. disallowed content and actions
     • Correct vs. incorrect extractions in RAG
   • Build golden paths: validated sequences of steps the agent should take for critical tasks.

   These become your baseline: a living evaluation asset you can run against different models, prompts, and configurations.

3. Turn expectations into explicit evaluators
   Instead of manually eyeballing traces, you convert your expectations into evaluators tied to concrete failure modes:

   • “Did the agent select the correct tool given the user intent?”
   • “Did the agent attempt to access or reveal PII?”
   • “Did the agent follow ‘never cancel a payment without confirmation’ policy?”
   • “Did the agent hallucinate fields not present in retrieved documents?”

   Galileo’s Evaluation Engine provides 20+ out-of-the-box evaluators for:

   • RAG quality and hallucinations
   • Agent tool usage and step correctness
   • Safety, security, and PII
   • Latency, cost, and resource constraints

   You can also define custom evaluators, or generate LLM-as-judge evaluators from a written description, then refine them with few-shot examples from real failures.

4. Distill evaluators into Luna / Luna-2 for production
   Here’s the critical step most teams miss: taking the evaluators that actually match your domain and making them cheap and fast enough to run continuously.

   Galileo distills your best evaluators—including LLM-as-judge logic—into compact models like Luna and Luna-2, then serves them on a purpose-built inference stack. The result:

   • Sub-200ms guardrailing latency
   • 97% lower monitoring cost vs. heavyweight LLM judges
   • Coverage on 100% of traffic, not a sample

   At this point, you’re no longer just “analyzing logs.” You’ve built a dedicated evaluation layer that can run at production scale.

5. Turn evals into guardrails and runtime policies
   Once your evaluators are reliable, you wire them into Protect, Galileo’s real-time firewall for agents and RAG:

   • Every input and output is scored against your guardrail metrics.
   • Failures trigger explicit actions:
     • Block the response before it hits the user.
     • Redact PII and sensitive strings.
     • Override with a safe fallback (e.g., “I can’t access that information, here’s what I can do instead…”).
     • Webhook to escalate to a human or trigger downstream systems.

   You can:

   • Version and iterate on guardrail policies.
   • Roll back changes safely without redeploying code.
   • A/B test different thresholds and evaluators.

   That’s how you close the loop: offline evals become online guardrails.

---

How this actually makes failures reproducible

Once you have this eval-to-guardrail system in place, a previously “mysterious” multi-step failure becomes something you can name, measure, and systematically replay.

1. Signals catch the pattern before it’s obvious

Galileo Signals continuously analyzes 100% of your traces to surface:

• Repeated tool mis-selections for specific intents
• New PII leak patterns in a particular workflow
• Policy drift where agents gradually stop following a constraint
• Latency spikes tied to certain external tools or paths

Instead of trawling logs, you get a surfaced signal: “For workflows involving tool X and policy Y, agents are exceeding allowed refund amounts.”

From that signal, you can:

• Auto-generate an LLM judge that formalizes the pattern.
• Convert it into a reusable evaluator.
• Run that evaluator across historical traces to see how long it’s been happening.

Now you have a concrete failure mode, not just an anecdote.

2. You can replay against golden test sets

With evaluators defined, you take your golden test sets and:

• Re-run them against the current model/prompt/tool configuration.
• Compare behavior against previous versions.
• See exactly which traces and spans fail which evaluators.

If an agent previously picked the right tool and now picks the wrong one:

• You see the diff in prompt and model.
• You see which span evaluation flipped from pass to fail.
• You can reproduce the failure by re-running that scenario with the current configuration.

3. Guardrails create clean before/after snapshots

When you deploy a new guardrail in Protect:

• Every span now has an associated guardrail score and action.
• You can compare:
  • Behavior before guardrail (failures reach users).
  • Behavior after guardrail (failures are intercepted, blocked, or overridden).

If a bug slips through, you can see whether:

• The evaluator didn’t fire (definition issue).
• The guardrail policy was too lenient (threshold issue).
• Or a new failure mode emerged that doesn’t match existing evaluators.

In each case, you adjust the evaluator, rerun on historical traces, and confirm you’ve captured the pattern. That’s reproducibility with teeth.

---

Why this matters more as your agents get more complex

As you shift from simple chatbots to real agents—with tool access, multi-step plans, and real-world consequences—the cost of irreproducible failures skyrockets:

• Financial risk: Wrong tool actions can trigger refunds, cancels, or updates in live systems.
• Security risk: Prompt injection and PII leaks slip through if you rely on brittle regexes and generic safety models.
• Trust risk: Users see inconsistent behavior; internal teams lose confidence in the system.

Meanwhile, your environment is constantly changing:

• Models get updated.
• Prompts are tuned weekly.
• Tools evolve and schemas change.
• New workflows are added.

Static test harnesses and ad hoc log spelunking can’t keep up. You need:

• Golden paths that define correct behavior for critical workflows.
• Evaluators that automatically check those paths on every change.
• Luna-2 guardrails that enforce those checks in under 200ms across all traffic.

Without that, “we have traces and logs” just means “we’ll eventually figure out what went wrong, after users have already seen it.”

---

How Galileo fits into your existing stack

You don’t need to rip out your current observability tools. Galileo sits alongside them and turns “raw visibility” into “actionable evaluation and protection”:

• Ingest: Connect your existing tracing (sessions → traces → spans) and logs.
• Evaluate (Evaluate + Evaluation Engine): Build and run evaluators on dev, staging, and production data.
• Detect (Signals): Automatically surface new failure modes and drift patterns.
• Protect: Deploy real-time guardrails powered by Luna-2 models and your evaluators.

Deployment options:

• SaaS for teams who want to move quickly.
• VPC or on-prem for enterprises with strict data boundaries.
• Enterprise posture: SOC 2 Type II, HIPAA-compliant infrastructure with BAAs, SSO, and dedicated inference when needed.

The output is not a dashboard. It’s a control plane for your agents: which actions they can take, which routes are allowed, and what happens when they misbehave.

---

Bringing it together

If your question is “We have traces and logs—why are agent failures still hard to reproduce across multi-step workflows?”, the answer is:

Because raw traces tell you what happened, not whether it should have happened—and they don’t give you a mechanism to repeatedly test, detect, and block those failures under production constraints.

You need to:

• Structure data as sessions → traces → spans.
• Capture domain-specific ground truth and golden paths.
• Encode expectations as evaluators, then distill them into Luna-2 models.
• Run those evaluators continuously in production as guardrails, not as one-off experiments.
• Use Signals to turn newly discovered patterns into reusable evaluators, so every incident upgrades your protection.

That’s how you stop flying blind. That’s how you make failures reproducible, fixable, and—eventually—rare.

Get Started