Stop Sending Employees to IT. Send Service to Them.
Episode Summary
IT service management was built around a constraint: a small IT team cannot serve ten thousand employees, so the employees are told to come to IT. Lenin Gali, chief business officer and a founding team member at Atomicwork, argues that agents remove the constraint and the whole model should invert. Instead of an employee leaving what they were doing to open a ticket in a portal and wait, the service arrives where they already are, in Slack or Teams, and answers in seconds. His framing is that the employee is the recipient of the service, so the employee should be the focal point, not the process that brings them to the queue. That reframe drags the measurement with it. Mean time to resolution stops being the number that matters once resolution is real time, and deflection, quality and productivity returned take its place. The back half of the conversation is about what has to be true before any of it is safe: trust, security, governance and compliance as four separate tests, an identity for every agent, and a support hierarchy for agents that mirrors the human one rather than a single agent doing everything.
Key takeaways
Invert the service model. The old design tells employees to come to a centralized portal because IT is small. Agents remove that constraint, so the service should travel to the employee in Slack, Teams, email or whatever application they are already in
Real-time response changes the unit of measurement. Ask a question in Teams and an agent answers immediately, which moves resolution from hours or days to seconds
Ticket deflection replaces ticket volume. Once agents open and close tickets behind the scenes, counting tickets measures nothing. The measures that survive are whether the employee got the outcome, the quality of the fix, and whether it created a new problem
ROI needs a baseline before it needs a story. Nobody gets ROI by asserting that AI works magically. Record what a thing costs and how long it takes today, then measure against that
Four separate tests for an AI vendor, not one: trust, meaning transparency and logs; security; governance, meaning guardrails and an off switch; and compliance
Give agents the same support hierarchy people have. A level one agent triages and resolves, then hands off to a Salesforce, SAP or Workday agent. One super agent doing everything is a single point of failure
Every agent needs an identity. Identity governance is already the foundation for granting a person access to an application, and an agent is the workforce equivalent. A hundred agents running with nobody able to say which one did what is the failure mode
About Guest1
Guest Linkedin Profile is VP of AI and Data at Envorso and a founder of the AI GovOps Foundation, a nonprofit practitioner community advancing AI Governance as Code. He spent 25 years at Microsoft and then led a Ford subsidiary serving 20 million connected vehicles, with senior roles spanning AI, data, cloud platform, telematics, and digital transformation. His book The Lean AI Handbook is due from Pearson in summer 2026. He is known for helping enterprises embed governance controls into AI systems through engineering rigor, automation, and operational feedback loops rather than policy documents alone.
In this episode
| 00:00 | Welcome and guest introductions |
| 01:45 | Ken: GDPR, privacy, and the road to AI governance |
| 03:32 | Bob: when the models changed and the controls did not fire |
| 04:50 | What governance as code actually looks like |
| 05:54 | Where the policy code lives |
| 07:06 | Why gates also have to run at runtime |
| 08:21 | Will the CI/CD vendors build this? |
| 09:20 | Why the tooling is open source |
| 11:07 | Agent swarms, or viruses with credit cards |
| 11:52 | Ford: the puddle that flipped the car |
| 14:10 | GM: governance treated as a safety system |
| 15:14 | Over-the-air updates and automated targeting |
| 16:07 | Governance After Hours in San Francisco |
| 16:42 | The biggest misconception: governance as a brake |
| 17:34 | Unsafe at any speed |
| 18:00 | How much testing is enough |
| 18:24 | Red teaming and adversarial testing |
| 19:14 | The security analogy: shift left |
| 19:53 | Getting past the maybe gate |
| 20:33 | How many models do you test against |
| 21:05 | Inside Beacon |
| 22:19 | Umbrella, Lantern, and the audit layer |
| 23:14 | The Lean AI Handbook and the learning loop |
| 24:47 | Blast radius control and rollbacks |
| 25:27 | Data as the new oil, refined |
| 26:54 | Bob on where to start |
| 28:23 | Ken on his free e-book |
| 29:26 | Executive clarity and prototype theater |
| 30:33 | The one thing to remember |
| 31:26 | Wrap-up |
In Lenin’s words
“The inconvenience for employees is I am running for service rather than the service coming to me.”
— Lenin Gali (06:46)
“Literally, you ask a question in Teams or Slack, now you’re not waiting because the agent is really immediately responding.”
— Lenin Gali (17:43)
“It’s not about volume of tickets. It’s about the outcome. Is the employee happy? Are they getting the service done? Is the quality of service correct?”
— Lenin Gali (19:37)
“You’re not gonna get an ROI unless you justify in steps. You can’t just say you just use AI and it’ll work magically.”
— Lenin Gali (22:18)
“There is no one way to solve any one problem. With AI, you’re actually getting that super intelligence capability.”
— Lenin Gali (42:34)
“You can’t have 100 agents running wild and nobody knows what they’re doing.”
— Lenin Gali (36:23)
“They need to also have a piloting system that knows, like a command and control, like air traffic control, just like that.”
— Lenin Gali (37:45)
Resources
Lenin Gali and Atomicwork
Lenin Gali on LinkedIn: linkedin.com/in/leningali
Atomicwork: atomicwork.com. Agentic service management, delivering IT support inside Slack and Teams rather than through a ticket portal
Ideas and frameworks discussed
Employee service management: His reframe of IT service management. The employee is the recipient of the service, so the employee is the focal point and the service travels to them
Ticket deflection: The metric that replaces ticket volume once agents resolve and close issues without a human. Paired with quality of resolution and productivity time returned
Trust, security, governance, compliance: The four separate tests he says an enterprise AI vendor has to pass. Trust is transparency and logs, governance is guardrails and an off switch, compliance is the standards and procedures
Level one, two and three agents: Agents arranged in the same escalation hierarchy as human support, triaging first and handing off to a system-specific agent, rather than one super agent doing everything
Agent identity and IGA: Identity governance and administration as the foundation. Every agent gets an identity so that any action can be traced to the agent that took it
Air traffic control for agents: His image for an agent control system: a registry where a deployed agent has a role and an entry, so nobody is running agents nobody can account for
Named on air
Global CIO Circle: The CIO community he runs, which he describes as moving what one CIO has actually deployed into the hands of the others
NANDA, MIT: The open source project defining standards and protocols for the agentic internet, led by Ramesh Raskar. He was present when it was introduced at an MIT innovation forum
MCP and A2A: The agent registration approaches he names when describing how an agent gets tracked once deployed
Okta: His example of the single sign-on layer that already governs who gets access to an application and for how long
Related AI Realized episodes and events
From Firefighting to Fire Prevention in IT Operations: Karthik SJ on the same operational surface from the observability side, where the equivalent move is getting ahead of the alert rather than working the queue.
Your AI Agent Is Not the Risk. Its Authority Is.: Yogita Parulekar on delegated authority, which is the governance layer above giving every agent an identity.
AI Governance as Code: From PDF Policies to Pipelines: Ken Johnston and Bob Rapp on guardrails that run rather than guardrails that are written down.
Frequently Asked Questions
-
Agentic service management is IT support delivered by AI agents inside the tools employees already use, rather than through a ticket queue they have to visit. An employee asks a question in Slack or Teams and an agent responds immediately, acting as a personal concierge rather than a form that enters a backlog. Lenin Gali of Atomicwork frames it as an inversion of the old model: instead of a small IT team inviting thousands of employees to come to a centralized portal, the service travels to wherever the employee already is.
-
Ticket portals exist because IT teams are small and the queue is how they ration attention across thousands of employees. Lenin Gali of Atomicwork is explicit that nobody involved is acting badly, and that both the person asking and the person supporting are trying. The constraint is that a one-line message gives a support engineer almost nothing to work with, so diagnosis is where the delay lives, and the automation to close that gap did not previously exist.
-
Deflection, resolution quality and productivity time returned replace mean time to resolution once resolution becomes real time. Counting tickets stops being informative when agents open and close them behind the scenes, so the questions worth asking are whether the employee actually got the outcome, whether the fix was correct, and whether it created a new problem. Lenin Gali of Atomicwork puts ticket deflection first among these, with productivity gains measured against what the same work cost before.
-
Set a baseline first and measure against it in steps. Lenin Gali of Atomicwork is blunt that nobody gets ROI by claiming AI works magically: record what a task costs and how long it takes today, then measure the same task afterward and report the difference. Once the baseline holds up, the conversation moves from savings to outcomes, which for any organization resolve to two things, spending less and generating more.
-
Four separate things: trust, security, governance and compliance. Trust means transparency, logs and a system that reports its own failures. Security means the new component does not open the organization up. Governance means guardrails, levers and the ability to switch it off. Compliance means the standards and procedures the organization is already held to. Lenin Gali of Atomicwork treats these as four tests rather than one, and says a company selling AI to the enterprise has to satisfy all of them.
-
Yes, every agent should have its own identity, on the same logic that every person granted access to an application has one. Identity governance already controls who reaches which application and for how long, and an agent is the workforce equivalent of a person doing that work. Lenin Gali of Atomicwork argues the identity has to be tracked so any action can be traced back to the agent that took it, because a hundred agents running with nobody able to say which one did what is the failure mode.
-
Arrange them in the same escalation hierarchy that human support already uses. A level one agent triages the request and resolves what it can, then hands off to an agent that specializes in a particular system, such as Salesforce, SAP or Workday, which goes in and returns an answer. Lenin Gali of Atomicwork warns against the alternative, a single agent expected to do everything, because nobody can define where its limits are and it becomes a single point of failure.
-
Mostly the model, infrastructure and cloud providers, which is the problem. Google, OpenAI, Anthropic and AWS are all working on it because they hit the same issue internally, and Lenin Gali of Atomicwork expects a set of competing agent registries rather than one. Christina Ellwood presses on whether an academic or standards body is involved, and points to NANDA, the open source project out of MIT led by Ramesh Raskar, which is defining standards and protocols for the agentic internet. The risk both name is siloed agent ecosystems that leave enterprises paying for three agent management systems.
-
[00:42] Christina Ellwood: Welcome to AI Realized, the podcast for enterprise executives leading AI deployments. From tackling security data and operational challenges to navigating organizational transformation, AI deployment offers a unique opportunity to redesign our organizations from the inside out. I'm Christina Ellwood, your host for today's episode, and we're talking today with Lenin Gali, the chief business officer and founding team member at Atomicwork. Lenin, welcome to the show.
[01:12] Lenin Gali: Thank you, Christina. I really appreciate the opportunity to be here.
[01:16] Christina Ellwood: I am, I'm thrilled to have you as I actually originally met you in your, during your work with the Global CIO Circle. So maybe we'll have a chance to talk about that very interesting and impressive group a little bit later in the show. But for the top of the show, let's talk about AI and how it's evolving and how your work at Atomicwork is helping enterprises with agentic systems as opposed to individuals using AI or using AI as a component, using agents as a system for getting work done.
[01:53] Lenin Gali: Yeah. A great question. And AI is evolving. Obviously, those who are experiencing and experimenting and learning would agree. The other thing about many people is that, "Hey, I think it's just a hype, and I would probably wait until the hype cycle is over before I enter." The problem with, uh, the attitude towards keeping AI outside of current organizations' learning ability is that it is learning, and it is an experimentation phase where it will strengthen the culture, it will strengthen the maturity, it strengthens the processes, it strengthens the quality of data and skills that are needed. And if you don't build that DNA of adapting a new memory, a new capability that is intelligent and assisting in what we do today in humanly and human capacity to adding a machine capacity on top, is something that you have to really bring in with a methodical approach, rather than just simply dropping it and expecting it to work, and magically. Because AI requires data, AI requires people in capacity, ability, and skills, and, and also a new way of thinking. And unfortunately, that is not going to come by waiting, and it needs to come by doing. And in, in, in the case of what I'm observing, in the case of what we're doing with agentic service management, is an evolution of AI over the past two, three years, and then we're part of that journey, and we're still evolving. And we see that today we're assisting humans in getting the work done. Tomorrow we might be actually taking over some parts of the work by AI agents themselves doing autonomously. So I think to a point of evolution is still coming.
[03:38] Christina Ellwood: Yeah. This augmentive versus automation is a really hot topic right now, and a lot of enterprise executives are grappling with the w-when to do one versus the other, or how to recognize the opportunity to move from augmentation to automation might be another way to think about that. I agree with you that it's very much a cultural change. It's a way of thinking. It's a different operational modality. What do you think is the most critical change in the way we design our cultures to accommodate this new mode? Is it related to the way we organize ourselves, or is it more related to the way we design the way we work together? Is it about our systems or is it about our organization, or is it both?
[04:34] Lenin Gali: Yeah. So for AI to work, obviously people are the most important thing because ultimately we decide whether AI's value or AI's place in the organization and how you see that is going to help the employees or its customers, and if it is an organization. So because of that, we need to make sure first people are ready. And once the people mindset and adaptability is in lined with a strategic value creation within the organization, I think then introducing it in places where there is a lot more patience for it failing is important because obviously AI is still in, in a maturity state, and that means you would have to do some work for it to really make an impact. And so because both sides are learning how to use it, and the other side is basically expecting certain ways of leveraging what it's capable of.
[05:31] Christina Ellwood: So- So human in the loop.
[05:33] Lenin Gali: Human in the loop is going to be very much involved. I don't think it's ever going to be that there is no human supervision while AI is doing. There may be an autonomous way of work done, but the work is still going to be somewhat monitored and observed or maybe even approved by a human eventually. I think that part will continue for a while, and then there will be use cases where the work's done by agents, but still, as long as the work is done according to whatever human approval process is set, workflows or whatnot is being created already and approved by humans, then there is no involvement of a human required. All it is, there is an auditability and traceability and governance components are built into so that things fail for any reason, because obviously every machine is bound to fail at one way or the other. That happens, you have a way to lift up and then basically go and figure out and what needs to be done.
[06:25] Christina Ellwood: Where do you feel the change management will happen to those processes that are being automated? Our businesses evolve all the time, so if we have a way we do it today, two years from now, we may not want it to be done that way, and we need to make a change in this automation we've done. So how do you envision the change management happening for the agentic systems?
[06:46] Lenin Gali: Yeah. It's a wonderful question. I love it because for-- Sometimes you just, you need to pause and then look and then understand the history of how- We've come full circle to be adopting AI, right? So the adaptability and taking risks is definitely something that we have all been doing for the last two decades of evolving through technology, redefining the business processes, and innovation happens in various different pockets. And as organizations that are actually able to do that and able to make that leap towards me- adjusting themselves for the agility that is required in order to do this adoption are all thriving, and those that are not able to are basically failing. And it's not because they cannot change, it's just that sometimes the people and the processes and then the tech burden or tech debt is so much so that they're unable to really prioritize. They're unable to really let go of the debt weight that they're carrying. And I think the change management in this case is, for example, if you take an exam-- Atomicwork, and then the problem we're trying to solve is It's an old problem. It's a problem of service management. It's a problem of where people perceive this as an IT led service management, where we're reimagining this with, okay, should it be? It should be focused on employee service management. It's all about employees. It's about in the organization, their experience, them being served. If that's the case, why don't we just flip it and then reimagine the problem and look it from the perspective of the people who are actually seeking that request and that help? And then how do you then leverage AI to change the way the processes are done? Today, IT teams are small, and so they tend to basically tell every employee to come to me for a central way of getting your work done because we're too small, we can't give you for 10,000 employees with 50 people or 100 people or even 500 people. We've looked at historically how the past two decades of evolution of change happened within the organizations, adapting to the internet, to adapting to commerce, to adapting to cloud, and then adapting to data and processing capabilities and chips and evolving technologies. We are adapting, and I think what is going on now is the intelligence of bringing all of that together is giving us an additional superpower, and that power is what AI is. And then, but it also requires a lot more scrutiny and a lot more attention, a lot more process evolution, because it all depends on people, because people are the most important ones in the process of adopting the change, and in which that we have to redefine in, in our case for Atomicwork, if you look at the problem that we're trying to solve. It, you know, service management and IT led service management is what the notion today. It's a human to human, and it's a small number of IT teams trying to support thousands of employees in the scale at which, and so they're inviting the employees to come to them to a centralized portal or wherever IT teams are to ask for help. And then they're then providing that service back to them so that nobody's really neglected. Unfortunately, that is not necessarily the best way to offer a service because there are more number of employees waiting, the more number of processes that you're unable to build for their needs. So I think that is what we've started reimagining. It's the same problem. Ultimately, what you're trying to do is providing the service back to the employees, and employees are the ultimate recipients of the service. Why not then make them first as a focal point and not the process about bringing them to you? Instead, how about taking the service back to them wherever they are? How can you then reimagine this problem, the old problem, in a newer way, and then a newer solution to leverage AI to bring the service capability of whatever they need to them. So they could be in Teams, they could be in email, they could be in, in a browser, they could be in a application doing something. So if that is the case, why do you-- they need to now context switch and jump out of that and then go to a ticketing system and, "Hey, I'm unable to do this one. Can somebody help me?" Or that is what the friction is because when you do that, it's still, uh, you're coming back and you're waiting, and now we have to go back to that particular place wherever you were earlier to figure it out. So I think the, the inconvenience for employees is I am running for service rather than the service coming to me.
[11:34] Christina Ellwood: I think that's beautiful. That's exactly how it would have worked if we had AI available to us in the beginning when designing service management. So I love that you flipped it on its head, and I think that's a wonderful example of redesigning the organization from the inside out, where you're putting the employee first instead of funneling everyone into IT. You're putting the context first. Whatever they're already doing, that's the context in which they need the help. Let's deliver them the help inside that context. I think that's a wonderful example of how AI can imagine a new or can drive a new way of working together. It also reminds me of something you said earlier about the power of AI. I think one of the cultural changes is that creativity and imagination now have a much more important role in everyone's job, because we're able to be more creative with AI, and we're able to reimagine how things are done or imagine how we could get something done with this superpower. We're really giving, putting a premium on people's ability to think critically so they can evaluate the AI, to think creatively so they can solve problems and do new things with this new capability, and they can imagine how things could look if we made the change using the technology. Are you similarly excited about that-
[13:06] Lenin Gali: Yeah ...
[13:06] Christina Ellwood: element of AI?
[13:08] Lenin Gali: Yeah. So I think there is always going to be skepticism whenever you introduce something new and innovative into the field, into the ethos. And there's always gonna be detractors. There's always going to be change resistance that is going to happen. I think we need to be cognizant around how all of these forces are going to work against things. And then also, n- just because it is AI doesn't mean we have to also jump right into it, and having some skepticism, some sort of a thought process around why I have to do certain things is a natural human element and a factor in our own behaviors. And I think what really excites me is with all of that, in the past two decades of industrial evolution, technological evolution, commerce, and the adoption of technology and adoption of human elements that we are now connected to each other through social media and then always connected to getting information faster, it also created a lot of impatience in our human behavior. So that means if something is not available to you, then you're, like, a little more frustrated, "Hey, why am I waiting?"
[14:16] Christina Ellwood: Yeah.
[14:17] Lenin Gali: And, and why am I waiting for anything that is not around me? And then why do I have to wait at this, in a day and age where everything is being given in real time? I think we're also changing the way we see the world. Um, and I think with AI, the ability to really bring that re-imagination, that innovation to back to solving the problems that were solved in a different way before is the real opportunity here. And I don't-
[14:43] Christina Ellwood: Yeah, I mean, there's, it gets about velocity in that sense, isn't it?
[14:45] Lenin Gali: Exactly.
[14:46] Christina Ellwood: Exactly. Yeah. So I'm a very pragmatic person, and I think a lot of people who are involved in the early adopter phase here of, of AI are also very pragmatic. We all use metrics, and of course, one way that you can start to adopt AI is you can take an existing KPI or a KR and you can ask yourself, how could this better be done with AI as augmentation or AI as automation? So let's apply that idea to IT service management. What metrics matter most to track when evaluating the success of agentic AI deployments in internal service workforce support settings?
[15:23] Lenin Gali: Yeah. That's a great question because most likely up until now, we've been talking about mostly how many tickets are resolved, how many tickets are open, and we're looking at mean time to resolution as a metric. Mm-hmm. And so the mean time to resolution as a metric is good because there you're measuring... Because everybody's opening tickets, like all of the employees, and then now IT is basically measured on how fast you're, how efficiently are you solving this. But the MTTR typically is from days to weeks sometimes. And so that is really the challenge is because- You can only go solve a problem as fast as IT teams can solve because it's a lot of human-oriented, and it is basically a human opens a ticket and now you're basically studying it and then understanding it and going back and forth and, and figuring things out. And then so you have a lot of information that is missing because people are sending just one line or email or one line or Slack message, one line or Teams message or calling and then saying, "I'm having a problem." The other side, a person is having a difficulty to figure out exactly what that is. So now the diagnostic time really providing that service is going to be where I think the delays are. Nothing wrong with-- There is no, there's no bad intention. Everybody is service-minded because people who are asking are struggling and people who are trying to s-support are also trying. But the problem is that there isn't enough automation capability built in or avail-availability of the technology for them to do it. And-
[16:53] Christina Ellwood: You could certainly envision a situation, MTTR is a great example of a velocity metric, right? It's about time. So you could envision a situation where the human still opens a ticket, the human still-- uh, the human who has the problem opens the ticket, the human who is responsible for resolving the ticket gets the ticket, but an agent is in between those and is already offering a solution, but maybe they offer it to the service management IT person first to make sure that it's, it's appropriate and whatever, and then it gets sent back to the person who opened the ticket as a sort of way to automate the part I- the agent is best suited to do and then automate the contextual component of, I get to ask the question in the context I'm in, so no ticket, and then have the agent answer me on the basis of the best fit answer. Is that an ex- Yeah ... is that what you have in mind here?
[17:43] Lenin Gali: No. So I think the ideal scenario here is that if you have an agentic service management or an agent providing the service to you, it's real time. Literally, you ask a question in Teams or Slack, now you're not waiting because the agent is really immediately responding. 'Cause the agent is nothing but your personal concierge, your assistant. And the way the agent can be for anyone, agent has multiple personas. It basically for one-to-one, and that is one first thing that is going to come with agentic service management. That means you have your personal concierge waiting for you. The minute you ask a question, the response comes back immediately, try to assist you. So it's a real-time help. That's your completely going from your MTTR from a response in a few hours to a few seconds.
[18:24] Christina Ellwood: That sounds like we're jumping into the deep end right out of the gate if we're putting people in... allowing them to get service management within the context that they're in, right, as step one. Yes. Is that- Absolutely ... Uh, that's amazing, and that is something that you, is within reach today to do realistically today? That's- Oh,
[18:40] Lenin Gali: that's- ... exactly, yeah, yeah. Agentic service management is nothing but really having agents fielding the first level one support that is basically saying, "Hey, I lost my badge and I need to enter. I need a new badge," or, "I am actually forgotten my password. I need to log in. I basically need... My computer is having issues and I can't connect," or all kinds of things that you typically have, or, "I, I need access to a particular application because I'm now stuck." So all of these are real-time needs, like I need it because if I don't solve it right now, I'm waiting for two hours to two days until somebody gives me that access. I think that is the type of things that we can fully automate today and be able to get out of the way.
[19:20] Christina Ellwood: So governance is obviously gonna be very important in something like that. Yes. There's security components of what you just said. There's governance components of what you just said. So how do we think about the governance and security issues related to using agents in an IT service management system- Yeah that you describe?
[19:37] Lenin Gali: Yeah, yeah. So let's just give you the metrics, that MTTR you asked earlier and then, and I'll come to the governance part because we're going into that eventually, is that the MTTR now becomes a real-time metric. And tickets are being addressed by AI agents directly, and then if they solve the problem, they'll close the tickets. And because most of the tickets are actually now waiting for this customer, or in this case your partner, and an employee needs to basically finally say, "I am done. I'm happy that your service is done," only then the agents are closing because they're not allowed to close. And o- over time, I think you will close the tickets. And so that's where the ticket response and inability to really measure correctly is an issue today. And that goes away because now problem is solved, and automatically AI will take the decision to close it and then move on. And then the routing happens, and then all of that. But the productivity, what is-- how do you measure that? So the ticketing, we want to move into a point where deflection happens. That means there is no human involvement required. AI agents are solving the problem by opening the ticket and closing the ticket. It's happening behind the scenes, so you don't have to really now measure tickets anymore. It's not about volume of tickets. It's about the outcome. Is the employee happy? Are they getting the service done? Is the quality of service correct? So these are the measures that are coming in. How fast are you solving the problem? And, uh, how-- what is the quality of that problem that you solved, or does it actually create an additional problem? And these are the things that you start measuring. And ticket deflections are number one, and then from there you go into really productivity gains, like how much of productivity time you give back, uh, to people. How do you measure that? It's basically based on the ticket opening to ticket closing in the past to present, because there's a benchmark that you would say. Okay, in the past, without AI, you're at this level, and now going forward, we measure that, and are you below the benchmark or so that level. So now you see the time saved for all of the productivity that we're bringing back to the employee. And-
[21:39] Christina Ellwood: That sounds like a stopgap measure, though. At some point, we're gonna have to measure something else, because it's not gonna be about comparing to the old manual way. That'd be like comparing the productivity we get from our computer to the productivity we got from a typewriter.
[21:53] Lenin Gali: Oh, absolutely.
[21:54] Christina Ellwood: So, like- Of course. We're gonna have to evolve that. Yeah. Y- y- yeah, but it make-- what you say makes perfect sense. The fact that the flow is uninterrupted when I'm trying to do something is, it's very difficult to measure the value of that as compared to having to stop and go out and come back and do all of that. But once you have that, aren't you able to set a higher bar for what it means- Go ahead ...
[22:18] Lenin Gali: and the volume. And you can see, I think what is really happening here is that the baseline need to be important because everybody's looking for ROI. You're not gonna get an ROI unless you justify in steps. You can't just say you just use AI and it'll work magically. I'm like, how do I measure it? The measure is always going to be somewhat a baseline. You have to say, "Okay, this is what I'm spending today, and this is how much I saved. This is how much time it took today, and this is how much I saved." And that's how we measure ourselves. And then at some point, when you start looking at the value creation, then you look at outcomes and say, "Okay, I see this is valuable to me, but what outcome are you driving with this? Like, ultimately, where is this going? Are you saving me money or are you increasing my productivity so that I can actually do more, and that means I can generate more, I can build more, and I'm able to generate more revenue?" There are only two elements for an organization, right? They do need to go hand in hand. One, I don't wanna spend too much money because I wanna optimize. And the other said, I want to generate more revenue. That's the growth. So do more with less. And how do you do that? And that's exactly where AI comes in, and that outcome is now where we are going to eventually get to. And that's where we go from being human assisted AI to AI doing the work and becomes the workforce So you can deploy a, an SRE, site reliability engineer, or you can deploy a, a data engineer, or you can deploy an analyst. You can deploy-- These are all things that are happening today, but they are in a very early stage of doing this qualitative work in a way to make that work automatable within the constraints of current AI capabilities. So if you look at the same thing in about a, by turn of this decade, you will be able to see majority of the work that is done by these repetitive ways of today's engineering, today's IT, and today's product development coding. All of these will be fully automated to a point where you have to now use them, use these capabilities to build the systems. You see what I'm saying? So-
[24:43] Christina Ellwood: I do.
[24:44] Lenin Gali: I
[24:44] Christina Ellwood: do. I-
[24:45] Lenin Gali: We, we-- Yeah, we're basically building the components to be leveraged. These components are much more intelligent than the components we have had before. So that means you now need to retool yourself, and then you need to now understand the power of these additional capabilities that are coming in that are humanly impossible for you to do, but machine-wise and AI-wise, you can. But then you need to be ready to use them, put them all together, build the newer systems, and that's where we're going.
[25:14] Christina Ellwood: So I go back to the governance framework question, because I think it's extremely important that this level of application of the technology has guardrails and security frameworks and compliance frameworks in place so that we run our organizations responsibly and robustly. What's your thinking about the role of AI in the governance, compliance, and security of the system itself?
[25:46] Lenin Gali: Yeah, great question because trust is important. Obviously, all of this comes down to one thing, right? How do I trust this is doing the right thing? How do I trust that it will tell me when it failed? How do I trust that it actually is compliant? I think it comes down to the trust part, and then comes the second part is securing it. Yeah, I trust that you show me all of these, you'd be transparent, you have logs, you have everything that you're doing. But then how do you then protect the system because you're introducing something new, and how do I know that it is secure? And okay, this is great. So you have trust, and then you have security now, let's say. Then how do you make sure that it is governed? Um, that means you're giving guardrails. You're giving me levers. You're giving me the ability to turn it on, turn it off, and controls that I need. And that is really the third thing. And then the fourth thing for all of these is compliance. We have set compliance, and compliance is nothing but a standards and procedures that you have to follow in order to meet the compliance standards that are set. And so if you're a builder, uh, you're a builder in the sense that, uh, as a startup, the expectation for you to be an AI company is you have to have all four of these, right? You have to be trustworthy in the sense how do you build the trust is because you're transparent, you show everything, you have the capabilities that they're asking, and everything is visible and transparent. But then you're also showing them you have com-- security protocols that you're following. You have SOC 2 certification. You're ISO certified. That means you're building the processes that are required in order to be secure, right? And then you go into compliance and then making sure that you're actually compliant about all of the regulatory aspects, including these certifications, but you're also providing the vulnerability scans and all the other things that are required in order to stay certified, right? So all of these are important for you, not only as a company that is a startup, but also is important for an enterprise as well. You need to also h- incorporate these things if you're building AI applications internally, that you have to adhere to the same standards as you put a vendor to. And this is something that I see a lot of lapses. When you go to an enterprise and you ask, like, what certifications you have, most of them don't have the same certifications they expect the vendor to have.
[28:15] Christina Ellwood: That's interesting. Now, you run a very large CIO organization, the Global CIO Circle. Is this something that you talk about within that group about the importance of having that s-symmetry in these four parameters, or is that something that is still controversial, the idea that this is a front and center if you're gonna be adopting AI?
[28:39] Lenin Gali: No. I think every CIO is, is a risk mitigator, right? And they risk-averse in the sense that they actually do not want to introduce more risk than they can handle. And they are asking these questions naturally because it is their job to make sure that whatever they're bringing into the organization is safe, right? And it is scalable, and it is something that they can actually support. And in part of the Global CIO Circle is really to bring that innovation that is happening in, in, in isolation. For example, the founders are building-- They're actually moving a lot faster because they don't have the baggage. They don't have to worry about a lot of tech that they're not carrying anything. They're just basically building something new, something faster, something that, that is going to solve the problem in a different way as a solution, as we were talking about, as Atomicwork, for example. But then there is a gap between what you're building to how people know you. How do you diff- how do they differentiate you from others that are actually also doing the same thing or say or claim and all of that stuff? So I think that is where the noise to the clarity is very important. So the trust around the people, the CIOs, like if one CIO basically deployed something that they like and, and they want that to be percolated to the other CIOs in conversations, I think my job was through Global CIO Circle is to really bring that, that, that rich conversations around the experiments that might be happening in silos to come to and then basically say which experiments are working. Uh, what is it that they're actually excited about? They may st- stumble upon a startup that is really doing something really incredible, and they need to be able to share that with others. I think what we're trying to bring through this Global CIO Circle is create these events, bring innovative startups, and bring these ch-- you know, champions of innovation of CIOs and CTOs and CISOs who are basically protecting the technology security and, and business interests to come together, look at these innovative startups and say, "Hey, I like what you're doing, but I don't think you're actually fully there. What are your thoughts?" And so that dialogue happening that early with the founders and the executives really shapes the innovation that these founders are building, and I think they're also seeking that. And I think that gap is what I'm trying to bridge between the two by bringing them to become advisors to these founders, bringing them be advisors to these product developers, like their executives within the startups that are building these. So that the executives who are actually going to be eventually bringing and introducing these things already ahead of it and know what is coming from these and then so to bridge that gap.
[31:23] Christina Ellwood: Yeah, it's, that's a mutually supportive approach. I think that's very smart, so they're ready to absorb this newer technology. So as you look ahead to the next three to five years, how do you see agentic AI, specifically agentic AI, reshaping enterprise functions like IT, HR, and finance?
[31:43] Lenin Gali: Right now, we're basically going into learning phase through experimentation phase, and once we start deploying, we need to start also building some sort of an education phase, like awareness phase to say, "Hey, AI may not give you the right answer." That means it's not a failure. It means it's a learning deficiency, and that means there is some sort of a work that needs to be done from the adopters, in this case, the humans who are basically certifying that. I think what we're basically building with Atomicwork is really in the next three to five years go towards that workforce level, creating fully automated work that can be done where the human-to-human interactions will move, morph into human-to-AI interactions and then AI-to-AI interactions all are captured within one platform, and that's the agentic platform and service management. And one of the things that we're also saying is that when you're introducing AI And you have so many agents are being deployed in the enterprise. How do you know which agent is doing what? And when a human gets involved, why did the human get involved? And if there is another AI agent gets involved, why did that AI agent get involved? Because this is where the governance and the compliance and then transparency and visibility is important because eventually, what is the ultimate goal? The ultimate goal is productivity. Ultimate goal is to really become a pioneer in that particular field and transform yourself to really achieve the business goals. If you want to do that, you need to have that visibility and transparency of how you're introducing AI into your organization. There has to be a first responder. That's why we have 911s and all these other things that we've set up, so that when somebody needs help, you can't be saying, "I need help," and then 10 people show up.
[33:42] Christina Ellwood: Mm-hmm. So are you envisioning that three to five years from now we have an agentic workforce that are automating whole areas of service management and maybe finance and HR, and we have first responders, if you will, who are handling the interventions when they're needed? Is that the picture that I should have in my mind?
[34:07] Lenin Gali: And so if you take the human nature here, the way that we've created our hierarchy today in terms of expertise and support, there's a level one support and level two, level three, level four, like that. Each level is created. There's a reason why these levels are, because you want to first address the what is that request that is coming in? What is that problem they're reporting? Triage that, understand it, and then route it to the person who could solve if you cannot solve it, if you don't already able to solve it. So now you go to the next level of support, and then from there to go further and further into deep into the product capabilities. I think the way the AI agents are going to be deployed also in, in the similar way. There's gonna be a level one agent, level two agent of AI that basically does the triaging and solving the problem. And when they can't solve it, they will hand off that to a Salesforce agent or an SAP agent or a Workday agent that they then go inside and then figure out what it is that they need to do and return back. And that handshake will happen, and that's how the agentic ecosystem needs to also evolve. You cannot be having a separate structures, because if you just deploy and expect an AI agent to do everything, then you're creating a super agent and somebody needs to figure out how, where is the limit for that particular agent and how that's a single point of failure. Right?
[35:32] Christina Ellwood: It's also a wor- wonderful attack vector.
[35:36] Lenin Gali: Yeah, exactly. Not only that. Not only that, but, but also then it creates a lot of a problem because now you have these ecosystems that we've already built in the enterprise where you have HR systems, you have sales systems, marketing, finance, and all of that. Every system is, you know, controlled by their separate vendors. Now they are going to introduce their own ways of coming into the enterprise and saying, "Hey, for you, I'll solve this problem for you. I'll solve this pro-" So the competition is good, however, it is also introducing chaos. And that chaos is what is going to be the realest, most worrying thing to CIOs and CISOs and the CTOs today if you're an enterprise, is that how do I manage this chaos? And that-
[36:19] Christina Ellwood: Would that being done through the service management layer? Do they, are there other models?
[36:23] Lenin Gali: There are other things, like for example, identity management. So you'll have to go into an IGA type of model where we've already built this. If you're introducing an application into the enterprise, you go through a single sign-on Okta, so you have guardrails built so that who gets access to that application, how long will they retain that access. So all of these IGA becomes a foundation. Every agent should get an identity, because agent is nothing but a human e-equivalent of a work in a workforce. So an AI agent should also get an identity, and that identity needs to be somewhat tracked and then say, "Okay, this agent with this identity has done this task," so that you can easily go and figure out who did what. You can't have 100 agents running wild and nobody knows what they're doing. And if you have that situation, you're gonna run into... And that's where the support system comes in. That's where the service aspects come in. That's where the controls and guardrails and providing way of an order is important. So-
[37:21] Christina Ellwood: Yeah, it sounds like an actual framework is needed too, not just a system, but you need to have a framework for thinking about- Yeah ... and designating. Yeah. Do you have a framework that you recommend? And I'm gonna ask you about other resources too that you recommend, so we might as well do that now. What resources do you recommend to listeners who want to learn more about this model that you're describing of an agent workforce in a governed framework?
[37:45] Lenin Gali: Yeah. So there are varying ways that most of the model providers, infrastructure providers, and cloud providers are also already thinking, because they themselves are, like, literally running into the similar issue. They need to also have a piloting system that knows, like a command and control, like air traffic control, just like that. You need to have also agent control system that basically says, "Okay, when you deploy an agent, that agent needs to have a role, and agent needs to have some sort of a thing." So what we're basically providing through Atomicwork is your ability to track an agent entry. And when an agent is introduced, if that agent is basically registered somewhat in an MCP or A2A or a agent space, in this case for Google. There are various ways everybody is trying to basically provide their buckets of the same concept. But I think what will happen is we don't know exactly where we'll end up in about five years from now. But what I'm hoping is that we don't create siloed agent spaces, siloed agent ecosystems, because then it becomes another chaotic situation. Who would you then introduce as your agent management system? Who, who would you-- Then they come with their own limitations, and now all of a sudden you end up paying for three different agent management systems because these guys have become a consortium. These guys have become another consortium. Now, if you want this, you go here. If you want that, you go here, like a Microsoft or Google or AWS or whatever. The ecosystem is really now very fluid, and my worry is This whole thing is going to evolve to a point where it is going to be chaotic for a while, but we need to come up with a common and a governing system that adapts to these agent mechanisms, ability to control how agents are introduced, how agents are performing their work, and when you want to turn them off, you have an easy mechanism available.
[39:45] Christina Ellwood: Is there someone working on that now, and can you recommend-
[39:48] Lenin Gali: There's a lot of research going on in this space right now and across the organizations, whether it is Google, whether it is OpenAI, whether it is Anthropic, whether it is AWS. Everybody is really looking at Microsoft also. Everyone is looking at this as an opportunity, and, and now we need to figure out who would introduce something like this as a platform and how it is. And what
[40:09] Christina Ellwood: we- That strikes me, Lenin, as very self-serving to those organizations. Is there an academic or a standards body that is looking at this at all?
[40:17] Lenin Gali: I don't know. The idea right now is that people are imagining, people are really realizing what is hap- what is going to happen. But I see this is a situation that we may end up if we don't come up with a common protocol, and this is where A2A and MCP, these are all the things that are also introduced by these providers. But you have to adapt to some sort of a protocol to be able to manage these interactions.
[40:42] Christina Ellwood: And- Have you looked at all at what NANDA's doing out of MIT, the-
[40:45] Lenin Gali: Yeah, NANDA is a- That
[40:46] Christina Ellwood: might be a framework that's worth thinking about.
[40:48] Lenin Gali: Absolutely, and that's something that I was there when he introduced that in an MIT innovation forum. Again, it's an, it, it has to be a governing principle. Somebody needs to adapt to it, and embracing it is important. It needs to be open, uh, so that others will be able to use it across the board, so the adoption is easy. So I think these are all things coming in right now. There's AgentSpace and there's AgentForce, there is Microsoft Copilot ecosystem, and there's so many different things coming in. How you bring that together is both technologically challenged, uh, adopt- adoption challenges, and also protocol challenges and securing and governing and all of that. So there's a lot of work that is coming ahead of us that we have to be very aware of.
[41:36] Christina Ellwood: Good. Good. Well, just for our, for the sake of our listeners, the NANDA project is led by Ramesh Raskar from MIT, and it is an open source project that is trying to define these standards and protocols for the agentic internet. So it's not specific for enterprises, but the principles that Lenin has been outlining for us today are very much being instantiated in the system that they're building. So there may be some good lessons that we can borrow from there, or at least perhaps they even are gonna provide us the roadmap that we all need that is not as... And I don't mean self-serving is always bad, but in the case of vendors doing self-service at Austin of- often can mean that we get lock-in or we get solutions that aren't necessarily ideal, but for us, but are ideal for the vendor. So it's good when there's independent work going on and not just vendor work going on. Lenin, if our listeners remember just one thing from our conversation today, what would you like it to be and why?
[42:34] Lenin Gali: I think what I would say be open-minded. This is not something that we have seen in the past. I think what, what needs to be really, really, uh, very important for anyone who's actually thinking about AI is there is no one way to solve any one problem. With AI, you're actually getting that super intelligence capability. That intelligence actually is allowing you to think differently, reimagine world problems in new ways, move faster, and move in a way that the consum- the consumer of that particular feature, whatever you're building, whether it is an organization, whether it is a human that is consuming that, is-- has full clarity, transparency, value, and outcome, all of that defined very much. And so if you're building, you need to have those governing guardrail, safety, and security. If you're a buyer, you are actually ensuring that whatever you're buying is actually fully functional and you can measure it, and you'll be able to use it for a long time rather than just a short time. So I think that's something that I hope people will, will pay attention to.
[43:48] Christina Ellwood: Yeah. Yeah, that's great. So in this AI era of revolution, what's your defining edge as an AI leader?
[44:00] Lenin Gali: As much as we're expecting everybody else to basically embrace, we also need to be in the thick of it. I spend quite a bit of time reading, uh, following, and you can see me, and I think LinkedIn has been, if you say anything, but I spend a quite a bit of time just reading what is happening and who's doing what. And even with that, I'm not at a pace in even capturing what is exactly going on. It is very important to be educated. It is important to be out there and finding the real value out of all of the noise that is out there. And so I think if you're a leader, uh, agility is very important. It is the most important, I would say, feature or capability that you have to have. And two, networking. You need to network and get to know people, get to know ways in which you can distill what is right for you, because at some point, you rely on human, uh, capabilities, even though you have machines telling you what is right, what is wrong. Sometimes we still have that notion of, "Hey, I think if I talk to Tom or if I talk to Vijay, they'll tell me exactly what is going on." You see what I'm saying? So I think that is really very important. So we still need that personal touch and personal connection because we do touch human-to-human interactions as much as the machines are helping us basically learn a lot faster and adapt a lot of things in a different way.
[45:29] Christina Ellwood: For learning, what are your favorite resources?
[45:32] Lenin Gali: I follow a lot of LinkedIn material that is out there, and I do follow a lot of the people who are actually creating most of these.
[45:41] Christina Ellwood: Anybody come to mind?
[45:42] Lenin Gali: A, a person? Yes. I don't have any one person, actually. That is really important because I'm following a lot of these different people, including Satya from his point of view to going into LinkedIn writers and a lot of influencers actually. A lot of influencers are doing a lot more content than actually creators, 'cause they're distilling it and then showing what is really going on. So I have, like, tons of followers that I follow, and then I'm looking at what they are producing and either I like it, and if I like it I save it, and then just I go back and then when I have time to review it. And I myself are also involved with my team who are actually also building things and opening doors for them to talk to people who are actually the real users. And so that is also a way for me to learn about our own product. So I'm talking to CIOs on one end, and I'm talking to my, our product teams on the other end. I'm also talking to our engineers and people who are building and seeing what they're doing and what challenges they're facing. I think it's very important to really experience it rather than sitting on the sidelines, and I think that is... It's one thing to read, the other thing is actually really going inside and then seeing with your hands and also talking to people who are actually experiencing it.
[46:53] Christina Ellwood: Gotcha. Okay. So being agile, being curious and learning, networking, and working at all levels, being put your hands on the wheel at all levels so that you have a personal connection to what is going on. Is that fair?
[47:07] Lenin Gali: Absolutely.
[47:08] Christina Ellwood: Okay. Lenin Gali, chief business officer and founder, founding team member at Atomicwork, thank you so much for joining us today. It's been a pleasure talking with you.
[47:17] Lenin Gali: Same here, and I'm incredibly impressed with the questions that you had for me, and I'm positive this is all gonna be enjoyed by the folks who's gonna listen to us.
[47:25] Christina Ellwood: Thank you. Bye-bye.