AI's First Demand Is an Ownership Map

This week on Quanta Bits, I talk through why the first real demand of AI agents may be an ownership map. Anyone can build an AI prototype now, but once that prototype needs access to CRM, ticketing, email, finance systems, or customer data, it becomes an enterprise decision. The episode covers why tool ownership is often unclear, why agents make that harder to ignore, and the four questions teams should answer before connecting agents to production systems. I also cover quick hits on Anthropic model access, rising AI costs, Mayo Clinic's AI cancer-screening work, and a short After Hours note on Eden and Middlemarch.

Transcript

SPEAKER_00 0:01

Try this for one minute. Five tools an AI agent will need to touch to do real work in your company. Maybe it is CRM, maybe the data warehouse, ticketing, email, the document store, whatever systems actually hold the work. Now for each one, don't ask who pays for it. Ask who can say yes or no to an agent connecting to it. And then defend the answer. That is the part I wrote about in last week's QuantaBits. Hey, I'm Reza Marakabadi. Welcome back to QuantaBits. The point this week is simple, but I think it matters. Almost anyone can build an AI prototype now. Finance, sales ops, marketing, support. Almost every function has someone who can wire together a useful first version. But the moment that thing needs production access, it is no longer just someone's experiment. It becomes an enterprise decision. The builder can be anyone, approval still needs a name. What I keep seeing, and I suspect a lot of operators will recognize this, is that people get stuck by two or three. Someone says, we want this agent to check customer records, summarize open tickets, update the forecast, and maybe send a note. Sounds reasonable enough. Then you ask who owns the CRM decision? Who owns the workflow decision? Who owns the data? Who decides whether this agent is allowed to act? And suddenly the answer is less clear. Sometimes three people would all claim ownership. Sometimes nobody really owns it. Sometimes the tool was bought by one department, used by another, administered by IT, and depended on by finance. ZLA's 2026 SaaS numbers put the average company at about 305 SaaS applications. They also found that almost half of licenses sit unused. So we are not talking about a tidy little stack where every tool has a clear owner and a clean decision path. For years that mess was survivable. People were the integration layer. If a report looked wrong, someone noticed. If a workflow broke, someone improvised. Agents do not give you that same buffer. They may validate what you tell them to validate, but they don't inherit all the informal judgment people use around messy systems. So the practical problem is not only can we build the agent, increasingly, yes we can. The harder question is who's allowed to let it into the company. There is a security angle here, but I don't want to make it sound more mysterious than it is. Simon Wilson, who co-created Django and writes a lot about AI security, has a phrase I like. The lethar trifecta. He's talking about what happens when an AI system has three things at once access to private data, exposure to untrusted content, and the ability to communicate externally. In plain English, the agent can see sensitive stuff, it can read things from the outside world, and it can send messages or take action. That combination can get dangerous fast. Now take that back into the boring business systems CRM, email, ticketing, data warehouse, shared documents. These hold customer records, pricing, notes, renewals, support issues, financial data, and sometimes quite a bit of internal context nobody meant to expose broadly. If a tool is unowned and then an agent gets connected to it, that unowned tool becomes an operations problem. I have seen the old version of this many times. An integration stops working because it was tied to one person's login and that person left the team. Everyone reconnects it and moves on. But reconnecting it does not answer the harder question, what was this thing supposed to do in the first place? Who would know if it started doing the wrong thing? That was annoying before agents. With agents, it can become an incident nobody can explain. The evidence is starting to point in the same direction. The Cloud Security Alliance ran a survey in March and found that 68% of organizations cannot reliably tell AI agent activity from human activity. Almost three-quarters said agents often get more access than they need. Microsoft own guidance now tells companies to keep a registry for agents, who owns it, and what it is for, where it runs, and what access it has. That sounds bureaucratic, but the first move does not need to be a giant governance program. That is probably how this gets stuck. Start smaller. Pick 10 tools an agent would plausibly touch first. Whatever is real in your company. Then answer four questions for each one. Who owns the application? Who owns the workflow it serves? Who owns the data inside it? And who can judge whether an AI integration should exist at all? If nobody can say no, the answer is no until someone can. That may sound rigid, but I think it is the only thing that scales when some requests arrive faster than committees can meet. The counterargument is fair. If you make this too heavy, you slow everyone down while other teams experiment. I agree with that. Ownership should not mean waiting six weeks for a meeting. It should mean there is a name decision path. Someone can say yes quickly, knows the allowed scope, understands the risk, and knows who gets called if it breaks. That is the balance, not permission theater. A fast name yes. A few other stories in this issue. First, Anthropic had this strange moment where two of its top models, Fable 5 and Mythos 5, got caught in a US foreign use restriction. Anthropic shot access broadly rather than try to figure out eligibility at runtime. The model name matters less than the operating lesson. Access can change because of a regulatory decision, not just because of an outage or vendor incident. If your operations depend on one model, one vendor, one geography, or one access pad, that is now a continuity question. CIOs and CISOs are going to need fallback models the same way they think about fallback systems. Second, the Wall Street Journal had a story about companies starting to ration AI because the bill is rising. Some companies burned through annual budgets in a few months. Uber reportedly used up its agentic AI budget by March. That tells me the experimentation phase is giving way to the operating phase. Last year the question was, are people using AI? Now the better question is what result did we get for the money? Usage is not the same as value. Finance is going to care about cost per outcome. And then on a more hopeful note, Mayo Clinic had a study on an AI model that can spot signs of pancreatic cancer on routine CT scans, sometimes long before diagnosis. I liked it because it uses data the system already collects. No grand reinvention, no new scanner, just reading existing images better. That is the kind of AI story I like. Useful, specific, and grounded in the workflow people already understand. Quick after hours before I wrap, I watched Eden, the Ron Howard movie about the Florenia affair, where a handful of European idealists go to a remote Galapagos island in the 1930s. What stayed with me was how quickly the philosophy falls away once people have to actually live together. Food, status, survival, resentment, all the basics come back. And I also finished Middle March, which was a project, 900 pages. The first half was a climb, but once the threads came together around gossip, debt, and reputation, I understood why people keep reading it. Both of these were a nice reminder that systems are always human underneath. Even when the topic is AI agents and access controls, the messy part is usually people, incentives, ownership, and trust. That's it for this week. The full issue with all links and sources is in your inbox or at quantabitsnewsletter.behive.com. I'm Reza Markabadi. Thanks for listening. See you next week.