Sponsored by: Capgemini | The Foundations for a Million Agents
Summary
- Managing a million AI agents at enterprise scale requires four independently scalable disciplines: Integration and Ecosystem governance, Development and Discovery, Business Management, and AI Resource Management — where IT functions as the HR department for the AI workforce.
- The AI Persona concept defines how the business delegates authority to an agent as a team member rather than a system, with standard operating procedures, defined permissions, and accountability structures comparable to those applied to human employees.
- Unity Catalog serves as the governance backbone for managing agents at scale, with a streaming Delta Lake architecture providing the data foundation that makes autonomous agent decisions reliable and auditable.
Sponsored by: Capgemini | The Foundations for a Million Agents

Every organization can build an agent — almost nobody is ready to manage a million of them. this video lays out what it actually takes, starting with AI Persona definition: how the business delegates to an agent as a team member, not a system. It then breaks apart four disciplines that must scale independently. Integration & Ecosystem spans MCP, Unity Catalog, and the governance of AI through MLflow, grounding agents in trusted data and policy. Development and Discovery use Genie and Databricks Marketplace to build and evolve agents. Business Management, through Mosaic AI and MLflow, drives accountability. AI Resource Management makes IT the HR function for the AI workforce. Underpinning it all is why a streaming Delta Lake architecture is central to an AI future. This is the architecture for a million agents.
Talk By: Srikrishna Srinivasan, Sr Director AI, T-Mobile (Primary) ; Steve Jones, Head of Agentic Transformation, I&D, Capgemini (Sponsor Speaker)
Chapters
00:00Introduction and the million-agent problem01:10Why agent management at scale is different from agent building02:39Four disciplines that must scale independently05:13AI Persona: delegating business authority to agents07:35Standard operating procedures for AI workforce governance10:33Business vs. solution risk: who owns what13:30Data quality requirements for operational AI decisions17:09Defining what agents can and cannot do21:20Linking data contexts across business units25:32Accountability and the independent judge model29:46AI Resource Management: IT as the agent HR function38:14Unity Catalog as the governance backbone for a million agents
FAQs
What is the million-agent problem and why is it different from building a single agent?
Building an individual agent is relatively straightforward with today's tools, but managing hundreds or thousands of agents across an enterprise introduces an entirely different class of governance, accountability, and coordination challenges. This video argues that the industry is focused on agent building while the harder and more important problem — managing agents at scale — is being neglected.
What is an AI Persona and how does it help govern agents?
An AI Persona is the formal delegation of business authority to an agent, treating it as a workforce member rather than a software system, with defined permissions, standard operating procedures, and accountability structures. This mirrors how organizations govern human employees, making it possible to manage a large agent workforce with clear roles and boundaries.
How does Unity Catalog function as the governance backbone for a million agents?
Unity Catalog provides the centralized governance layer through which agents access data, tools, and capabilities, with policies that enforce what each agent is permitted to do at the platform level. In this architecture, Unity Catalog is the mechanism by which IT acts as the HR function for the AI workforce, controlling access and ensuring that agent activity is auditable and compliant.
Why does a streaming Delta Lake architecture matter for agentic AI?
Agents making autonomous decisions need data that is current and accurate at the moment of action — stale batch data can lead to incorrect or harmful decisions. A streaming Delta Lake architecture ensures that agents have real-time context from operational data, which this video describes as the non-negotiable data foundation that makes agent autonomy reliable rather than dangerous.
Full transcript
[00:07] First of all, I have to give an apology to Sri Krishna, who was going to be my partner in crime today. Um, unfortunately, he wasn't able to uh make it down from the uh Pacific Northwest to present, so you're going to have to put up with just me. Um, so uh going through, got the first
[00:20] slides uh that we need to go through, which is the standard forward-looking statement which every presentation have to have, which means nothing I say is true apparently, and you can't rely on it at all to make any decisions. That hopefully isn't going to be quite true,
[00:33] but there we go. Um, if you've got some surveys, then you need to complete them, so that's all good. Um, I haven't put any up here, but what I'm going to talk about is something that been working with uh Sri Krishna, and then we really were thinking about what were did we
[00:45] want to present on. And what we thought about, and and certainly can't be here, is not let's go into the deep technology that we've done, but let's think about the problem of what are we doing when we have a million agents? What are we doing in the future when we have all of these
[00:58] things, and what is the impact of it? We're at the stage where we've got 100 agents, 200 agents, a few hundred agents. That's a problem of management, and that's really when we think about
[01:10] scaling, what we're all about, which is where does the world go I forgot I got a clicker, I can walk around a bit more, that's good. Um, where does the world go when the agents exist all over the place? When agents are just the default,
[01:24] when every system has agents. This is a world, remember, where Salesforce have said the application is irrelevant. That it's about the agents that interact with it. Now, they may still draw their
[01:36] picture and put data at the bottom, but there is no data. There is no agents without data at the top. There is no agent without the ability to make decisions to drive the applications. SAP
[01:48] have said they're so paranoid about the uh the packages, you have to use our agents to interact with our package cuz we know that the agents are going to be the workers of tomorrow, and we need to have those within our world. So, the
[02:00] question is, when we think about the foundation for million agents is, what does it mean to actually talk about all of these things? And what does it mean to not focus on? Now, I'm going to start with a controversial statement,
[02:12] which is Genie's great. The agentic harness stuff is great. But right now in this industry, there is a true literal trillion dollars being poured into helping everybody build
[02:26] agents and put them in production really, really fast. And burn credits and tokens really, really fast. That's the focus. Build, build, build an agent, build an agent. And here's the problem, is that is not the only problem that
[02:39] exists. It's great when you're building one or two, and I'll talk about use cases in a bit, but one or two things, but it's not good when you're actually thinking about how I've got lots of these pieces. If you focus just on the
[02:52] build, well, how does my business discover what I've got? How does the business manage what I've got? If you've ever tried to show a head of marketing an evaluation matrix for a an
[03:06] an an LLM, it's an entertaining conversation to try and tell explain to them why it hallucinated based on the mathematics of the implementation and what probabilistic models actually mean. They really don't care. They care about
[03:19] why the marketing went out and looked like absolute garbage and trash. That discovery and business management problem has nothing to do with build in the sense of you can build it and not do that. The investment in build doesn't
[03:31] make it easier for you to manage. The integration and ecosystem. We at Cap have a Salesforce system. Probably a lot of people in this com- in in this room, their companies have a Salesforce system. I will bet you a very
[03:45] nice bottle of red wine that your implementation looks nothing like ours. That means that from an integration perspective an ecosystem, that is specific to my company. It is specific to the way of working that I have. How I
[03:58] allow an agent to be able to integrate with my systems is not a generic problem. It is specific to my company. And underneath that, when you think about how you manage it and operate it, right now, what can best be described as
[04:11] the the prevailing wind from I'll say it some of the the larger package vendors is, if you build and the hyperscalers, if you build everything in our walled garden, you'll be able to manage it. If everything is in our walled garden,
[04:24] it'll be great. The thing is is that's always what everybody does at the start of these new technology generations is, if you build everything in our world, everything will be great. The problem is, just for a laugh, if you're ever bored
[04:36] on a Friday afternoon, and you deal with both SAP and Oracle and Salesforce, phone each one of them up and tell them that the other one is what you want to use for the walled garden. And say, "Listen, Oracle, as long as all of your
[04:49] stuff works inside SAP, we're great to use your tech." Just just listen to the pain at the end of that conversation, that phone line. Just amuse yourself a little bit on it. That challenge of AI resource management, of how you're going to
[05:01] manage this new generation of digital employees, is not a walled garden problem. So, the second thing to be aware of is when people talk about agents, they
[05:13] always go, "Well, we're going to have lots of agents." But, there are two very, very, very different problems with agents. There is one, the AI is infrastructure. How do I automate tasks? How do I move data around in my infrastructure?
[05:26] How do I do the plumbing of my business much more effectively? And I'll put in that some invoice processing, some of those sort of tasks. They're infrastructural tasks for AI. And then on top of that, you have the
[05:39] business delegating their authority to an AI to do a task, which is their career success is linked to. Those are not the same problem. If you build an AI that tries to do both of
[05:52] those, I guarantee it'll fail because you'll have the infrastructural piece being the CFO or the marketing officer not caring about the infrastructural piece, and you'll have the IT department not understanding the pieces going on from the business perspective. These two
[06:05] explosions of agents are not the same, and you cannot manage them and define them the same way. So, the next bit of that, the implication of all of that is that in
[06:18] order for these two worlds to exist, you need to be able to describe your business for AI. When they were talking about Genie and the ontology, and we can have discussions about hyper ontologies
[06:31] and all of those pieces, but it's the start of this problem of There was a myth last year that you just be able to buy an agent from all of these companies and roll it into your company and it would work. But, when an an employee joins your company, you have to tell
[06:44] them how you work. You onboard them. You tell them what the processes are. You describe the systems. You say what you can and cannot do. That is the description of your business for your employees. AI needs to be exactly the
[06:59] same or it's somebody else's AI. If you're relying on Marc Benioff or Sam Altman or Elon Musk to define how your business best works, good luck. Entertaining to watch. Tell me, I'll
[07:11] short the stock. It'll be good. That is not how a business will succeed. That is not how a CMO will succeed. If it's I don't understand how my AI works, I can't describe what our marketing vision is,
[07:23] uh but sure, let's hit the button. That is not a CMO that's going to be in that job for very long. So, if you don't have a way to describe your business for AI, and that's not just the data, that's the function, that's the processes,
[07:35] that's the standard operating procedures. It's all of the things AI needs to work in your company the way you want it to work. That's the fundamental. So, how do you solve that? Well, we
[07:48] think there's four things you really need to look at. First one is business management. Business needs to be able to run those business agents. They're going to be part of the business teams. The second one is the
[08:00] technical problem. The integration, the ecosystem. How do you turn those definitions into things that are there? The deployment and discovery. How do you actually manage the things that are deployed? How do you enable people to discover what can and cannot be done?
[08:14] And finally, the AI resource management. What is Oh. That disc guide disappeared for a second. Um the AI resource management. How do you manage all of these agents across all of these systems?
[08:26] So, let's start with business management. There are only three ways you could possibly govern AI, right? The first one is let's have the AI govern itself. I think this in in Silicon Valley can be
[08:38] described as the startup idea. Um that seems to be most of the startups I speak to is like, "Yeah, AI can do all of this itself. Excellent." Have you ever met a regulator? Have you ever met a business? Have you ever seen a company go bust? That's clearly absolutely
[08:51] insanity. The second one is, "Well, AI is going to be making half of the decisions in our business. The CIO now owns half of the decisions in the business." Another entertaining question is then to go to the CFO and say, "Good news. IT is going to sign off half of
[09:04] the procurement decisions in this company. IT is going to sign off half of the capital expenditure in this company. Marketing, great news. IT is now responsible for half of the marketing decisions that happen in this
[09:16] organization." Yeah, that is not going to happen. Which means there's only actually one governance model for that top piece of AI that's actually going to work. It's that the business needs to govern its AI, and it needs to govern it
[09:28] in that magic word. I believe it's a current in the city of San Francisco you have to use this word at least once in every presentation. It's own context. The business's context needs to be how they
[09:40] manage the AI. What does that mean? Well, that means we've got to think about something of what the business should be managing. And there are not Everybody talks about
[09:53] risk and agent control planes and all of these things. And what that forgets is that there are not one type of risk. When you talk about LLMs and you talk about hallucinations and you talk about burning tokens and FinOps and deeply,
[10:06] deeply technical systemic risks associated with AI, that's the same as when you think about in business the onboarding of an employee, the management and the mandatory training, the uh risk department within an
[10:20] organization. They manage the systemic risks of having employees and doing the job of business. Then you have the solution. So, once somebody's been hired, once the payroll, once the background checks have been done, then
[10:33] the business manages the solution risk of having an employee. It needs to be the same for AI. You don't want the business managing the systemic risk because that exists everywhere. You want
[10:46] the business managing the solution risk because that's specific to them. If you try and put those two fields of management together, it won't work. So, what do we think when we say starting with a business model for AI?
[10:59] This is when you think about your AI and why use cases and this is uh my partner in crime we we would we would have definitely done a a two-fer on this one is use cases are a terrible way to build
[11:11] AI. Because use cases span multiple areas of control. Working with another organization uh in the insurance space, the CDO one time found me giggling and said that he had 20 use cases with a combined
[11:24] value of over 20 billion dollars. I said, "Wow, that's phenomenal." What What is it? He said, "Yeah, the only problem is every one of the 20 has been created by our sales teams and involves us changing the way we do risk.
[11:36] Now, in an insurance company, there is one department that can change how you do risk, and it is not the sales team. Shocker. Right? But, the point was a use case goes through all of these areas. It says this is how we're going to sell to the customer. This is how we're going to
[11:49] provision it. This is how we want to manage risk. But, the reality is that the business is where those employees live. If you don't have the ability to define agents before you start the project in the context of the business
[12:01] and say, "This work actually is going to go through four different agents. This use case is the orchestration of four agents which live in three different areas of our business." That is how you need to build it. If you
[12:14] build it based on use cases, you will fail in governance and you won't be able to scale. You also, from a data perspective, when we think about data products and we think about all of these areas, there is
[12:26] a data supply chain which is not bronze, silver, gold. There is a data supply chain for agents which starts from the idea that the sales team, I'm going to pick on sales teams a lot, uh sales team created an
[12:39] order with an incorrect address. The people who had the problem with that were in the supply chain and distribution area. The finance team had a problem because the sales team created the customer name wrong. The marketing team had a problem
[12:53] because it was a completely incorrect segmentation. The problem with the supply chain is at the source, which was the the sales team. That is different to when we think about data products in terms of bronze, silver, and gold within the lake. This
[13:06] is what is the business model of data that AI relies upon to be accurate, and where is the accountability for that accuracy? Data quality exists because it wasn't
[13:18] accurate in the first place. And the thing you should be thinking about with Salesforce and SAP and what they're and Dynamics and what they're all saying about AI is they're saying that agents are going to make decisions based on their systems.
[13:30] Hands up in this room, anybody who thinks that transactional applications have the peak data quality in their organization? Well, that's a safe bet, wasn't it? Right. No, because they've never cared
[13:43] before. They've never cared about data quality because in the data world, we cleaned it up after the fact. We recognized the fact that it was wrong and we went through all the work. If you don't understand what your data supply chain is, you can't find out how to make
[13:57] it accurate so decisions can be relied upon. This is the business model of data in order to make AI scale. So, once we understand we've got a vision of our business model for data,
[14:10] how do we start describing it? Well, that's where you need to start thinking about click the idea of where business and for AI lives. When you think about how Salesforce have
[14:23] described the future of agent force, it lives above Salesforce. That means there is a piece between Salesforce and the agents that describe how your business works in that Salesforce environment. They don't put
[14:36] that picture that in the picture, but it has to exist for those agents to follow your sales process, for those agents to work for your sales leaders. It has to be there so that it follows the processes and practices that you want in
[14:49] your organization. Then there's the technical systems and function. Yes, the applications are part of technical systems and function. They are the commodity in this AI world, but they're only a commodity if they can be
[15:02] described so an agent can understand them. The next generation, the current generation of thinking agents are very, very good if you give them very specific understanding and descriptions of tasks, of standard operating procedures, of
[15:15] data. You saw the Genie demo today. If that description, that ontology, functional as well as data is accurate, agents are very, very good. If that description is inaccurate or non-existent, they are entertaining and
[15:29] will hallucinate and will confidently do very bad things. Give you a little story from uh um something we worked on. We didn't put it in production, but it was a good example of in testing something we found, which was we had agents trying to close tickets. I'm sure everybody's
[15:42] tried to do that sort of piece. The closing ticket agent was gold on reducing the number of open tickets. When it tried to fix the tickets and couldn't, it had access to the MCP server from ServiceNow, which includes a
[15:54] delete function. So, it deleted the tickets, resulting in a reduction of the number of open tickets. Goal achieved. For pointers, that's an SOP. An SOP should only say the functions that should happen. Should only say the tasks
[16:07] that need to be done. Should only say the processes that are allowed. That description is a data problem. It is not a functional problem. It is a data problem to describe so AI can understand
[16:20] the functions and data of an organization within a specific context. So, how does that work? Well, the first thing is I need to understand the business context. Speaking to somebody earlier who works
[16:33] at the consumer products company, they separate customers from consumers because customers for them are people like Walmart. Well, at Walmart, customers are people like you and I who go into a Walmart and buy stuff.
[16:45] One word. Can you have a context therefore that uses the word customer between Walmart and a CPG company? No. I need it to be contextually specific. Sales teams and finance teams hate each
[16:57] other because they're meant to. They have a different context on what their world is. The business context is domain specific. You need process descriptions, standard operating procedures that say
[17:09] what can be done, what cannot be done, and they need to be done in a way which is understandable to AI, and it needs to include the negatives as well as the positives. This is what you can't do as
[17:21] well as what you can do. The systems manuals you have that describe what a system does, how you log on, all of those pieces, they need to be turned into things an AI can understand. And obviously, really importantly, the data products.
[17:34] Going to big up Genie again. That's what the ontology stuff in Genie is about, describing data products, but it's only one of four problems. And then underneath that, you've got to have the ability that for a specific task,
[17:46] which of these things applies to that task? You do not tell an agent, "Right, here is every single system I have in my company, every single operating procedure, have at it, let's see where
[17:58] we go." You need to be able to say, "For this task, for this problem, you're allowed to see this data, this function, and you're going to work under these operating procedures. It is limited to that task." That means the assignment of
[18:11] it is dynamic to a task and dynamic to a purpose. That's one of the pieces when you think of unique catalog and setting it up and setting the structure of it. And the third piece is that governance has to be done for security and policy.
[18:25] If there's a bugbear that might I'm sure Christian would have sort of talked about is there is right now no decent security policy for AI delegation. Um hopefully there will be soon, but all AIs either work in system accounts or
[18:37] based on magic token sharing. It's not the best thing in the world when we're looking at security. So, development and discovery. How do we actually move these things forwards? Well, when we think about data products, I'm
[18:50] going to speak speak on data products, is data products, we all use the phrase data products is data product data product. There isn't just one. And we think there's five when we think to the future. The first one is the one that
[19:02] lake base is set up to do and SAP and Salesforce want to do, which is operational speed data products. Most organizations today think data products only live in their lake. Only live in
[19:14] the post-transactional world. But if AI is going to make decisions operationally, then you have to have AI relying on operational data products.
[19:26] You have to understand the governance that needs to go around data products that work at operational speed. You've then got the post-transactional data products. We think of those as the collaborative products. And where's my
[19:38] partner in crime gone around around now? She's moved. Um around understanding that if you try and do an entire enterprise data model, as we tried to do at one company, you find out that there's far too many attributes on it. So, you end up with a much smaller data
[19:51] product, which is focused on what is actually the collaborative set of data associated with Oh, there she is. Um with that subset of data. That's how you need to think about it. Is the collaborative piece is what do I
[20:04] need to know between business areas? They don't need to know every meeting that happened with the client from sales. They don't need to know the intent. They don't need to know these They just need to know the fact that this is the current information that feeds into the demand forecast. That's
[20:17] the subset of information that needs to be properly governed. Then you've got what data lakes are fantastic at, the historical pieces. If anybody hasn't seen Weather Next from Google or GraphCast, um
[20:29] it's an amazing amazing uh research project that's now like a commercial product. But they took 40 years of weather data and they simulated weather for planet Earth. Not physics, simulated it using AI.
[20:42] People thought that could not be done. And now the idea of using historical data to simulate and effectively do Monte Carlo simulations on steroids for everything you do in a business is going to be normal. Historical data
[20:55] products are going to be the foundations of that. Managed data products, the master data. It's not about golden records in this world. It's about having the ability to navigate between all of the different
[21:07] data sets that exist in an organization. Manage data is so you can navigate from sales to finance. It's not saying there's only one way to describe a customer because finance have a
[21:20] different view of describing a customer to sales and they're both right in their contexts. But if I can link the customers, I deliver 80 90% of the value even if I get their name wrong.
[21:32] And as somebody who like moved to the US and and uh the US government managed to get my name wrong on my social security the first time round, I will say them knowing me was definitely more important than the fact that they called me used
[21:45] my first name three times in my name. So I was Steve Steve Steve Jones. Um which was an interesting uh problem I had to uh fix to prove that I wasn't Steve Steve Steve Jones. Um so I had to send my passport in to prove it. But the
[21:57] point is the references existed, the core data was wrong, the references are what matter. And then finally for AI, the magic word again, contextual. How do I provision data products
[22:09] specific to business problems? That mechanism of provision, you saw it today with uh Genie when they talked about how they you can record some of the Genie space agents and have those pieces. At
[22:21] that stage, there's a very clear subset of data that is working against agents. So, what does that actually mean from a pieces? That's a really important point in an AI world which is
[22:33] information is contextual. When you think about people say, "Oh, customer data." And we build a customer data hub. We put all of our data in our customer data hub. Do not give an AI
[22:45] unvarnished access to your entire customer data hub. If it's working in finance, it needs different information and a different context. It might be chasing them up for a bill. It might be chasing an invoice. It might be asking
[22:58] them for payment. It needs to know certain things related to that problem. If it's working in supply chain, it needs to know where they are and what the deliveries are. That's what it needs to know. If it's working in customer, it needs to know sales, propensity to buy,
[23:10] all of those pieces. Those are three different contexts for the same customer. And AI is not going to run across You don't have one AI that does all of these things. There is no
[23:22] super god AI that lives in the sky that you ingest your entire data warehouse and it magically does all of these things. That doesn't work. Context is specific to the problem. And the second reason context is specific is each one
[23:35] of those four have a different boss, have a different manager. So, if you're asking one thing to do all of that, that means you have to have a meeting where you get the CFO, the head of supply chain,
[23:47] and the um head of customer sales all agreeing that they're going to work in the same way. And they never ever will. Because they'll just annoy do it to
[23:59] annoy each other. You have to recognize the governance they have for them to be able to manage it. Right. In the history of what we have talked about when we think about data products and we think about data within our
[24:11] world, we've always thought about doing source to target. We go source to target because we are the passenger to the applications. That's what we've always been. We have the applications, they're a fact of life. We now have to
[24:23] work out how we make something sensible out of the data we get from the applications and all of those pieces and data cleansing we do. For AI, we have to start thinking about target to source.
[24:36] And AI is a user of these applications. You are talking as much about doing screen design uh for an application as you are talking about doing data design. You are trying to build something that
[24:49] an AI will understand the target. One of the pieces that when you then start using AI in terms of doing the mapping, well, what are things that AIs are normally good at? Ontological translations, generation of code,
[25:03] understanding mappings between different data products. AI, once it's got the target, can do a very, very good job of accelerating your ability to create the source. But the target, the contextual data products, how the business needs to understand it, is the thing you need to
[25:17] own and define, because that's the world the AI has to live in. You're now defining for a different customer base. You're not just defining for reporting.
[25:32] So, onto the the the final bit. Um which means, if I've understood what I've got, which I said, my business now has aligned to the way of working in the business, every single team has multiple agents working for every employee doing
[25:44] multiple tasks in very clear domains, so I can properly govern them and manage them. They have the solution risk associated in a way that means the business can now manage each of those agents. They can work and manage those
[25:57] business agents, because I've described them in a business way. Now, we come to the problem on the IT side of the fence, which is great, but this means every single one of those agents is making calls that are flowing
[26:11] across our network and making decisions that all need to be audited, all need to be traced, all need to be tracked, all need to be validated. How on earth do we do that? So, this is the final bit that when you think about
[26:23] what you should be thinking about strategically as you look at rolling out um data bricks closet size is the big problem we're going to have, and I've already seen this happen, is if I've got agents from four different
[26:35] vendors and they're calling each other and something goes wrong, none of them stand up and go, "Oh, how bad." They all go, "Ah, I don't know what went wrong there. It must have been somebody who called me. It was the information we
[26:47] got that was bad." Which thread caused that piece? Well, we don't know which thread. We don't know which instance on SAP called the instance on Salesforce. So, they all pointed each other. If you can't define
[27:00] the threads, they're all just going to point at the error and say, "That wasn't us that caused it." There needs to be accountability within AI. And that needs to understand
[27:13] where accountability rests. And to take a uh three-part of government type piece, that means there needs to be an independent judge. One of the pieces that, you know, we're
[27:26] looking working with Databricks on is exactly that. Who's the independent judge? Because there are some very big companies out there who would love to be the independent judge. But, there's a reason why Splunk and Datadog exist in data
[27:41] monitoring. It isn't because SAP, Oracle, all those companies couldn't do it. It's that they can't do it between everybody. You need somebody who sits in the world between all of those pieces. That
[27:54] company needs to do a few things. One is, it needs to be able to record every single interaction between every single agent and be able to understand the context at that point in time. Which means, it's a large data problem.
[28:08] I don't want to say big data cuz that's out of fashion there. But, it's a large data problem to be able to track all of these interactions. You need something that can run actively agents to profile across all of those things to see
[28:20] whether or not a call being made should allowed to be made. In other words, yes, this agent sometimes can call that system, but in this context, it should not. This agent can make a request to
[28:33] this other agent, but in that case, it definitely sent an envelope which was incorrect. That judge, that cross-agent audit, and how you understand the threads between agents is something
[28:45] we're already seeing a problem with. which is agent A calls agent B calls agent C and something goes wrong. If you can't say which specific context in each one of the agents, which prompts, which
[28:57] inputs, which outputs led to the issue, the debugging hell is like nothing you've ever seen. Because debugging a probabilistic system where you have three probabilistic
[29:10] systems is super fun when you have no debug logs that enable to lick them to to link that stuff up. If you don't today start thinking about how you build out an infrastructure to manage that
[29:22] information, to make sure it is recorded, so when something goes wrong, you can understand was that just a random hallucination, or is this something that when that threat type of threat happens over and over again,
[29:34] it always goes wrong. If you don't have the ability to track threads, you cannot govern agents at that scale. So, in terms of what this means for AI and
[29:46] resource management, think of your HR department. How does HR make sure that you people you may you hire, except in sales, aren't psych- pass or sociopaths? Well, the first thing they need to do is to say
[29:58] recruitment and onboarding. What are we allowed to recruit into our company? Every single company out there right now is going, you we can sell you tens, hundreds, thousands of agents. Just buy them from us and roll them in.
[30:12] That would be insanity. So, you need to think about what your recruitment pipeline is to say, right, this is what these companies have, this is what we're going to validate, this is how we're going to judge the value of those pieces. I then need to onboard it into
[30:24] my organization. I need to do things like red teaming. Red teaming is the penetration testing equivalent for agents. It's the way you validate that an agent, when it goes wrong, how it goes wrong, how easily it is to make it
[30:36] go wrong. Red teaming is not something your marketing team should be doing. It is not something that your supply chain team should be doing. It is something that should be done consistently like penetration testing in cyber across all of your company. That
[30:49] is part of the onboarding process that has to happen. Then operational management. The LLMs, let's take a theoretical example. You've got an LLM that you're relying upon on a bunch of different agents and then I don't know, randomly
[31:02] somebody bans you from using it. So it's no longer available. Clearly, that could never happen this week. Um but if that happens, what's your operational management to make sure that those agents still succeed? What's your BCP, your business
[31:15] continuity planning for when a model fails to happen? What's your operational management for looking at these agents and making sure that they're operating within boundaries? That's a systemic risk problem to monitor all of these
[31:28] things. Life cycle and performance management. How are they business saying and how are they able to change the KPIs and the measures and all those pieces? But also more importantly than that, how are you making sure you're not overpaying for the LLM you're using? Um
[31:43] we had a an example at a a an organization where we were building some pieces for the legal team and we were using the full fat model um to build out those pieces and it was a cost
[31:56] a lot of money for the year. And then the team, because we defined it well, we described it well, we had a very clear boundary around it, ran a really, really small model and instead of being able to buy a Ferrari, the sales person might
[32:09] have been able to buy himself a new insole for his shoes. Same understanding of the outcomes and evaluations. That performance management becomes incredibly important at the pace of
[32:21] change the models happen. You need constant to be looking at, will this agent still succeed if I move it to a cheaper model? Will it succeed better if I move it to a more expensive model? How will I be able to manage all of that?
[32:33] The answer is you can only do that at the system and infrastructure level. You can only do that if you're recording all of those inputs and outputs so you can run evaluations against alternative models, which means you need a platform
[32:45] in which all of those things are able to exist from a data perspective. And that brings us on to the magic, which is cost management. If you can do all of those things, you can then actually optimize the cost. We've all heard the horror stories of people who've rolled out
[32:57] cloud code and then I genuinely don't know how people spent quite that much, but you know, we use it incredibly extensively and it's impressive. Although we did have somebody who uploaded a binary Excel multiple times
[33:10] and did manage to burn $100 before we managed to stop them. When they asked, "Why isn't this working?" And the answer is, "Because you're putting a binary in and it doesn't do anything with it." But it did cost $100 of processing to do that piece of
[33:23] work. So, if you can spot those pieces in the cost management, understand what goes in and out, understand the model optimization, understand how cascades work, those are deeply technical problems that apply to all agents on every platform.
[33:36] And they're based on the data that the agent generates when it is running. You need to have a centralization of that so it can be monitored, so it can be managed, and so it can be improved. It's like having an HR department for your
[33:50] agents. You wouldn't have an HR department for every single business area that had separate payroll, that's had separate training, had separate risk management, had separate contracts, used
[34:02] a separate vacation system, a separate time reporting system. You wouldn't do that. And yet right now, we see people trying to do exactly that with agents, which is every set of agents is
[34:14] completely separate. Every set of agents works completely differently. There is no traceability across all of it. That would be exactly like doing it with employees and saying, "No, everybody gets their own HR and everything gets run on
[34:27] separate contracts." It just isn't possible to manage systemic risk if you do it that way. So, coming down and wrapping it up with 5 minutes to go,
[34:40] um the first thing on that I've talked about is onboard things before you trust them. If you don't have a process that says how you certify its comprehension, how you certify it works, how a vendor proves or
[34:53] internal team proves it understands it, you should not be doing it. Then, it's active. If you don't have a step that proves that an agent can succeed, then you shouldn't be rolling it in. The
[35:05] phrase "it looks like it works" is an absolute common phrase with AI agents because LLMs are needy, optimistic, and love to give you an
[35:17] answer. So, it looks like it works. If you can't prove comprehension, if you can't prove it actually worked, you shouldn't be putting it into production. Uh side note, we did find out some
[35:29] agents that uh some business folks built at one company, um about 10% of them weren't even connected to the data sources they thought they were connected to, and they gave a very high confidence score that the data coming out of it was incredibly good. So, explain to people
[35:42] that no, it literally is just hallucinating all the figures you gave it, um they it took a while to convince them. So, nothing an agent does should be unattributable. This should go without saying. Every single action, every single step should be attributed
[35:54] to the specific engagement of a person, an agent, an agent thread, an agent chain, what we like to call ABCR&R, which is now audit balance control, reconciliation, and non-repudiation.
[36:08] If you can't do that across all of the agents, you're not going to be able to trace all of those things around. That means from in the these the set from a Databricks perspective, if you don't have the ML flow traces driving into with the Unity Catalog to get the
[36:20] visible, that means you don't have durable evidence of these things. You need to be able to establish all that end-to-end. Where to start? Well, the first thing to start with is
[36:32] the business. The thing underneath the line of automating what you do in in IT, I have to say I think we pretty got it. We We We've got that one. We're IT people, we know what to do, we know how to build those pieces. That's our
[36:45] responsibility. But, on the business side, if the business isn't being clear on what the boundaries are, the question I always ask on the business side isn't what do you want AI to do, it's how do you want to delegate the work to AI?
[36:58] Because that's actually the problem they have That's the question they have a problem with. Not what they want it to do, but how are they going to delegate that work so an AI can succeed on it. That's the problem they go around it. Number two, shape the catalog. If your
[37:10] Unity Catalog aligns with your business architecture, your agents will be aligned to where your business works, your data products will be aligned to your business works, your Unity Catalog be should be a reflection of how your business works.
[37:22] And industrialized platform, there is absolutely zero reason whatsoever that data ingestion, data transformation, data provisioning have any nuance in any platform anywhere in any organization. We've known what good looks like
[37:35] for over a decade now. It should be done in a standard consistent way. So, what does it mean to have the platform for a million agents? Well,
[37:47] is we're going to have things when we think about Databricks, you got to think about lake base. That's where the operational agents live. It's the provisioning of data into lake base using Delta Sync to enable agents to work at operational speeds. I have my
[38:00] Delta Lake and Genie doing my collaborative and contextual with people engaging with it and working with all those pieces. My historical, I've got Mosaic AI doing my simulations on my archives to create my new ways of working on my models on top. The managed
[38:14] is where Unity Catalog really kicks in. It's not just the management to be able to say these are the cross references, these are where these pieces live. It's also the fact that management of the catalog and its structure. And what we think in terms of how you build it is you should be thinking about these data
[38:27] products of think beyond Genie. Think about how they can be autonomous in the way you build and operate them. How a data product is something that runs as an AI all the time. From a governance
[38:39] perspective, make sure you've got a gateway. If you don't have a gateway, you should have a gateway. Um MLflow too, obviously the asset bundle of streaming phones, and all of this, the thing that wins from a
[38:51] Databricks perspective is there is another company here in San Francisco that says that the future of all of this is zero copy. Well, the laws of physics called. Zero copy will always lose out to the laws of physics because the laws of
[39:04] physics are unbeaten since the start of the the first picosecond of the universe. The speed of light is a thing. Latency is a thing. If you have data that is inefficiently
[39:16] defined, good luck trying to do efficient actions on inefficient data. The laws of physics are what beat you. This isn't about one data modeling approach to another. It's about the laws of physics against not fighting the laws
[39:29] of physics. So, all of those foundations when we think about it, I'm just wrapping up and summing it as in here, is AI is now a business user. A business user. It is not just a technology. There are two
[39:42] worlds. There is what we're using AI for to automate what we work, and there's AI as a business user. That business user needs the business described so AI can understand it. AI underneath is AI for
[39:54] infrastructure. We're going to get that. We're going to do that. There's going to be a lot of money spent on that. The business management, the integration ecosystem, deployment development and discovery, and the AI resource management, and that's where we think all of that gets powered by
[40:06] Databricks. So, the thing you should be thinking about as we finish this as I finish this presentation is there will be a million agents, but there will only be one business, and that's yours.
[40:18] If you get a million agents that don't know how your business works, a million agents that don't understand what you want to do in your business, you have no business. Because the competitive advantage of the
[40:31] future is based on your ability to make AI work for you. A million agents, great. But one business. Your problem is not build, it's the definition, it's the
[40:43] governance, it's the management to make those agents work for you. Not believing that Sam Altman, Elon Musk, Mark Benioff, and any other startup out there understands actually
[40:57] how your business works. That's it. >>
Learn more about the Databricks Data and AI platform.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.