What an AI Control Plane Actually Does

As companies add more agents, models, and AI-powered workflows, something has to decide where each request goes. This episode explains the AI control plane in plain English: how it routes work, chooses models and tools, limits access and authority, records results, handles failure, and creates an operating job of its own. Reza follows one refund request through the shared layer, then looks at model choice, Box's new AI roles, provider risk, and where companies can start.

Read the full issue: https://quanta-bits-newsletter.beehiiv.com/p/quanta-bits-july-11-2026
Subscribe to Quanta Bits: https://quanta-bits-newsletter.beehiiv.com/subscribe

Transcript

SPEAKER_00 0:01

Picture poor requests arriving inside the company at about the same time. A customer wants a refund. A salesperson wants help reviewing a contract. Finance has an invoice that doesn't match the purchase order. And somebody wants to know the weather before a business trip. Those requests should take different paths. The weather question probably shouldn't use AI at all. A weather service can answer it faster and for less. The contract may need a review agent that sends material risks to legal counsel. The invoice may need ordinary rules before AI gets involved, and the refund may be simple enough to approve automatically or unusual enough that a person should look at it. Something has to decide where the work goes before an agent starts doing it. Hey, I'm Reza Markabadi. Welcome back to QuantoBits. This week I want to explain what an AI control plane actually does. The name sounds technical, the idea is much simpler. It is the shared set of rules that decides how AI work moves through a company. I recently listened to Dallas Dolan at PWC Use the Weber example, and I liked it because it makes the problem obvious. If one person sends a better request to an expensive model, nobody cares. The cost is tiny, but now multiply that by thousands of employees, several models, dozens of agents, and requests that reach into customer finance, HR, and legal systems. The default starts to matter. TechCrunch reported that Uber used its annual AI budget in four months and then introduced limits on how much employees could spend using AI. Small choices become material at a scale. Which model gets called how many times does an agent retry? How much information gets sent with the request? Does a person have to correct the answer afterward? And cost is only one part of it. Some models are better at certain jobs, some are faster, some may not be approved for sensitive information. A provider can have an outage, access can change because of government rules or vendor decision. Once AI use gets large enough, a default model becomes a budget and risk decision. There isn't one agreed definition of an AI control plane, so let me give you the practical one I use. Think of it as the shared rules and record keeping around AI work. A request comes in, a gateway or workflow system uses those rules to look at who made the request, what kind of task it is, what information it involves, and how much risk it carries. Then it sends the work to the right place. The right path may be an agent, model, ordinary software service or person. Sometimes it is not AI. The control plane defines the allowed paths. The gateway or workflow system applies those rules to each request. The agents, people, tools, and business systems do the work. And this is where I think the idea can get confusing. If you automate one refund process, you have automated the workflow. That can be useful, but it is not yet a company controlled plane. The difference is reuse. The refund process, contract review, invoice check, and employee request all draw from the same approval model list, identity rules, cost records, security checks, logs, and backup process. Let's follow the refund request because it shows the decision without making it too abstract. First, decide whether AI belongs in the path at all. The purchase date, refund window, and amount can probably be checked with normal software rules. Those checks are straightforward. A model adds cost and a chance of error without adding much judgment. But imagine the customer has long history, the policy is unclear, or the product failed in a way the rules don't cover. Now an agent may be useful. Second, choose the right agent and model. A customer service agent might use a less expensive model for common exceptions. A stronger model may be worth the cost when the policy and customer history are harder to read together. That choice should come from tests on the company's own refund cases, not a public ranking that has nothing to do with the work. Third, limit what the agent can see and do. Give it the order, the relevant policy, and the part of the customer history it needs, then decide whether it can read, recommend, draft, or act. An agent can recommend a $50 refund without having permission to issue an unlimited payment. This is also where security gets real. A bad instruction can be hidden in an email, document, or customer message. People call that a prompt injection. The control plane can screen the request, reject actions that break policy, and require approval for sensitive work, but it cannot make that risk disappear. The payment system still has to check identity, approval, and transaction limits. The control plane adds a layer of protection. It does not replace the controls in the systems underneath it. Fourth, check the result and decide what happens next. The company should be able to see what agent and model handle the request, which tools they used, what it cost, whether the answer passed its test, and whether a person stepped in. If something fails, the workflow might try, switch models, stop or ask a question. But the right response depends on the work. Retrying a lookup is usually harmless. Before retrying a refund, the payment system has to check whether it already happened. Otherwise, the customer can get paid twice. The control plane is useful because it keeps these decisions consistent across many workflows. There's a catch here, of course, a control plane creates work of its own. If many AI requests pass through one layer, that layer becomes important infrastructure. A bad routing rule can affect several agents at once. An outage can slow down more than one business process. The layer adds logs, storage, connections to maintain, and another system for the security team to protect. It can help control AI costs, but it also has a cost. And somebody has to own it over time. That doesn't necessarily mean creating a large new team. Models change, prices change, providers go down, government rules change, business workflows change, new attacks show up. The real examples used to test the system six months ago may no longer resemble the requests people are sending today. Business owners have to say what a good result looks like. Security has to keep access rules current. Technology teams have to maintain the routing, tool connections, backups, and logs. Somebody has to rerun the tests when a model changes. That recurring work is part of AI operations. The software gives the team one place to apply those decisions. It still takes people to keep the rules, tests, and backups current. So what would I do if I were starting tomorrow? Pick one workflow with enough volume, cost, risk, or customer impact to matter. Name the business owner, record what it costs today, how long review takes, and how often it fails. Then define where AI belongs, what the agent can access and do, how you will judge the result, and what happens when it fails. But build those decisions as company rules, not instructions hidden inside one agent. The next workflow should be able to reuse the approved model list identity rules, security checks, cost records, logs, and backup processes. And don't start by buying or building a large new platform. Use the identity workflow, approval login, and gateway tools you already have and a shared service when several workflows create the same need. Start small, but don't bury the rules inside one agent. Two other stories from the newsletter to share. First, I use Fable to help make last week's issue and GPT 5.6 for this one. So far, Fable has worked better for me when the job needs strategy, judgment, or design. GPT 5.6 has failed faster and more decisive when I want it to execute. That is one person's experience, not a benchmark, but it shows the operand in question. Which model fits this job at this cost under these rules? Second, the New York Times reported that Box has created 13 kinds of jobs because of AI. The new roles include AI architects, automation engineers, people who test models, and engineers who help customers put AI into real workflows. Box also says it has not slowed down software engineering hiring because people working with agents can build more. I like that story because it is more realistic than the idea that AI simply removes jobs. The work moves, somebody still has to connect systems, test results, help people use the tools, and keep the whole thing running. I love this Vesuvius challenge story. A scroll was burned and buried when Mount Vesuvius erupted in AD 79. Physically opening it would destroy it, so researchers used scans and machine learning to read the layers while it stayed closed. The first results appear to be Greek philosophy rather than the lost works scholars hope to find, but hundreds of scrolls and fragments remain unopened. If the method keeps working, AI could recover writing that has been out of reach for almost 2000 years. AI helped scholars read a scroll that human hands could not safely open. And for after hours, I finished The Final Problem by Arturo Perez Roberte, and it became a favorite. It is a locked room mystery set on a Greek island in 1960. The main character is an actor who once played a famous detective and now has to solve a real death. So it is a murder mystery about murder mysteries, and the book knows exactly what it is doing. What I liked was the craft. The clues are not only things people say or objects somebody finds. Some of the best clues are omissions and silence. It moves quickly, trusts you to follow the clues, and never get so clever that the mystery stops being fun. That's it for this week. The full issue with all the links and sources is in your inbox or at quanta bits newsletter.behive.com. I'm Reza Markabadi. Thanks for listening. See you next week.