Each native plane governs its own estate

The native planes cover similar ground, each inside its own walls. Amazon Bedrock AgentCore’s services include a runtime, memory, a gateway that connects MCP servers, identity and OpenTelemetry-compatible observability.² Google’s Gemini Enterprise Agent Platform includes an agent registry, an agent gateway and agent identities.³ Agentforce is a platform for building, running and optimizing agents inside Salesforce, with trusted context and controlled behavior.⁴

Their claims also overlap. Microsoft’s guidance for its own estate names Agent 365, or Entra Agent ID where Agent 365 is not in use at scale, as the authoritative inventory, and it asks for consistent policy across every agent platform.⁵ An enterprise with two or three such planes has two or three candidates for the record of its agents, and it has to settle which record counts before an audit raises the question for it.

Where each plane is authoritative

The handbook’s default keeps each native plane authoritative for identity and runtime inside its own estate. A vendor-neutral plane, which the handbook realizes with MuleSoft Agent Fabric, is then authoritative for the cross-estate inventory, for policy on every call into enterprise capabilities and data, for orchestration across vendors, and for cost and audit.⁴

The split holds only when the planes share what they know. Each agent’s identity should be federated from the plane that issued it, so every plane checks the same identity. One registry has to hold the record of ownership, or an agent that appears in two inventories ends up with two owners or none. Every plane’s telemetry also belongs in one trace, so that an action that starts in one estate and finishes in another can be followed end to end.

The native planes keep running and securing the agents inside their own estates. The vendor-neutral plane governs the crossings, where an agent’s work reaches another estate or the enterprise’s own systems and data.

What to do next

1. CIO. List every agent platform in use, and for each one record which system is authoritative for inventory, identity, policy and telemetry, with a named owner for each decision.
2. CTO. Federate agent identities from the plane that issued them, and send every agent’s calls into enterprise APIs, tools and data through one policy point, whichever estate the agent runs in.
3. CIO and CTO. Agree which registry holds the record of ownership, and send telemetry from every plane to one trace before the next agent platform goes live.

Go deeper

Section 7 of The AI Control Plane Handbook sets this division of labor beside the handbook’s map of requirements to capabilities and the checks to run on any agent platform. Slide 25 of the executive deck puts the table and the default on one page, with speaker notes you can present from.

Small faults move the numbers

The Visual Handbook’s case studies work through three datasets written for the book, a music catalog, a set of house sales and a record of penguin measurements, each with problems planted on purpose.² A first audit of the three turns up the faults below, and every one of them changes a figure someone might quote.

The zero tempos show how quietly a fault can hide. No song plays at 0 beats per minute, so each zero is a missing reading stored as a number, and the mean counts it as real.³ A check with isna() finds none of them, because to pandas a zero is data, and the same is true of codes such as -99 or 9999.¹ The genre column fails the other way. A group-by splits pop into pop, Pop, POP and pop with a trailing space, so the largest of the four groups holds only 161 of the 181 rows.

Each fix is a judgment

A value in the wrong unit is harder to spot, because it still looks like a number. NASA lost the Mars Climate Orbiter in 1999 because one piece of ground software supplied thruster data in English units where the navigation software expected metric units.⁴ The penguin file holds a small version of the same fault. A single flipper length recorded in centimeters, among hundreds in millimeters, raises the column’s standard deviation by about 17%.

The right fix depends on why a value is wrong. The penguin flipper was multiplied by 10 and kept, because its cause was known.⁵ The three impossible track lengths were removed, while long tracks that were merely unusual stayed in.³ Duplicates barely moved the mean house price, from $184,147 to $184,027, yet they added ten sales to every count and made the sample look larger than it was.⁶

These choices cannot be fully automated, since only the meaning of the data decides whether an age of 0 is a newborn or a missing default.¹ That is why the handbook asks for the reason behind every cleaning step to be written down.² Cleaning done in a script, with its reasons logged, can be checked and rerun by someone else, which a spreadsheet edited by hand never allows.

What to do next

1. Analyst. Before any summary, audit the row count, duplicate rows, missing values in each column and the distinct values of every text column, and look for codes such as 0, -99 or 9999 that stand in for a blank.
2. Developer. Keep the raw file untouched, clean it in a script, and add checks that stop the run when a value leaves its valid range or a key repeats.
3. Analyst and Developer. Write down each cleaning decision and its reason beside the code, and report the row count before and after each step with the result.

Go deeper

Chapter 18 of the Visual Handbook sets out the dimensions of data quality, the common faults and an audit routine, with a notebook that profiles a messy customer table. Chapter 26 runs one first audit on the three teaching datasets. Chapters 27, 28 and 29 then clean each one from raw file to analysis-ready table and give the reason for every step.

Each survey measures something different

In the table below, the middle column shows how far agents have spread in each study, and the last column shows what has not kept pace with them.

The four results can’t be added up or charted as one trend, because their samples differ in country, company size and date, and each study counts something different. Deloitte counted plans to deploy,² KPMG counted organizations building or running agents,³ Microsoft measured agents in active use,¹ and BCG estimated where the value of AI will come from.⁴

Read one at a time, the studies still point the same way. In each one, the measure of adoption runs ahead of the measure of control, whether that control is a governance model, a boundary on what agents may decide alone, or a rule against tools nobody approved.

Companies sense the gap in their own operations. In Deloitte’s 2026 technology predictions, 80% of organizations consider their basic automation mature, but only 28% say so once AI agents are included.⁵ The cost of leaving the gap open shows up in forecasts. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls.⁶ Each of those causes is something a control plane exists to manage, which is why the controls need to be in place before the next wave of agents arrives.

What to do next

1. CIO. Ask for a list of every agent in use, including those built with low-code tools, with a named owner for each.
2. CTO. Route agent actions through one policy enforcement point, so each rule is written once and applied to every agent, whichever vendor built it.
3. CIO and CTO. Agree autonomy tiers before the next rollout. Each agent’s tier should set what it may do alone and what needs a person’s approval.

Go deeper

Section 1 of The AI Control Plane Handbook sets these surveys beside an integration benchmark and an analyst forecast, and explains why coordinating models and agents has become an infrastructure problem. Slide 4 of the executive deck puts the four results on one page, with speaker notes you can present from.

Try it

Before you quote figures like these, Quote a survey figure with its weights and margin of error shows what to check first, with a notebook you can run in Colab.

A definition with edges

A Deloitte Insights analysis from August 2026 defines an enterprise control plane as a governed, intelligent layer that mediates decisions across systems, deciding who can act, what data can be accessed, how workloads execute and how AI agents operate within defined cost, latency and regulatory boundaries.² It resembles service-oriented architecture, but it is event-driven and does more than expose reusable services, because it coordinates workflows as conditions change.

HCLTech’s April 2026 analysis suggests judging a platform by what it governs as well as by what it does, since control planes compete for authority more than for attention.³ The same analysis observes that an agent without identity constraints is automation without accountability.³

Three capabilities turn the definition into questions

Deloitte’s analysis rests the control plane on three capabilities.² Each decides something different, and each can be put to a vendor as a single question.

A product that answers one question well can still leave the other two open. A catalog of connectors speaks to architecture, a model router speaks to orchestration, and an audit dashboard speaks to trust, yet none of them alone decides who may act on what, which is why the definition asks for all three in one governed layer.

A good answer to each question is something a vendor can show on your own systems:

• Architecture. One real business capability, such as checking an order’s status, exposed as a governed API or tool that an agent reaches with its own identity and its own limits.
• Orchestration. One task routed to a model and an agent by rules you can read, covering cost, latency and where the data may go.
• Trust. The record of one completed action, naming the agent, the person it acted for, the policy that allowed it and the approval, if one was needed.

Most enterprises span several ecosystems, so the harder task is coordinating control planes across them. That is the case for a vendor-neutral control plane, one that keeps identity, policy and audit in a layer the enterprise owns while models and agents come from many sources.

What to do next

1. CIO. Put the three questions into your next platform review, and ask each vendor to answer them on one of your own use cases.
2. CTO. Map today’s stack against the three capabilities, product by product, and mark each question that no product answers yet.
3. Architect. Check that identity, policy and audit records sit in a layer you would keep if you changed model or agent vendors.

Go deeper

Section 2 of The AI Control Plane Handbook sets out the definition and the lifecycle a control plane enforces for every agent, from proposal to retirement. Slide 7 of the executive deck puts the three capabilities and their questions on one page.

Try it

Run a broker and its specialist agents from one config file shows orchestration and an approval gate at work in a small agent network you can run in Colab with your own OpenAI key.

Where each change lands

MCP standardizes how agents reach tools and data,² and A2A standardizes how agents collaborate.³ Both are now projects of the Agentic AI Foundation, hosted by the Linux Foundation.^2,3 A third protocol, for agent payments, is moving the same way.

The MCP revision did more than remove state. It documents how OpenTelemetry trace context travels with each call, tightens authorization checks and deprecates several features with a minimum 12-month window.² That window is the deadline for any tool that still relies on a deprecated feature. Agent payments are at an earlier stage, and until the new standards are settled, AP2 is best treated as pre-standard.

For MCP, statelessness means every request carries what the server needs, and no server keeps a session between calls. A server can then run behind an ordinary load balancer, since no request depends on an earlier one. For A2A, an agent card is the description an agent publishes of itself, and a signature lets another agent check who published it before it trusts the work on offer.

The cost of each change depends on how agent traffic is wired. Where every agent connects to every tool on its own, each team re-implements each change in its own code and on its own schedule, and the slowest team sets the pace for everyone. A control plane absorbs much of that work in one place. Its registry can check signed agent cards before one agent trusts another, and its gateway can apply policy to MCP’s standard headers and join every call to its trace, so a change to the protocol becomes a change to one policy, and the same traces show which tools still call a deprecated feature as the window closes.

What to do next

1. Developer. List every MCP server you run, and check which ones still hold session state or leave out the method and tool headers, starting with the servers your production agents call most.
2. AI Engineer. Require a signed agent card before an agent accepts work from another agent, and give no privilege to roles an agent asserts about itself.
3. Developer and AI Engineer. Track the MCP deprecations against their 12-month window, and keep any payment flow built on AP2 behind a person’s approval while the standards work continues.

Go deeper

Section 4 of The AI Control Plane Handbook places the protocols inside a control plane’s routing, context engineering and delegation. Slide 13 of the executive deck sets the protocols beside context engineering and capability discovery.

Every risk on the list has a control

The table maps each risk to the controls that address it in an AI control plane.

Several controls appear in more than one row, and they are the place to start. Approvals bound to the exact action defend against goal hijack and against people trusting a confident draft. One identity per agent, with delegation that narrows at each hop, closes off privilege abuse and limits what a spoofed message between agents can do. Exposure limits that add up across agents and sessions contain both tool misuse and cascading failures.

The threat lists keep growing. Microsoft’s AI Red Team added seven agentic failure modes to its taxonomy in June 2026, among them agentic supply chain compromise, inter-agent trust escalation, session context contamination and MCP and plugin abuse.³ MITRE ATLAS has added agent-specific techniques since December 2025, such as AI Agent Tool Credential Harvesting and Publish Poisoned AI Agent Tool.⁴ Tagging red-team scenarios with these names lets a team’s results map to the vocabulary other teams use.

What to do next

1. Developer. Allow-list the tools each agent may call, validate every call against the tool’s schema, and accept only registered, signed and version-pinned MCP servers.
2. AI Engineer. Bind each approval to the exact action and show the approver the facts behind it, so a polished draft can’t carry a harmful change through.
3. CISO. Name an owner for what enters the agent registry and another for what approvers are shown, because no gateway closes either risk alone, and tag red-team scenarios with the risk names in the table.

Go deeper

Section 5 of The AI Control Plane Handbook covers identity for agents, runtime controls, cryptography and human takeover after the kill switch. Slide 17 of the executive deck puts the ten risks and their controls on one page.

Each milestone has value and evidence

The handbook’s plan runs for 24 months in four phases. Each phase ends in a milestone the business can see, with evidence to report at every steering review.

The architecture delivers value of its own before any use case reaches full scale, from spend visibility at month 3 to faster delivery of every new agent at month 8. Each milestone also brings more of a real use case into production, starting with a first slice that works in assist mode and moving to agents that act in systems of record once the controls are in place.

Expectations of AI payback are shortening. In KPMG’s 2025 Global CEO Outlook, 67% of 1,350 CEOs expected returns on AI within one to three years, where a year earlier most expected three to five.² Google Cloud’s 2026 survey of 2,403 executives found 84% seeing increasing financial returns from AI and 26% seeing returns accelerate year over year.³ Phasing lets a program beat the two-to-four-year benchmark, because read-only and propose-only slices release capacity within months and help fund the controls that the larger gains depend on.

Deloitte’s survey also found that 85% of the leaders it studied use different frameworks or timeframes for generative and agentic AI.¹ A program can do the same, judging its early slices over months and the agents that act in systems of record over a longer horizon.

What to do next

1. Agree the four milestones and the evidence for each with finance before the first phase starts, so every steering review reports against them.
2. Pick a first use-case slice that can run in assist mode by month 3, so the program shows value while the larger controls are still being built.
3. Set one horizon for read-only and propose-only slices and a longer one for agents that act in systems of record, and report each against its own.

Go deeper

Section 8 of The AI Control Plane Handbook sets out the four phases, how three reference use cases phase in, and the first 90 days. Slides 26 and 27 of the executive deck show the plan and the value at each milestone.

What the plus in AI+ stands for

The site’s name reads as AI, plus the data science, math, statistics and Python behind it. The Visual Handbook’s second chapter sets out how those parts fit: statistics makes sense of data, machine learning learns patterns to predict, and data science combines the two with code and domain knowledge to deliver something useful.² Statistics asks why a pattern exists, and machine learning asks what comes next.²

Statistics runs through every stage of an AI system, from collecting the right data to measuring whether the system works once it is live.² A large language model is the clearest case, because it writes by estimating the probability of each possible next word and choosing a likely one.² When a vendor or a team reports a number about such a system, the number is a statistic, and it can be tested like one.

Questions that test an AI number

Three questions catch most of the ways a number misleads. The survey analysis shows each failure on real data, drawn from 134,897 adults in three years of the National Survey on Drug Use and Health.¹

The same discipline applies to the model’s own scorecard. A model’s accuracy is a proportion, so it carries a margin of error exactly as a poll does.³ That margin shrinks with the square root of the test set, which means halving it takes four times as many labeled examples.³ A leaderboard number reported without its margin tells you less than it appears to.

None of the three questions needs advanced mathematics. Each needs a habit of asking before a number goes into a decision, and each has a standard answer that a careful analyst can produce.

What to do next

1. CIO. Ask for the baseline with every accuracy figure, meaning the score of a model that always gives the most common answer.
2. CTO. Require a margin of error, and the sample behind it, on any model metric that decides whether a system ships.
3. Analyst. When a sample over-represents some groups, report the figure weighted to the population and say which figure answers the question being asked.

Go deeper

Chapter 2 of Statistics, Data Science and AI: A Visual Handbook maps how statistics, machine learning and data science fit together, with a notebook you can run. The survey analysis works through all three questions on one dataset, with the code behind every figure.

Try it

Choose the right statistical test in four questions puts two of the three questions into practice, “Compared with what?” and “How sure?”, with a decision map and a clinic dataset to test in Colab.

Why the weights move the number

The survey is a stratified multistage probability sample. Some groups are over-sampled on purpose, so that estimates for them are precise enough to publish, and every respondent carries a weight saying how many people they represent.² Young adults are among the over-sampled groups, and they report depression at much higher rates, so the unweighted figure overstates the national rate by about a third.² A weight undoes the over-sampling. Each young adult counts for fewer people in the population than an older respondent does, so the young adults together count for their true share.

Depression and marijuana move most, and both are concentrated in younger adults, who are over-represented among respondents.¹ Cigarette use moves slightly the other way. The direction and the size of the shift depend on who was over-sampled and on how the measure varies across those groups, which is why no rule of thumb replaces computing both.

Who is in the sample matters as much as how each person counts. The three survey years hold 174,407 respondents, and 34,875 of them are aged 12 to 17, who answer a different set of questions and were never asked the adult depression question.¹ They are a restriction on the population, so every figure in the analysis describes adults 18 and over.¹

The margin of error moves too

The design changes the precision of an estimate as well as the estimate itself. In the same analysis, standard errors that respect the survey’s strata and replicates were 1.74 to 1.96 times larger than naive ones, so a confidence interval built without the design would be roughly half as wide as it should be.¹ With a sample this large, no conclusion reversed, but the reported precision would have been wrong.

A margin of error measures precision and nothing more. It can be small on a sample that describes the wrong population, because it says how much an estimate would vary across repeated samples drawn the same way.³ Weighting fixes who the estimate describes, and the design-based margin says how sure you can be.

Survey numbers often lose this context on the way to a slide. A press release quotes one figure, a vendor deck repeats it, and by the time it supports a decision nobody can say whether it was weighted or how wide its interval was.

What to do next

1. Analyst. Use the survey’s weights and design variables, meaning its strata and its clusters or replicates, for every estimate you publish, and report the design-based margin of error with it.
2. Analyst. When you show an unweighted figure while exploring the data, label it as describing respondents, and keep it out of any headline.
3. CIO. Before a survey figure goes into a board paper, ask whether it was weighted and how wide its margin of error is.

Go deeper

The survey analysis computes every descriptive figure both ways, with the R pipeline and a Python notebook behind it. Chapter 74 of the Visual Handbook explains the margin of error and the three things that drive it, and chapter 70 designs and analyzes a survey from start to finish.

Try it

To weight a survey yourself and check the result against a known answer, open Quote a survey figure with its weights and margin of error, whose notebook runs in Colab with nothing to install.

Accuracy rewards the majority answer

In the analysis sample, 119,664 adults reported no depressive episode and 15,233 did, so a model that always answers “no” is right 88.7% of the time.¹ The penalised logistic regression in the analysis matched that score at the default cut-off of 0.50, and its Cohen’s kappa was 0.04, effectively zero.¹ Kappa measures agreement beyond what chance alone would produce, which is why it exposed what the accuracy figure hid. A kappa near zero means the model agreed with the truth about as often as chance would, given how rare the outcome is.

The model itself carried real signal. Its AUC of 0.7406 means it ranked a randomly chosen person with depression above a randomly chosen person without it about three times in four.¹ The failure was in the decision rule, because the default cut-off of 0.50 sat far above the probabilities the model gives for an outcome this rare. AUC judges the ranking across every possible cut-off, and accuracy judges a single one, which is how the two can disagree so sharply.

Lowering the cut-off to 0.20 finds 39% of the people with depression, at the cost of flagging 15% of everyone for a closer look.¹ At that cut-off, 29% of the people flagged have depression, so about seven in ten flags are false alarms.¹ That rate suits a quick follow-up question and would be far too high for anything costly or intrusive. Which row is right depends on what happens to a person the model flags, and a cheap follow-up justifies a lower threshold than a costly intervention does.

The outcome is rare enough that people without depression outnumber those with it by 7.86 to 1. Class weighting and resampling, the other standard responses to imbalance, move the model along the same trade-off without adding information, so a team still has to choose where on the curve to sit.¹

The Visual Handbook’s chapter on model evaluation shows the same pattern with fraud, where a model that labels every transaction legitimate is 87% accurate and catches no fraud at all.² Any outcome that is rare enough produces the same illusion, from fraud and equipment failure to an agent’s request that needs a human to review it.

What to do next

1. CIO. Ask for the base rate with every accuracy figure, and for the share of the cases that matter that the model actually finds.
2. Analyst. Report recall, precision and kappa beside accuracy for any classifier whose positive class is rare.
3. Data Scientist. Set the cut-off from the cost of each kind of error, and show the people who will use the model a table like the one above before they choose.

Go deeper

The survey analysis shows the classifier, every cut-off and the code behind them. Chapter 115 of the Visual Handbook covers the confusion matrix, precision and recall, the threshold and the precision-recall curve, with a notebook to run.

Try it

Catch a model that is 88.7% accurate and misses almost every case works through the same checks on card-fraud data, in a visual guide and a notebook that runs in Colab.

Defaults that change your numbers silently

The code below shows all three on tables small enough to check by eye. It runs as written on pandas 3.0.

import pandas as pd

# 1. groupby leaves out rows whose key is missing
orders = pd.DataFrame({"region": ["East", "West", None], "revenue": [100, 200, 300]})
orders.groupby("region")["revenue"].sum()                # East 100, West 200, and the 300 is gone
orders.groupby("region", dropna=False)["revenue"].sum()  # keeps a missing-region group of 300

# 2. merge multiplies rows when a key repeats where you expected it once
rates = pd.DataFrame({"region": ["East", "East", "West"], "rate": [0.10, 0.20, 0.30]})
orders.merge(rates, on="region", how="left")             # 4 rows from 3 orders
orders.merge(rates, on="region", how="left", validate="many_to_one")  # raises MergeError

# 3. pivot_table averages duplicate cells unless you choose the function
sales = pd.DataFrame({"store": ["A", "A", "B"], "month": ["Jan"] * 3, "units": [10, 30, 5]})
sales.pivot_table(index="store", columns="month", values="units")                 # A shows 20.0
sales.pivot_table(index="store", columns="month", values="units", aggfunc="sum")  # A shows 40

Grouping drops rows whose key is missing by default, so the group totals stop adding up to the column total.² Pass dropna=False when a missing key should appear as a group of its own, which it usually should in a report.

A merge returns one row for every matching pair of keys. When a lookup table repeats a key that should be unique, every order that matches it is duplicated, and every total built on the result grows with it. The validate argument states the relationship you expect, such as "many_to_one", and raises an error when the data disagrees, while indicator=True adds a column that shows which rows found a match.³

pivot_table combines cells that share an index and a column with the mean by default, so two orders of 10 and 30 units appear as 20.⁴ Name the function with aggfunc, or use pivot, which raises an error when it meets duplicates.

None of the three raises a warning, because each behaves exactly as documented. The damage shows up later, as a total that no longer matches the source system or a dashboard that drifts after a supplier adds a duplicate row to a reference file.

The pattern repeats across all three operations. pandas picks a reasonable default, the default hides a problem in the data, and one argument brings the problem into view, at the cost of a few characters. A plain check catches what the arguments miss, because comparing the row count and the column total before and after each step shows at once when a step has added or lost data.

What to do next

1. Analyst. Check that group totals add back to the column total after every groupby, and pass dropna=False whenever missing keys matter.
2. Developer. Give every merge a validate argument, and use indicator=True while you develop to see which rows failed to match.
3. Analyst and Developer. Name aggfunc in every pivot_table, and count rows before and after each merge and reshape in your tests.

Go deeper

Chapter 151 of the Visual Handbook covers Python, NumPy, pandas, reshaping and charts across five notebooks, from a raw order log to a finished chart. Its fourth notebook works through groupby, merges, pivot_table and melt on real data.