1. Capture everything
Full context, reasoning, actions, and results recorded in real time. You cannot retroactively log what was never written down.
Observability Is Not a Feature for AI Agents. It Is the System.
Engineering — — by Mahmoud Zalt
AI agents do not crash cleanly. They loop, drift, and quietly degrade. Here is the six-layer observability architecture that production agents actually need.
We run an AI workforce in production. Marketing, sales, support, and operations employees that work for weeks at a time, hand off tasks to each other, and make hundreds of decisions a day with no human watching each one. After enough time operating them, one lesson reshaped how I build everything: **you cannot run agents you cannot see.**
In the era of autonomous AI agents, we have crossed a line. Observability no longer just supports the backend. It is the backend. This article is the architecture underneath that claim: what each layer does, why it matters more than it did in the deterministic world we came from, and the order to build it in.
Benefits
2. One open stack
One tool per layer, unified into a single pane, on data you own. No usage spike should turn into an unsustainable enterprise bill.
3. One correlation ID
A single identity that follows a request across every service, worker, queue, tool, and external API it touches.
4. Continuous evals
Traces say what happened. Scores on live traffic say how well it happened, and catch regressions the hour a prompt changes.
5. Agent-shaped alerting
Loops, tool misuse, goal drift, cost spikes. Failures that never raise an exception, so error monitoring never sees them.
6. A closed loop
Telemetry routed back into the system: monitoring agents that act, failed traces that become regression tests, history that makes the next run smarter.
Why does the old debugging playbook break for AI agents?
Because the old playbook assumes determinism and explicit failure, and agents give you neither. In normal software a request times out, a service 500s, an exception fires. You reproduce locally, read the trace, fix the line. You can even add logging after the incident, because the same input gives the same output every time.
Agents break every one of those assumptions. The same input can produce different reasoning, a different tool choice, and a different outcome on every run. Reproduction is not a reliable step in your process anymore, because the run you are trying to reproduce may never happen again.
And when an agent fails in production it rarely crashes outright. It enters a loop. It calls the wrong tool. It acts on stale context. It slowly stops serving the goal it started with. None of that throws. It surfaces as worse output, higher latency, or a cost spike, long after the decision was made.
| Assumption | Traditional software | Autonomous agents |
|---|---|---|
| Failure signal | Exception, 500, timeout | No signal at all, just worse output |
| Reproduction | Same input, same output | Same input, different reasoning each run |
| Instrumentation timing | Can be added after the incident | Must exist before the run, or the evidence is gone |
| Unit of debugging | A stack frame | A decision path across many steps and tools |
| Question you ask | What error fired? | What did the agent see, and why did it choose that? |
| Time to notice | Seconds, the alert pages you | Hours or days, when a human reads the output |
That last row is the expensive one. The question you actually need to answer is not what error fired. It is what the agent saw, and why it chose what it chose. If your system cannot reconstruct that after the fact, you are not debugging. You are guessing. Observability has to come first not because it is good hygiene, but because it is the only source of truth a non-deterministic system has.
Layer 1: Capture everything, because you cannot log it later
Record the full context, reasoning, actions, and results in real time, before you know which run will matter. When an agent does something wrong at 2pm and you notice at 6pm, you cannot go back and add the log line. The signal either existed or it is gone forever.
In practice that means capturing more than most teams are comfortable with at first. Not a summary of the run. The run.
- **The resolved prompt**, after every template, variable, and injected context has been rendered. Not the template.
- **Every tool call**, with its parameters, its raw result, its latency, and whether it failed or was retried.
- **Every retrieved document or memory**, and the query that pulled it, so you can tell bad retrieval from bad reasoning.
- **Intermediate reasoning and plan revisions**, not just the final answer the user saw.
- **Model, version, temperature, and token counts**, so a silent provider-side change is visible as a change in your data.
- **The state the agent carried between steps**, including what it chose not to do.
Storage is cheap. An unreconstructable decision is expensive. And there is a second payoff most teams miss: today's captured trace is tomorrow's evaluation case and tomorrow's training context. The data you collect to debug is the same data that makes the next run smarter. It is not overhead. It is fuel.
Layer 2: One open stack, one pane, data you own
You do not need an exotic platform for this. You need one tool per layer, unified into a single pane, and full ownership of your own data. Agent telemetry is high volume by nature, so per-seat or per-gigabyte enterprise pricing turns a good month of growth into a budget incident.
| Layer | The question it answers | What it must not do |
|---|---|---|
| Unified dashboard | What is the state of everything, in one place? | Force you to hop between five vendor tabs during an incident |
| Infrastructure metrics and structured logs | Is the system healthy, and what exactly happened? | Store unstructured text you can only grep |
| LLM tracing | What did each call cost, how long did it take, what was the prompt? | Sample away the failed runs you most need to read |
| Product analytics | What did real users actually do? | Ship personal data to a third party by default |
| Error tracking | Which deployed commit introduced this? | Report errors with no release attached |
| Evaluation store | How good was this run, scored consistently over time? | Live only in a notebook on someone's laptop |
The discipline is not in the tooling. It is in deciding, up front, that nothing ships unless it is observable. That single rule is what keeps the stack coherent as the system grows, and it is far easier to hold than to reinstate later.
Layer 3: Correlation IDs are non-negotiable
One identity has to follow one request across every service, worker, queue, tool, and external API it touches. That is the piece that makes the rest of the stack usable. Logs without shared context are noise at scale. Logs that all carry the same identity are a time machine.
The ID alone is not enough though. Enrich every record with the dimensions you will want to slice by during an incident: tenant, user, session, employee, workflow, step, and the release that produced it. Those fields are what turn one lucky query into a repeatable investigation.
The test is simple and worth running against your own system today. When a failure shows up hours later, can one query reconstruct the entire execution end to end, across every process boundary it crossed? If the answer is no, everything downstream of this layer is weaker than it looks, because your evals and your alerts are both reading a partial story.
Layer 4: Evaluate decisions, not just outputs
Traces tell you what happened. They do not tell you how well it happened. For that you need a continuous evaluation layer scoring live production traffic, not a benchmark you ran once the week before launch and never repeated.
Score a sample of real traces with model-as-a-judge checks, custom scorers, and plain rule-based assertions. The most valuable signal is not the final answer. It is the path the agent took to get there, measured against the goal it was given.
| Metric | What it measures | What a drop usually means |
|---|---|---|
| Tool-call accuracy | Right tool, right parameters, right order | A prompt edit or a changed tool description |
| Grounding | Claims traceable to retrieved context | Retrieval quality dropped, or context got truncated |
| Goal adherence | Final output still serves the original intent | Too many steps, or context lost across a handoff |
| Task completion | The job actually finished, not just replied | A tool started failing silently and got retried into a dead end |
| Cost per completed task | Economic efficiency, not raw token count | Loops, retries, or a silent model swap |
| Human override rate | How often a person corrects the agent | The strongest early warning you have, and the cheapest to collect |
Two disciplines make this layer worth the cost. First, treat the eval set as versioned code, so a score today is comparable to a score last month. Second, run the evals against every prompt and model change before it reaches all your traffic, so regressions surface as a failing check rather than a customer complaint a week later.
Layer 5: Monitor beyond infrastructure
CPU and uptime tell you the box is alive. They tell you nothing about whether your agents are behaving. The failures that actually hurt in production are agent-shaped, and most of them are silent: they produce no error code, so error-log monitoring never catches them. You have to monitor for them on purpose.
| Failure mode | What it looks like | What catches it |
|---|---|---|
| Infinite loops | Agent keeps working but repeats itself, burning cost with no progress | Step ceilings plus no-progress detection |
| Tool misuse | Calls the wrong tool or with bad parameters, exceeds intended scope | Tool-call accuracy scoring and permission checks |
| Goal drift | No single step fails, but the final output no longer serves the original intent | Compare first-step vs final-step reasoning against the goal |
| Silent degradation | Quality slowly drops with no error and no crash | Continuous eval scoring on live traces |
| Cost and latency anomalies | A spike with no obvious cause | Metrics with alert thresholds on spend and p95 latency |
| Broken business workflow | Every service is green, but the work stopped moving through the pipeline | Alert on business outcomes, not components: tasks completed per hour |
Then route the alerts like you mean it. Tiered channels separate a broken user journey from a noisy background warning, so the page that wakes you up is always the one that matters.
- **Critical:** users are blocked or money is at risk. Wakes a human immediately, day or night.
- **Infrastructure:** a component is degraded but the work is still flowing. Same-day attention.
- **Business:** an outcome moved outside its normal band, like signups, spend, or completion rate. Reviewed in daylight, never paged.
- **Silence:** the dead man's switch, which fires an incident when the telemetry pipeline itself goes quiet.
That last one is the alert most teams forget, and the worst outage is exactly the one where your monitoring also went down and never told you. An agent platform is especially exposed here, because a quiet dashboard and a healthy system look identical from the outside.
This is the layer where observability stops being a passive dashboard and starts being a control system. You are not just recording what the agents did. You are setting the boundaries that decide when a run gets stopped, escalated, or paused before it can cascade into the next agent and the one after that.
Layer 6: Close the loop, telemetry as autonomous fuel
Here is where agentic systems pull ahead of everything that came before them. In classic software, telemetry is for humans staring at dashboards. In an agentic system, telemetry is fuel the system can consume on its own. A reliable feedback loop has four stages: detect, diagnose, decide, deploy. Observability owns the first two, and increasingly the agents can drive the rest.
- **Monitoring agents** watch the telemetry stream and act on anomalies without waiting for a human.
- **Failed traces and low eval scores** flow to coding agents that propose root-cause fixes, which a human reviews before anything ships.
- **Execution history becomes dynamic context**, so the next run starts smarter than the last one did.
The strongest pattern in the field right now is turning a production failure directly into a permanent regression test. A trace that went wrong becomes an eval case that runs on the next change, so the same mistake can never ship twice. The loop from incident to guardrail shrinks from days to minutes.
Keep one human gate in that loop on purpose. Agents can detect, diagnose, and propose all day, but the change that reaches production should still pass a review. That single boundary is what separates a self-improving system from one that can confidently automate its own mistakes.
How to start, in the order that actually works
- Instrument one flow end to end — Pick your highest-value agent path and give it a correlation ID that survives every hop, plus full capture of prompts, tool calls, and results. One complete flow beats partial coverage everywhere.
- Make errors release-aware — Attach the deployed commit to every trace and error before you tune anything else. Without it, you will keep debugging code that was never running in production when the failure happened.
- Turn ten real failures into eval cases — Your first eval set should come from actual production traces, not synthetic examples. Score tool accuracy, grounding, and goal adherence, and version the set like code.
- Add the agent-shaped alerts — Step ceilings, no-progress detection, cost per completed task, p95 latency, and a business-outcome alert. Route them into tiers so only the critical tier can wake someone up.
- Add the dead man's switch — One heartbeat that fires an incident if the telemetry pipeline goes silent. It is the cheapest alert you will ever build and the one that saves the worst outage.
- Close the loop — Route failed traces and low scores back into the system: automated root-cause proposals, a human review gate, and execution history as context for the next run.
This is the exact foundation everything else at Sistava sits on top of. Our AI employees are observable by default, every action traced on one identity, every decision scored, every failure able to become the next guardrail. That is what lets them run autonomously for weeks without quietly going off the rails, and it is the difference between an agent you can actually trust in production and one you are only hoping behaves.
If you are building this yourself, the good news is that none of it requires exotic technology. It requires deciding early that the telemetry is part of the product rather than a thing you add once something goes wrong. Every team that gets burned here got burned the same way: the run they most needed to read was the one they never recorded.
FAQ
What is AI agent observability?
It is the practice of recording and scoring everything an autonomous agent sees, reasons, and does, so any run can be reconstructed and judged after the fact. It goes beyond traditional monitoring because agent failures rarely produce errors: the agent loops, misuses a tool, or drifts from the goal while every service stays green. Observability is what makes those silent failures visible.
How is it different from normal application monitoring?
Normal monitoring watches components: CPU, memory, error rate, uptime. Agent observability watches decisions: which tool was chosen, what context was retrieved, how many steps were taken, whether the final output still served the original goal. A system can be perfectly healthy by infrastructure metrics while its agents produce steadily worse work.
What should I log for an AI agent?
The resolved prompt after all templating, every tool call with parameters and raw results, every retrieved document and the query that pulled it, intermediate reasoning and plan changes, model and version and token counts, and the state carried between steps. All of it stamped with one correlation ID plus tenant, user, session, workflow, and release.
Is capturing everything too expensive?
Trace storage is one of the cheapest lines in an agentic system, far below inference cost. The expensive outcome is an unreconstructable decision that costs days of engineering time or a lost customer. Control cost with retention tiers rather than by capturing less: keep raw traces for weeks, keep the aggregated metrics and eval scores computed from them for much longer.
What is a correlation ID and why does it matter for agents?
It is a single identifier attached to one logical execution and passed through every service, worker, queue, tool call, and external API it touches. Agent runs are long, asynchronous, and cross many process boundaries, so without a shared ID the evidence for one failure is scattered across systems that never reference each other. With it, one query returns the whole story.
How do you evaluate an agent in production?
Sample live traces and score them continuously with model-as-a-judge checks, custom scorers, and rule-based assertions. Track tool-call accuracy, grounding, goal adherence, task completion, cost per completed task, and human override rate. Version the eval set like code and run it against every prompt or model change, so regressions appear as a failing check instead of a customer complaint.
What is a dead man's switch in observability?
It is an alert that fires when expected telemetry stops arriving. Every other alert depends on data flowing; if the pipeline itself breaks, your dashboards go quiet and look exactly like a healthy system. A heartbeat that raises an incident on silence is the one alert that protects all the others.
Should observability come before prompt optimization?
Yes. Without traces and scores you cannot tell whether a prompt change helped, hurt, or did nothing, so prompt work becomes guesswork with confident-sounding results. Build the measurement layer first and every later change becomes an experiment you can settle with evidence.
If you take one thing from this: before you optimize a single prompt, build the observability layer underneath it. Prompts improve what your agents say. Observability is what lets them improve themselves. In deterministic software it tells you what happened. In an agentic system, it is the only thing that tells you why, and the only thing your agents can learn from. Build on it, not around it.