In May 2026, Meta laid off roughly 8,000 employees, about 10% of its workforce, using scores generated by a set of internal AI systems. By July, 26 of those employees had sued the company, on the grounds that the AI systems never accounted for employees on approved medical, parental, or disability leave. Productivity scores dropped while people were legitimately out of office, and those scores fed directly into who got cut. The case is still proceeding in court, and the layoffs stand.
When the consequences affect someone’s livelihood, the need for accountability only grows. Enterprises must be able to see what an AI did and catch it going wrong before the consequences become irreversible. That is exactly the gap AI observability fills.
AI observability is the practice of tracking what an AI system actually did, at every step, and evaluating whether that output was correct.
Consider an AI agent that processes expense reports. It reads a submitted receipt, checks it against company policy, and approves or flags the expense. Traditional monitoring would confirm the agent ran successfully. It received the receipt, produced a decision, and responded within the expected time. It wouldn’t check its accuracy.
AI observability asks a different question. It checks whether the agent read the receipt correctly, applied the right policy rule, and reached a decision that actually matches what happened on the receipt. An agent can approve every report on time, with zero errors, while still misreading half of them. AI observability’s job is to catch it before it’s too late.
1. It can’t see inside a multi-step process: It tracks a request and a response. It doesn’t show what happened between them, which tool it called, what it retrieved, or what the model decided along the way.
2. It can’t judge the content of an output: It checks status codes and response time, not whether what the model actually said is correct.
3. It doesn’t track failures unique to AI: An agent can get stuck calling the same tool over and over, or a model can invent a tool call that doesn’t actually exist. Neither looks like an outage, so standard monitoring has nothing to flag.
4. It doesn’t show which decision drove the cost. A server dashboard shows the total bill. It doesn’t break that number down by request, so if one particular type of AI decision uses far more resources than the rest, you’d never know which one drives the cost up.
| AI Monitoring | ML Monitoring | AI Observability | |
| What it covers | The AI service’s operational health, uptime, latency, error rate | The model’s pipeline, data quality, feature freshness, prediction accuracy | The entire system a request passes through, retrieval, tool calls, model, output |
| What counts as a problem | The service is slow, down, or erroring | Model performance drops against a benchmark | Any step in the chain produces a wrong or unsafe result, even if every component reports healthy |
| How deep it goes | Confirms the system is up and responding | Flags that model performance has changed | Traces back through the exact steps that led to a result |
| How often it runs | Continuous, real-time | Often scheduled, batch-based checks | Continuous, on every request |
| What triggers a red flag | A latency or uptime threshold is breached | An accuracy or drift metric crosses a threshold | A trace shows a step behaving differently than expected, even with no metric breached |
| Where it fits in the AI lifecycle | Post-deployment, ongoing infrastructure health | Around and after training and deployment | Spans the full lifecycle of a live request |
| Who typically relies on it | Ops and infrastructure teams | Data scientists tracking model health | Engineers and product teams evaluating the full system |
An AI system isn’t one single unit. A single request travels through four distinct layers, and a failure in any one of them can produce a wrong result while the rest of the system reports normally.
It is the layer where a user’s request first enters the AI system and where it delivers the final response back to them. Problems at this layer are usually about how it captured a request or showed a response .
Let’s take an example of an AI agent handling a customer’s refund request. At this layer, the customer types their refund message and the agent captures it, pulling out details like the order ID and the reason for the return.
It is the layer that decides what steps to take and in what order, before the model produces anything. Problems at this layer usually come from a missing or misordered step in the plan.
Let’s go back to the AI agent handling a customer’s refund request. At this layer, the agent decides to check the order status, verify the return window, and call the refund tool, in that sequence.
It is the layer where the actual reasoning happens. Interpreting whatever input and context it has. Problems at this layer usually mean the model itself got the answer wrong, regardless of whether it followed the right steps .
Back to the refund agent, the model reads the return policy and the order details it received, and decides whether to approve the refund.
It is the layer of the servers, GPUs, and network the entire system runs on. Problems at this layer are the traditional kind, like slowdowns, crashes, or dropped connections.
For the refund agent, this shows up as the refund tool timing out or the connection to the payment system dropping mid-request.
A doctor doesn’t just know a patient could develop a fever, they take the patient’s temperature to know if they actually have one. An AI system needs that same kind of ongoing measurement, as a way to check if it’s actually failing.
What it means: It measures how long a request takes to complete, from the moment it sents to the moment a full response comes back.
What to track: For an agent, it’s the time spent gathering context, waiting for a response to begin, and generating the full answer. Breaking it down by step shows whether a slow response comes from the model itself or from a tool call upstream.
Why it matters: A single slow step anywhere in an agent’s chain can drag down the whole response, and a combined number won’t tell you which step to fix.
What it means: It measures what a single request or session actually costs to run.
What to track: Cost broken down by session, by user, and by which specific call or decision drove it.
Why it matters: Two requests that look identical from the outside can cost very differently. One tool call might succeed on the first try. Another might retry five times before succeeding, that would drive up cost without ever showing up as an error.
What it means: It measures whether an output was actually correct, safe, and useful for the situation it was responding to.
What to track: Check whether the response actually matches what the request needed, whether it’s factually accurate, relevant to what the request asked, and safe to act on.
Why it matters: Without tracking quality, only the customer notices a wrong output, after it has already reached them.
What it means: It is an ongoing, automated process that grades the quality of outputs, using rules or a second model instead of manual review.
What to track: Outputs scored either against fixed rules, or by a second model checking them against a standard, with the weakest ones flagged for review.
Why it matters: As agents make thousands of decisions a day, no team can manually review each one, so evaluations are what make catching a quality problem possible at that scale.
Agentic AI adds two layers of complexity: agents that work with other agents, and agents that make dozens of autonomous decisions inside one task. Both need observability in ways a single request-response check doesn’t cover.
A workflow often runs through more than one agent, such as one agent verifying a booking and another completing the payment. A failure here isn’t always the second agent’s fault. It can be acting correctly on the bad context that the first agent passed along, which means observability has to trace the handoff itself.
Inside a single agent’s workflow, an escalation to a human is one of the clearest signals. One escalation is normal. A repeated pattern for the same type of request means the agent is missing a tool or training it needs.
An agent’s effectiveness can decay over time even without any change to the agent itself. A fraud detection agent might get less accurate simply because fraud tactics evolve. Observability here means watching for a gradual shift in response patterns.
At AISquared, AI observability is the final layer of our AI Controls Framework, Observability and Continuous Improvement.
We trace each prompt step by step, from context-building to the final response, and track model speed, failure rate, and token usage.
Break costs down by message, session, app, and user, and monitor connection health, sandbox start and deploy times, and tool errors behind the scenes.
We also flag which users are seeing the slowest sessions or incomplete prompts.
Mark every release on the dashboard, so a performance shift is easy to trace, and you can switch off the whole layer with one setting.
Meta laid off roughly 8,000 employees based on scores an AI system generated. The underlying lesson here is about what happens when an AI system makes consequential decisions and nobody can reconstruct why.
AI observability isn’t an optional add-on for later. It’s the difference between an AI system you can trust and one you’re hoping works. As agents take on more of the decisions that used to sit with a person, the ability to trace what actually happened, at every layer, on every request, stops being a nice-to-have and becomes the baseline for running AI in production at all.
Yes! A managed LLM provider is responsible for the model’s uptime and API reliability. If you’ve built an agent on top of that model, one that reads your data, calls your tools, and makes decisions inside your workflows. The failures such as, a misread input, a wrong tool call, a decision based on stale data, all happen on your side of that boundary, and only your own observability layer can catch them.
Observability is what makes governance possible to enforce. Governance sets the rules, who can access what data, which decisions need human review, what counts as an acceptable output. Observability is the record that proves whether a given request actually followed those rules. Without it, a governance policy is a document. With it, a governance policy becomes something you can audit.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。