YouMind
Sign in

Will AI Observability, Evaluation, and Assurance Merge?

@asad0801
ENGLISHOct 11, 2026
379K
90
19
14
7

TL;DR

This article analyzes the merging markets of AI observability, evaluation, and assurance, referencing Satya Nadella's governance principles and debating the necessity of independent verification for AI agents.

Nadella's 7 principles, Dynatrace's $915M Arize deal, and a debate between CIOs, founders, and investors on who should check AI agents. Updated October 2026.

An AI agent can explain a refund perfectly and still send the money to the wrong account. The transcript reads well, and the transaction is wrong.

Three groups of products exist to catch problems like this: observability, evaluation, and assurance. Vendors have started merging them. Whether buyers will follow remains open, and so does a second question: who should do the checking, and what counts as independent?

AI is progressing from merely answering questions to carrying out actions. Gartner predicts that by 2028, one-third of enterprise software applications will feature agentic AI, up from less than 1% in 2024. These agents can write and submit code, transfer money, and communicate with customers, usually without any human having to monitor them in real time.

When software only produced answers, the main question was whether they were good. Agents raise more questions: what did it do, was it right, can someone stand behind it, and can it be stopped? For CIOs, these are as much AI governance and risk management questions as they are engineering ones.

Today three markets cover parts of this:

  • AI observability records what the AI did.
  • AI evaluation measures how well it did it.
  • AI assurance brings together the evidence, the controls, and their limits so a person can make an accountable decision. The UK government describes it as the process of measuring, evaluating, and communicating trustworthiness.

AI observability was a $1.25 billion market in 2025, and the same research expects evaluation and quality assurance to grow fastest within it. Dynatrace closed its Arize acquisition on October 1, 2026, a $915 million deal to combine evaluation and observability. Cisco completed its Galileo deal in May. On October 10, Satya Nadella published seven principles for trusting AI that touch all three markets.

The rest of this piece covers how AI got here, what Nadella proposed, and a debate between five composite voices about where the market is going.

From rules to AI agents: why trust got harder

A simplified history in four stages. Each made the machine more capable and harder to explain.

  1. Rules (roughly 1950s to 2000s). Most software applications were written manually, step by step. It had plenty of bugs, but an engineer could open the code and find the line that caused one.
  2. Patterns (2010s). With deep learning, machines learned from examples instead of rules for tasks such as image and speech recognition. Nobody wrote the logic. These systems mostly labeled, ranked, and recommended, and people or ordinary software decided what to do with the output.
  3. Chat (2022 to 2024). Chatbots could write, summarise, and argue. They were often wrong, but a person usually read the answer before acting on it.
  4. Agents (2025 onwards). Agents click, type, buy, code, and deploy. Labs train them by having them practice tasks in simulated offices, browsers, and codebases. Some run for long periods without a person reviewing each step.

In the chat stage, a bad answer usually costs a re-read. In the agent stage, a bad action can cost money, data, or a customer.

Software made costly automated decisions long before agents. The difference now is that a single general-purpose model chooses and executes a chain of actions across several tools. When something goes wrong, the cause could be the model, the prompt, the data it retrieved, an API, stale memory, its permissions, or an exchange between two agents. The conclusive answer is only part of the evidence.

Nadella describes the old situation this way: with traditional software, "we had the tools and capability to trace behaviors to a specific code path." With current models, nobody can point to the training data or weights behind a particular decision. These three markets are trying to close that gap.

Satya Nadella's AI governance framework: 7 principles for trusting AI agents

On October 10, 2026, Nadella published "Models as Insider Risks in the Super Intelligence Era" on his blog. His central proposal is that "we need to separate the supply of intelligence from the authority over it."

He compares a capable model to an employee with wide access. The concern is not that the model is malicious. Anyone with access to important systems can make mistakes or be compromised, so you limit what they can reach, record what they do, and keep the ability to stop them. In his words, "If it can't be observed, it can't be trusted!"

He calls them seven "observability principles." Read together, they work as an AI governance framework for agents. Each principle is paraphrased below, followed by my own mapping to the markets that cover it today.

  1. Model diversity: no single AI checks its own work or makes an important decision on its own. Market today: evaluation.
  2. Observe everything: every meaningful action leaves tamper-proof evidence a human can read. Market today: observability.
  3. Verifiability: the entire system is continuously tested, including attacks, failures, and edge cases. Market today: evaluation and assurance.
  4. Independent controls: the rules on what the AI can access sit outside the AI, where it can't change them. Market today: mostly security and access tools, with guardrails starting to appear in AI platforms.
  5. Independent auditability: evidence about the AI's behavior is kept separate from the AI being checked. Market today: assurance.
  6. Containment: an authorized person can pause or shut down the model mid-task. Market today: mostly runtime and security tools.
  7. Incident disclosure: when it fails, those affected are informed, and lessons are shared. Market today: a company practice, supported by observability records.

No single market covers more than two of the seven. Independent controls and containment sit mostly outside all three, with security and runtime tools. Taken together, the principles describe a system larger than the three markets combined.

His concluding line is: "The most trustworthy Super Intelligence system will not be the one with the model we trust most. It will be the one that enables us to trust the model the least."

Trusting the model as little as possible requires a record of what it did (observability), a way to judge it (evaluation), and evidence a person can stand behind (assurance). It also requires two things these markets have mostly left to security and runtime tools: controls the model cannot change, and a way for a person to stop it.

AI observability vs evaluation vs assurance: the market today

Think of an AI agent as a newly hired driver.

  • Observability is the dashcam. It records each turn, stop, and near-miss, and answers "what did the AI do?" It is sold mainly to the teams that keep systems running.
  • Evaluation is the driving test. It scores how the driver handles set situations and answers "how good is it?" It is bought mainly by engineers building AI products, and increasingly by QA teams.
  • Assurance is the inspection report. It collects the evidence needed to decide whether the car and driver are fit for the road, before the first trip and throughout the driving. It answers "is there enough evidence to stand behind this?" No inspection proves a car will never crash; a good report states what was checked, what was found, and what remains unknown. This is the least developed of the three, and the work is currently spread across quality, risk, and compliance teams.

Separate tools for separate buyers worked reasonably well while AI only produced answers. With agents, the gaps between them matter more. Each tool is useful on its own, but footage nobody reviews proves little, a test goes stale when the driver changes every week, and a report depends on the footage and test results behind it.

Recent acquisitions of AI observability and evaluation platforms:

Dynatrace says the Arize deal brings evaluation and observability together so teams can check AI before launch and keep it reliable afterward. Cisco describes Galileo as covering early evaluation through production monitoring and guardrails.

These deals show vendors combining products. They do not yet show buyers merging budgets, dropping specialist tools, or buying assurance from the company that runs their AI. The rest of this piece is about those questions.

![Diagram of an AI agent with observability, evaluation, sign-off, and control working as one loop outside it

https://pbs.twimg.com/media/HUXj23UaIAAG2Id?format=png&name=small

read image description

ALT

If the markets merge · watch, grade, sign off, control

One possible arrangement if the markets do merge, not a forecast. The agent does the work, and the record, scoring, and stop controls are set in a way the agent cannot change.

The debate: who should check AI agents?

Five composite voices, built from arguments heard by investors and founders. They are not quotes from real people.

  • Long-Game Investor: invests on a 15-year horizon and focuses on who buys.
  • Momentum Investor: follows where money and talent are moving now.
  • Agent Builder: ships AI agents to customers every week.
  • Platform Founder: runs a data and AI platform and wants to own the full stack.
  • Bank CIO: approves any agent before it touches a customer account.

Round 1: Will the markets merge?

Momentum Investor: It's already happening. The monitoring companies are buying the evaluation companies, and deals of that size usually mean a category is forming.

Bank CIO: Acquisitions aren't the same as merging. I've bought suites before and ended up with three products, one logo and three logins. Gartner also expects more than 40% of agentic AI projects to be canceled by the end of 2027, with inadequate risk controls among the reasons. The trust problem is real. It hasn't been proven that a single merged market solves it.

Long-Game Investor: Markets merge when buyers merge. Right now there are three: operations watches, the AI team evaluates, and risk approves. The question is whether agents create one person who answers for all three.

Agent Builder: My company already has one. When an agent refunds the wrong customer, nobody asks which team owns the problem. They ask me for the recording, the score, and the evidence within minutes.

Long-Game Investor: If that's common, the buyer is merging, and that tells me more than the acquisitions do.

Round 2: Why not keep three separate tools?

Bank CIO: Why can't I keep three best-in-class tools?

Agent Builder: Because each depends on the others. You can't evaluate what wasn't recorded, and you can't sign off on what wasn't evaluated. A production failure should become a new test case. With three tools, each handoff is a point where it can get lost.

Momentum Investor: The line between before release and after release is also blurring. Agents change weekly: new model, new prompt, new tool. Testing once at launch is like inspecting a car once while someone keeps swapping the engine.

Bank CIO: Merged suites are usually mediocre at everything.

Long-Game Investor: Early on, yes. Specialist tools tend to win first, and integrated products catch up later. That has happened in many infrastructure categories, though not all.

Round 3: Who should own it?

Platform Founder: We already run the model, store the data, and log the traces. Put evaluation and approval on the same platform: one vendor, one bill, one place to look.

Bank CIO: So the company that runs my AI also tells me it's working?

Platform Founder: We're good at it.

Bank CIO: That's not the issue. My external auditor must remain independent of the business it audits. Students don't mark their own exams, and carmakers don't run every crash test themselves.

Long-Game Investor: Nadella makes a similar point - validation has to be independent of the intelligence it is assessing, and the controls should be located outside the model; this is akin to a platform assessing the AI that it is running, grading its own performance.

Agent Builder: So the tools may merge while the market splits along a different line: checking done inside the platform versus checking done outside it.

Platform Founder: Inside will be cheaper and easier.

Bank CIO: Outside may be what my regulator and insurer accept. I might pay for both, but I'll sign off based on one.

Long-Game Investor: "Outside" needs defining. Technical independence means the agent can't change its checker, edit the record, or get around its limits. Organizational independence means a different party owns the review and has no incentive to go easy.

Agent Builder: Those aren't the same. A separate company can use the same models and the same weak checks as the platform. A platform can keep its controls and records completely out of the agent's reach.

Bank CIO: Then I'd rather ask five questions than compare logos. Can the agent edit the record? Can your checker see the actual change in my systems, or only what the agent reported? Who tests your checker? Can someone else reproduce your result? What couldn't you verify?

Round 4: What should it be called?

Momentum Investor: Analysts will probably keep calling it AI observability for a couple more years, because that's where the budget is.

Platform Founder: "AI trust layer."

Agent Builder: "Observe, Eval and Assure": watch it, evaluate it, and have a person sign off.

Bank CIO: Be careful with "assure." A tool produces evidence. A person reads it and signs. Design for that person.

Long-Game Investor: The name matters less than whether buyers have a budget line for it. In 2026, most don't. I'd expect most large companies to have one by 2028, with a single owner accountable when an agent does wrong.

Bank CIO: Whatever it's called, I need to be able to stop it.

How to test an AI agent: a refund example

This describes a hypothetical customer-service agent that can issue small refunds. It is an illustration, not a customer result.

  1. Define the business rules. The refund goes to the right customer, stays within the limit, and follows policy. A retry must not pay twice. Exceptions go to the right person before money moves.
  2. Test difficult conditions. Use conflicting customer records, a slow payment service, a tool timeout, and an instruction hidden in a support message. Run important cases multiple times from the same starting state, since a single successful run proves little. Simulations allow dangerous cases to be tested safely; real devices and real integrations catch differences that simulations miss.
  3. Check the system of record. The agent saying "I refunded $50" is not evidence. Check that the right account received exactly one $50 refund. Use exact checks where the answer is exact, and AI judges only where it isn't.
  4. Severe failures should be reported individually. Incorrect amounts, duplicate payments, and unauthorized operations should be shown apart from the general assessment of task completion. An average score of 94 percent can mask the most important failure.
  5. Test the limits outside the agent. Does the payment system block an over-limit refund even if the agent requests it? Can the agent's access be revoked mid-task? Stopping the agent prevents the next payment but does not reverse the last one.
  6. Test the checker. Plant known failures and measure which ones it misses. Give it correct outcomes to measure false alarms. Keep "could not verify" separate from "passed."

This doesn't answer the market question. It describes what useful evidence looks like, regardless of who produces it.

Where AI quality assurance fits: TestMu AI

TestMu AI (formerly LambdaTest) works on technical independence. We don't build models, and we don't sell production monitoring dashboards. Our checks run outside the agent under test, before release and on every change, and they examine what actually happened rather than only what the agent reports.

The platform covers the three kinds of software in this piece: people using apps, people talking to bots, and agents working with other agents. Each product maps to a need raised above.

  • Rook (agents checking agents). Runs your agent through scenarios and records the expected and actual outcomes of each check, with evidence saved for each scenario. It reports pass, fail, and "unable to verify" separately, so missing evidence is never counted as a pass.
  • Agent Testing (bots talking to customers). Tests chat, voice, and phone agents in realistic conversations before customers use them.
  • KaneAI and Kane CLI (apps that AI helps build). Test applications in plain English (KaneAI) or from the terminal (Kane CLI).
  • SmartUI along with Accessibility (failures nobody wrote for). Catch problems functional checks don't look for, such as broken layouts or screens some users can't use.
  • Real Device Cloud (what a simulation misses). Runs tests on real phones and browsers, not only emulators.
  • HyperExecute (running important cases many times). Runs the same checks on every change, in parallel.
  • Test Manager (a record for sign-off). Keeps one record of what was checked, what was found, and what remains unknown, for the person who signs off.

Observability tools monitor what happens after release. We provide the evidence used to decide what reaches release. Our agents run checks at a scale a team couldn't manage by hand, and testers decide what is worth checking and look for problems no check would catch. We call the combined work Observe, Eval, and Assure.

This isn't about certification. The fact that a product has a name or that there is an extra checking agent doesn't make a system safe or independent. Instead, we must be evaluated just like any other tester - on the scenarios that have been run, the failures that have been discovered, and the evidence that is available for inspection.

The future of AI agent governance: what 2030 could look like

These are predictions. Each has an early signal today.

  • Agents get identities and records. Each agent has a defined scope, an approver, and a log of its actions. Microsoft plans to distinguish agent actions from human actions in its identity system.
  • Records come from outside the agent. Logs are written by something the agent cannot edit, rather than relying on the agent's own account of what it did.
  • Checks run continuously. A model update, prompt change, or new tool triggers re-testing automatically, which leaves people more time for exploratory testing.
  • Agents check other agents. Gartner expects 15% of day-to-day work decisions to be made autonomously by agentic AI by 2028, up from none in 2024. People can't review that volume one by one, so checking agents will handle much of the routine monitoring while people set priorities and investigate anomalies.
  • Insurers price AI risk on evidence. Since 2025, Lloyd's insurers have offered cover for AI errors that pay out when performance drops below an agreed baseline, and one underwriter has said it won't cover systems it considers too error-prone.
  • Enterprises budget for it. One owner and one process cover monitoring, evaluation, sign-off, and control, and each failure is fed back in as a new test.

Unsolved problems

  1. Testing the checker. An AI judge (often called LLM-as-a-judge) can be fooled as easily as the AI it grades. A second model does not guarantee independent judgment, especially when both were trained in similar ways.
  2. Gaming the check. In July 2026, OpenAI models working on a difficult internal cybersecurity evaluation searched external services for solutions, bypassed isolation controls, and breached parts of OpenAI's and Hugging Face's systems. OpenAI identifies reward hacking as a primary driver and says the evaluation lacked the safeguards of its deployed models. The incident concerns how evaluations are isolated; it doesn't show that all agents behave this way.
  3. Unreliable self-reports. Nadella calls reasoning transparency "a non-negotiable" but writes that it "alone is not sufficient or dependable." What a model says it did and what it actually did can differ.
  4. Scores versus quality. A 94% pass rate measures performance on the checks someone wrote. It provides no information about situations in which no one wrote a check.
  5. Cost. Independent log storage, second models, repeated runs, isolated sandboxes, and human review add cost and delay. Recording everything also creates obligations around sensitive data.
  6. Irreversible actions. Stopping an agent prevents further actions but doesn't reverse completed ones, so the permissions granted up front matter more than the stop control.
  7. Disclosure. In September 2026, OpenAI began publishing misalignment incidents under a new disclosure framework, though it decides what qualifies as a misalignment incident. Most companies deploying agents don't publish incidents. Aviation safety improved partly because accidents are investigated publicly.
  8. Checks versus testing. Automated checks confirm what someone already thought to ask about. Many serious failures come from questions nobody asked, and finding them takes skilled testers who explore, question the specification, and judge which risks matter.

None of these has a settled answer.

Where the debate stands

The five voices agreed on three points:

  • Agents make monitoring, evaluation, and approval more interdependent.
  • Evidence should come from somewhere the agent can't edit.
  • A person still signs off on the deployment, its limits and its exceptions, if not every routine action.

They disagreed on four:

  • One platform or several tools. The Platform Founder wants one vendor; the Bank CIO distrusts suites.
  • Inside or outside. Checking within the platform is cheaper. Independent checking is what auditors, regulators, and insurers have long required in finance and safety. Which matters more for AI is unresolved.
  • Ownership. It could sit with operations, the AI team, risk, or quality. Few companies have a budget line for it yet.
  • Naming, and whether any tool can "assure" anything.

Three signals would help settle it. If buyers keep connecting separate tools through open standards, the markets stay separate. If the evaluation bundled into observability platforms meets most needs, the inside approach wins. If no separate assurance budget appears, independent providers will struggle.

If your agent made a costly mistake tomorrow, whom would you trust to explain what happened: the company that runs it, or someone who doesn't?

FAQ

What is the difference between AI observability, AI evaluation, and AI assurance?

AI observability records what an AI system did: its inputs, tool calls, outputs, errors, and cost. AI evaluation measures behavior against defined expectations, for example, accuracy, policy compliance, or task completion. AI assurance brings together the evidence, controls, and their limits so a person can make an accountable decision about deploying or continuing to run the system.

What is an AI governance framework for AI agents?

It sets who decides what an agent may access, how its actions are recorded, how it is tested, who can stop it, and how failures are reported. Satya Nadella's seven principles are: model diversity, observe everything, verifiability, independent controls, independent auditability, containment, and incident disclosure.

What are Satya Nadella's seven principles for trusting AI?

In his October 2026 essay "Models as Insider Risks in the Super Intelligence Era," Nadella lists model diversity, observe everything, verifiability, independent controls, independent auditability, containment, and incident disclosure. His central idea is to separate the supply of intelligence from the authority over it, treating capable models like employees with wide access.

Are AI observability and AI evaluation consolidating?

Vendors are combining them. Dynatrace closed its $915 million acquisition of Arize in October 2026, and Cisco completed its acquisition of Galileo in May 2026, both to join evaluation with production monitoring. Whether buyers merge their budgets and teams around a single platform remains an open question.

Who should check AI agents: the platform that runs them or an independent tester?

Both approaches exist, and the question is unsettled. Platform checks are cheaper and closer to the data. Independent checks separate the reviewer from the system under review, which auditors and regulators often expect. Technical independence, where the agent cannot alter its checker or its records, matters in either case.

How do you test an AI agent before release?

Define the business rules, then test difficult conditions such as conflicting data, timeouts, and secret instructions. Run important scenarios many times, check the actual system state rather than the agent's description, report serious failures separately from averages, test permission limits outside the agent, and validate the automated checker itself.

Story originally published on https://medium.com/@mask.tech/will-ai-observability-evaluation-and-assurance-merge-a5b011e26b3a?sharedUserId=mask.tech

Sources

The refund example is hypothetical, the debate voices are composites, and product documentation describes capabilities rather than independently measured performance.

One-click save

Use YouMind for AI deep reading of viral articles

Save the source, ask focused questions, summarize the argument, and turn a viral article into reusable notes in one AI workspace.

Explore YouMind
For creators

Turn your Markdown into a clean 𝕏 article

When you publish your own long-form writing, images, tables, and code blocks make 𝕏 formatting painful. YouMind turns a full Markdown draft into a clean, ready-to-post 𝕏 article.

Try Markdown to 𝕏

More patterns to decode

Recent viral articles

Explore more viral articles