AI agents no longer wait for a human prompt. They invoke tools, write to repositories, call external APIs, and consume tokens autonomously, across endpoints, browsers, and Kubernetes clusters simultaneously. Gartner reports that only 13% of organizations believe they have adequate agent governance in place. The remaining 87% cannot reliably see what their agents are doing, how much they are spending, or whether sensitive data is leaving the environment. Once an agent takes an action, reversing it costs more tokens, more time, and in regulated industries, potential compliance exposure.
In this interview on TFiR, Poonacha Kongetira, CEO and Co-founder at Classie, breaks down how enterprises can discover sanctioned and unsanctioned AI agents running across every surface, attribute token spend to specific users, agents, and departments, and enforce unified policy in real time using Classie’s Supervise platform.
Guest: Poonacha Kongetira, CEO and Co-founder at Classie
Show: TFiR
Here is what every platform engineer, security architect, and AI infrastructure team needs to know.
Technical Deep Dive
Q: Why is AI agent governance a more urgent problem in 2026 than it was during the initial GenAI rollout?
Poonacha Kongetira, CEO and Co-founder at Classie, argues that the shift from prompt-response GenAI to autonomous coding agents and knowledge-worker agents has changed the threat surface completely. Earlier GenAI interactions were gated by human latency, so token consumption and autonomous action were bounded. Coding agents such as Claude Code and Codex, and their knowledge-worker counterparts, now operate at speeds and action volumes that no human-supervised workflow can match, making the governance gap exponentially wider than it was in 2022.
“The token volume consumption was orders of magnitude lower. Right now with a lot of the autonomy that people are able to provide to these coding agents, token consumption and the ability for these things to actually take actions is just exploding.”
Poonacha Kongetira, CEO and Co-founder, Classie
Q: What is the difference between sanctioned and unsanctioned AI agents, and why does it matter for security?
Unsanctioned AI is any agent or tool the enterprise has not formally represented in its identity provider, not reviewed for data access, and not covered by organizational policy. Kongetira notes that in every Classie deployment, the sensor architecture surfaces shadow AI within 30 to 60 minutes that IT teams were confident did not exist. A gray area also exists: agents the enterprise has formally sanctioned but whose actual usage, data connections, and actions are invisible to the security team.
“I’ve never had a single experience where the customer has not been surprised to find new manifestations of AI which they had not actually bargained for.”
Poonacha Kongetira, CEO and Co-founder, Classie
Q: How does Classie’s Supervise platform detect and respond when an agent takes a prohibited action?
Kongetira describes a three-stage journey through the platform. Discover identifies every agent running across endpoints, browsers, and Kubernetes fabrics. Analyze attaches identity, data access, and behavioral context to each agent session. Supervise then enforces a policy ruleset: operators can configure alerts for specific conditions, blocks for others, all through a single unified policy agent built on OPA. Because the same OPA policy plane covers every surface, a rule written once applies whether the agent is running locally, through a SaaS browser session, or on internal compute.
“One single unified policy agent and control panel to control all of the different AI running in every surface that AI can actually be used on.”
Poonacha Kongetira, CEO and Co-founder, Classie
Q: What does Classie capture in its runtime transcript, and how does that become a chain of custody record?
The Classie sensor library captures prompts, responses, tool calls, local standard IO access, and agent context and memory, because intent lives in context and memory, not just in the prompt. Crucially, when an agentic workflow spans a local machine, a frontier model API, and a hosted agent on an enterprise Kubernetes cluster, Classie assembles all of those surface-level traces into a single correlated session transcript. That multi-surface, multi-agent transcript is what enables intent-based decisions over the full span of a workflow rather than at the level of a single tool call.
“To really understand the intent of the transaction, you have to be able to put together that multi-agent transcript where you associate all of these different surfaces with one common workflow.”
Poonacha Kongetira, CEO and Co-founder, Classie
Q: How do you attribute AI token spend to a specific person, agent, department, or project without manually correlating logs?
Kongetira explains that spend attribution requires two things working together: collecting the session transcript (which contains token counts per turn) and plumbing the identity of the human or agent that authorized each transaction through the full workflow chain. Classie calls the resulting output Token IQ, a continuous, minute-by-minute aggregation of spend broken down by user, model, project, and department. When trace volume spikes unexpectedly, the system can trigger an alert to the responsible user before a runaway session generates a large and unexpected bill.
“We are able to create this attribution of spend along all these different dimensions: people, model, project, department. We aggregate that on an ongoing basis on a minute-by-minute level, so that you see what’s going on as it happens.”
Poonacha Kongetira, CEO and Co-founder, Classie
Q: Why did Classie choose OPA as its policy engine, and what does that mean for enterprises already using OPA elsewhere?
Kongetira positions the OPA choice as a pragmatic one: OPA is open source, benefits from broad community review, and carries a high degree of quality as a result. More importantly for enterprise teams, writing AI governance policy in OPA means that policy definitions can be versioned, reviewed, and audited through the same infrastructure-as-code workflows already in use for cloud and Kubernetes policy. Classie’s single unified policy agent means those OPA policies apply consistently across every surface where AI agents run.
“Open source also has a pretty high degree of quality because of the amount of review which actually goes into it.”
Poonacha Kongetira, CEO and Co-founder, Classie
Q: Where should continual learning infrastructure for AI supervision models run, and who owns the resulting model weights?
Kongetira frames data ownership as a founding principle: because Classie’s supervisory models learn from customer trace data, the resulting updated model weights belong to the customer, not to Classie. Classie exports a SaaS tenant that can also move on-premises; all customer trace data and all Classie models run within that tenant boundary. This means enterprise-specific behavioral patterns and updated detection accuracy stay inside the enterprise environment and are not transferred to other tenants or used to improve Classie’s shared models.
“If our models learn from the customer data, then those updated weights become the property of the customer. We’re not exfiltrating their proprietary know-how.”
Poonacha Kongetira, CEO and Co-founder, Classie
Q: How do the Discover, Analyze, and Supervise stages work together, and does adding them increase operational complexity?
Kongetira presents the three stages as a single platform journey rather than three separate tools. Discover surfaces every agent and its surface of operation. Analyze attaches user identity, tool usage, and data context to each session. Supervise enforces the policy rules the team decides on after reviewing what Analyze surfaces. The key architectural decision is a unified data model: rather than sending events from multiple specialized tools into a SIEM or data lake where they cannot be correlated in real time, Classie assembles all telemetry into one fused transcript API before detection runs, removing data assembly as the bottleneck.
“Data assembly is actually the long pole in most tooling. We’ve taken that data assembly out of the picture and made it assemblable in real time across the entire transcript.”
Poonacha Kongetira, CEO and Co-founder, Classie
Q: What visibility do security and IT teams gain after turning on Classie, and how does that change governance conversations at the executive level?
Kongetira describes the primary outcome as giving management a coherent, data-backed picture of AI usage across the enterprise, something most organizations currently lack entirely. Classie’s summarization models generate reports from the collected transcripts so that C-suite discussions about AI policy move from assumptions to evidence. The controls layer then carries forward whatever governance decisions the organization makes, closing the loop between visibility and enforcement.
“The most useful way that we can actually help influence this going forward is to be able to present the data of what is found in an actionable way so that when people look at it they get a pattern and then they can decide on what to do.”
Poonacha Kongetira, CEO and Co-founder, Classie
Q: How is Classie different from existing DSPM, DLP, browser security, and GenAI prompt-response tools?
Kongetira’s central differentiation argument is holistic session coverage versus fragment-level visibility. Existing tools each see one surface: a DLP tool sees data at egress, a browser security tool sees browser traffic, a DSPM tool sees data store access. Each writes detections to a separate data repository, and no tool can correlate them into a real-time session-level intent determination fast enough to intervene. Classie integrates security alerts and spend alerts into a single unified supervision layer and outputs to existing SIEM and observability platforms, including Splunk and Datadog, so it fits existing SecOps and IT ops workflows.
“Tool fragmentation is the enemy of real-time supervision. You just can’t put the jigsaw together in time. Access to the whole is what you need to actually make the right decision.”
Poonacha Kongetira, CEO and Co-founder, Classie
Resources & Documentation
- Classie, AI agent supervision platform: Discover, Analyze, and Supervise AI agents across endpoints, browsers, and Kubernetes fabrics with unified OPA-based policy enforcement and Token IQ spend attribution.
- Open Policy Agent (OPA), open source policy engine used by Classie as the unified policy control plane for AI agent governance across all surfaces.
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: As we all know that AI agents are no longer just answering questions. They’re locking into your systems, moving data, and even spending money on behalf of employees. According to Gartner, only 13% of organizations believe they have the right agent governance in place, which means most companies can’t see what their AI is actually doing. And that gap only grows as agents move from pilots into production, from assistants into autonomous agents that are taking actions. Because once an agent takes an action, you usually can’t undo it. And then you will have to actually spend more tokens just to try to find and fix those mistakes. Classy is trying to solve this problem with a solution they call supervise. And today we have with us Punacha Kongetira, CEO and co founder of Classy Punucha. It’s great to have you on the show.
Poonacha Kongetira: Thank you so much for having me. Swapnil. Pleasure to be here.
Swapnil Bhartiya: Before we get into the problem, I want to understand the foundation of the company so that our audience, they do know who they are listening to. Talk a bit about when and why you created it, because if you look at this problem today, which is a huge problem, so talk a bit about the company at its origin.
Poonacha Kongetira: So I think my AI journey started about, you know, I would say probably about 10 years ago. So as part of this Google team that was working on TPUs and which is the accelerator, you know, for machine learning, which, you know, Google developed and uses. And from then on I went on to work at another AI first company where I was responsible for not only the infrastructure that the models ran on, but the training of the models themselves, accessing inference and training pipelines using kubernetes as a deployment fabric and APIs as a front end. So we had some idea of how models tended to behave. And I think the defining difference, if you will, between all other types of tools that we’ve built in the past and these types of tools is that machine learning is basically the science of models, learning what to do stuff from the data they presented with. It’s not quite clear how this logic is actually encoded in these models. There are maybe a gray box or even a black box for the people who build them, and certainly a black box to people who use them. And today we actually find a lot of people building agentic applications that are wrapped around these LLMs which may be built by a frontier lab, built by an open source community, et cetera. And so the defining thing for these application builders is that they’re using something which is a black box and something which has also got Variable behavior, that’s the nature of the map, the nature of the orchestration which causes behavior to be somewhat variable. The same prompt may not always elicit the same response. So turns out that we haven’t built machines like that before. Things that you could. All the machines we’ve built before have been things that you could actually pre test exhaustively and then put out into the field. These things you can’t. And luckily we do have experience working with these types of things. They’re called people. People are actually black boxes which have variable behavior. You can teach them a certain thing, you can never always be sure that they’ll follow that instruction. And the way we handle them in organizations is by putting in superiority structures, right? Where in real time or through coaching and stuff like that, you sort of gently, you know, manage people’s actions in a certain way so that they have the desired outcome. And so that led us to, you know, realize that similar infrastructure was actually needed to manage agents. But they had to be really fast because agents are like 100 times faster than people can ever be. And so that’s what led us to find, to actually find, you know, to find the solution and to found this company called Classy, right, which is designed to supervise AI actions, you know, alert in real time when they’re sort of doing something they shouldn’t be be able to supervise their spend and also to like create these exhaustive transcripts of what they did so that things can be forensically investigated, assessed for compliance and things like that. I think that’s how we got to this thing and how we ended up defining supervision as being a comprehensive visibility and security layer with spend, attribution and control and the ability to create compliance orientated transcripts of activity with the chain of custody very well, you know, established.
Swapnil Bhartiya: I talk about this problem almost on a daily basis because this is an industry wide problem. Everybody’s aware of it. But I want to look at it from your perspective, from your lens. What are you seeing inside enterprises right now that’s making agent governance an even more pressing and urgent problem? Not something to figure out later.
Poonacha Kongetira: I think what’s happened in enterprises is that, you know, it started with, you know, the chat GBD moment which was 2022, as everybody knows that that led to sort of the utilization of gen AI within companies, nominally through chatbots, but also through copilots and stuff like that. But I think this year in 26, the, the use of agents such as Claude Code Codex and their cousins like the co work and stuff like that, built for Knowledge workers has just exploded in enterprises. We see this with every customer that we talk to. The difference between the two, I think, is in token volume and what they can actually do. Genai was still sort of like governed by human interaction, like prompt response, interaction delay. So the token volume consumption was like orders of magnitude lower. Right now with a lot of the autonomy that people are able to provide to these, know, coding agents and other such agents, like these coding agents, token consumption and, you know, the ability for these things to actually take actions, right, is actually just exploding. And so I think every enterprise I’ve talked to, you know, is, you know, seems to be using these, these things very heavily because ultimately they provide productivity to the enterprise and you can’t say no to that.
Swapnil Bhartiya: I also want to just quickly explain it to our audience. What is the difference between sanctioned and unsanctioned AI agents and what does that distinction mean for security?
Poonacha Kongetira: So I think we see this with customers all the time, right? So when we actually walk in and you know, get a sense of like, what problem they’re trying to solve, they’d be like, oh, I think we have a lot of our AI users pretty much locked down. And then we deploy and within half an hour to one hour, our sensor architecture starts finding all the shadow AI which is living or being used by their employees, whether it’s on the endpoint, whether it’s deployed on a Kubernetes fabric, internal compute of the enterprise, or being accessed through a browser. And almost always I’ve actually never seen. I’ve never had a single experience where the customer has not been surprised to find new manifestations of AI which they had not actually bargained for. They thought they had a lockdown, but clearly there was usage of different tools which they did not know, and the connecting of these different tools to potentially sensitive workflows and or data reposition. And so in a way, the way to think about sanctioned or unsanctioned is that unsanctioned AI is stuff that you don’t know about, haven’t bargained for, and haven’t gotten in organizational policy or control to do something about. I think I would call that unsanctioned AI. Sanctioned AI is if you’ve actually found that, okay, one of these AI applications are useful, you represent them in your identity provider. Any user who like, you know, uses that application, authenticates and authorizes the agent to do things on their behalf, then, you know, it falls under the definition of sanctioned. There is a gray area though, where you actually know that you’re running certain applications but you don’t know what people are doing with them. So that’s a gray area where you’ve sanctioned an agent that. But you have no visibility into what people are doing with it. And I think that’s unfortunately something that people have to solve. And that’s exactly what, so what Flossy does, for example, if you install us in your enterprise, we will find a whole list of stuff which is running, of which some things may be sanctioned and a whole bunch of things may be unsanctioned. That gives you the visibility and the ability to say, turn this on, turn this off. If you investigate more, whatever, and the sanction stuff, right, we can track how people are using it, for what purpose, what their spend is, what models are being used, Is it an efficacious use of, you know, token dollars? Is it a secure use of the agent and the data which you’re actually feeding it? So we do all of these things. And so I think when it’s like when it’s fully understood, I think that’s when you can actually call it like fully sanctioned AI. Otherwise, even if you’ve sanctioned it, it probably falls into this gray area of not quite knowing what people are doing with it.
Swapnil Bhartiya: Can you walk us through when supervise catches an agent doing something it is not supposed to do, what actually happens in that moment? Does it alert the team, does it reroute it, does it stop it, walk us through what happens?
Poonacha Kongetira: I think it’s a journey for a customer and I’ll explain what I mean by the journey is the first step in our journey is to discover what’s going on, right? And most people, when they discover what’s going on, they don’t want to initially like immediately start turning things on or off for blocking behavior. Most security operators or IT operators want to have the time to understand what the usage is like surface, the usage to management, etc. And then come up with a consensus based approach to limit or control access. So the first step is discover, you find out what’s running. The second step is to understand the dynamic usage and for that we are able to turn on a set of policies and sensitivity detectors, identity followers, things like that, which help the operator to not only know what application they found, but what a given user is using that application agent, tick application for and what data is it connected to. So that whole user agent data and tool usage is all boiled together so that you’re able to analyze the usage of these things and then decide should you be worried about it or not. And the final stage is Supervise when you actually turn on the controls, which tell you, okay, right, if this happens, I want you to send an alert. If this happens, I want you to block it. These are all a set of policies or rules that you can actually write. And the nice thing is that we’ve actually built this out to be a single unified policy agent built on this thing called opa. And if you write your organization policies to that, you know, through that unified agent you can control AI actions no matter where the AI is running, whether it’s on your laptop, whether it’s being accessed through your browser on SaaS or whether it’s running on your own compute fabric. So one single, you know, unified policy agent and control panel to control all of the different AI running in every, you know, all these different surfaces that AI can actually be used on.
Swapnil Bhartiya: Can you also talk about what goes into the runtime transcript that Classy creates and how does that turn into a chain of custody record that someone can actually use?
Poonacha Kongetira: That’s a really good question. You know, I can’t emphasize enough how important it is to actually collect all of the telemetry and you know, prompt. It’s not just prompts and responses. That’s how Jenny I started out originally. But you want to see prompts, you want to see responses, you want to see tool calls, you want to see local standard IO access, and you also want to be able to peek into Asian context and memory because that’s where the intent actually lives. What we are able to do through our sensor library is to acquire all this information. Even when an agentic workflow could start on your computer, go to Claude, from there, go to a hosted agent on your Kubernetes enterprise fabric and come back to the user. So that’s multi surface. To really understand the intent of the transaction, you have to be able to put together that multi agent transcript where you associate all of these different surfaces with one common workflow. We’ve been able to actually do that. It’s kind of hard. So not everybody has been able to do it, but we’ve been able to. Acquiring that information gives us the ability to make intent based decisions over a wider time span. Of course we can also do the simpler stuff that hey, you’ve typed in your Social Security number block that that’s immediate on a very transactional basis. But, but an agentic workflow today is actually made up of a multi turn conversation which can span many surfaces. And putting that together to determine what the intent is is super important, right? To like, you know, if you want to Determine whether an agent is off, is on the way to doing something bad, like breaking out of a sandbox. You can actually figure it out, right. If you’re actually thinking about things at the session level. So that’s kind of how we’ve approached the problem. Not just on a singular prompt response tool call basis, we do that, but also this transcript, which is a session transcript. And what is actually going on, what is the intent of it and can we do something before it’s too late?
Swapnil Bhartiya: Let’s not talk about the biggest elephant in the room, no pun intended, token cost. The whole tokenomics that we are talking about these days, how do you tie AI spend and token usage back to a specific person, agent or a session without having to dig through dashboards across every gateway?
Poonacha Kongetira: So again, you know, it’s sort of, it’s very interesting. So it ties back to two things. So one is collection of the transcript. If you’re collecting the transcript then you have a sense of like what your token, what the token usage for that thing is. So that’s number one number. The other thing is being able to plumb the identity of the person, agent, token which authorized that transaction and to relate it back to a human, an agent, a department, a project or a model. So we have actually established this attribution throughout the agentic workflow. And now what we are able to do is we are able to, on a up to the minute basis, be able to create a, we call it, you know, token iq. We are able to create this attribution of spend along all these different dimensions that I mentioned. People, model, project, department, et cetera. Right. And we aggregate that on an ongoing basis on a minute by minute level, so that you see what’s going on as it happens. I was just discussing a case like this that we were thinking that a customer was actually having where suddenly we noticed that the trace volume spiked. We don’t actually get to see what our customer is doing because we stock to and their data is their data. But we do see indicators when the tenant is actually hitting massive trace volume. And when we found this, we approached them and found that it was actually a single user that was actually causing this massive trace volume because of the type of data that they were having, the model chipmunk. Now something like that, if you tie an alert to it which says that if trace usage is spiking like this, send an alert back to the user, make sure you know what you’re doing, don’t spend a billion dollars, that kind of thing, it’s all sort of like, is this the right way to do this thing? You know, supervision in real time of both your spend as well as your actions.
Swapnil Bhartiya: You mentioned that you are using OPPA as the core policy engine. It’s an open source policy agent. Why open source and how much does it matter to you?
Poonacha Kongetira: So I think, you know, we definitely, you know, happy to participate, benefit from and contribute to open source. So I think we’d be fine with all of those things. We’re pretty young right now, so we haven’t taken a strong position one way or the other. But in general I think we all benefit from open source. And I think open source also has like a pretty high degree of quality because of the amount of review which actually goes into it.
Swapnil Bhartiya: Now let’s talk about continual learning infrastructure. Agents and AI models are increasingly learning from themselves and improving over time. Where should that continual learning infrastructure actually run? In customers on private cloud? Because we live in a hybrid world either way. So what is the ideal setup for truly continual learning infrastructure?
Poonacha Kongetira: I think the continual learning part of it is kind of interesting. So we have these supervisory agents and models which run on these transcripts that we collect so that we can come up with intent and detections and the right actions to, to provide supervision benefits for our customers. Now the approach we took is that this data that our models learned from actually belonged to the customer. I don’t think it really belongs to us. Right? So from that point of view, the way we built our infrastructure was that these models would be running locally on the customer tenant. Right? Class C basically exports a SaaS tenant which can also move on prem. That tenant has got all of the customer’s trace data as well as all of our models. And if our models learn from the customer data, then those updated weights become the property of the customer. That’s our viewpoint. And we think that that’s a fair viewpoint because then we’re not exfiltrating their proprietary know how and that belongs to the enterprise. So from that point of view, it’s been a kind of like a, a founding principle of us that that should belong that way. Now for their general functional use, right? They might be using frontier models, they may be using open source models in one way or the other. They may have indemnity from the model providers, they may have agreements or whatever it is, zero data retention. So there are different ways to solve the problem, which is to the comfort level of the enterprise, if you will. But from our perspective, we just took a simple position. We were like, this isn’t our data, we don’t want to beam it up. The reason that we want these models to learn on customer data is so that they can be more accurate for the customer. We’re not really interested in transferring that to other people. We let the customer have a clean, clean like we have a clean conscience. They have a good sense of understanding of what’s going on. So that’s how we left it.
Swapnil Bhartiya: Now you have three things. Discover, Analyze and Supervise. Can you walk us or talk about how do these three work together, why that order matters and how easy is this for the end customer? The whole observability cloud, native stack is already complex. So do these make things easier or add more layers, more things to maintain?
Poonacha Kongetira: I think it’s basically one platform. It’s your journey through the platform which is Discover, analyze, supervise, you know, so, so discover is find out what’s going on. Analyzes understand what, what people are doing with it and what those things are doing. And supervisors put the rules in place so that you can govern them. Right. But I do want to sort of, it’s another sort of like founding principle of this architecture is that what we found is that there’s usually a large number of tools which are trying to perform the supervisory function in enterprises. So you have a Genai prompt response tool, you have an endpoint tool which discovers agents and endpoint some other browser tool which is described on a browser or something else which a firewall which is man in the middle which is looking at data infiltration and trying to do dlp. And what we found is that you have different identity tool, you have something else. Something else, right. And what happens is that all of these different tools, they look at the problem in a particular way and when they collect data and detections they put it in a separate repo. There is no one unified data model that serves multi vendor data collection. In some cases you can say that, well, you can send everything off into a data lake or send everything off into Zillow too. Yes, you can send it all there, but you can’t piece it together. It’s a jigsaw, you can’t piece it together there. So the approach we took was to, you know, build this sort of this family of sensors which can see things at different points. And we put it into a common unified transcript, you know, accessed by this API which is a common fused data model of the entire transcript. And so if you can actually assemble the data in real time, then our models are actually great at figuring out intent in real time. And sometimes I Feel like data assembly is actually the long pole in most tooling and we’ve taken that data assembly out of the picture and we’ve made it assemblable in real time across the entire transcript, across sensitive data identity this, that and the other. Right. Put all the stuff together so that you can extract the intent, extract the hazards as it’s happening, otherwise you just can’t. Right.
Swapnil Bhartiya: Can you talk about what changes do teams feel when they turn on these discover, analyze of course supervise tools and they can actually look at their own ROI that now they are able to do things that they were not able to do yesterday.
Poonacha Kongetira: I think first thing is, you know, they actually are able to sort of like figure out what’s going on and then make that known to company management. I think finally, you know, decisions in a company are still made by people so far. And then but being able to show them a, you know, this is what’s going on in the enterprise can lead to the right I think governance conversation in management circles. I think in the C suite or the E suite or whatever it is. Ultimately I think, you know, enterprises have to come to terms with how they can use this extremely capable tool in a way which protects their customers data, their own ip, all of this stuff. Right. And often the enemy of that debate is not having any data to show that you can use to actually formulate a go forward position with. I think the most useful way that we can actually help influence this going forward is to be able to present the data of what is found but also to like we have models which actually do the summarization of what’s going on and report generation and all this stuff. Be able to put the data together in an actionable way that when people look at it they get a pattern and then they can decide on what to do and then we obviously have the controls to actually carry forward their decisions. But I think that’s really what most people need is like a coherent cohesive view of what’s going on so that they can decide what to do.
Swapnil Bhartiya: Last question before we wrap this up is that how is classy different from other observability or genai security tools? That market is flooded, it’s crowded, it’s tricky. A lot of organizations are already doing that. A lot of organizations only have tools in place. So how is classy different and how does it fit into your customers existing infrastructure?
Poonacha Kongetira: So I think how it fits into the existing infrastructure is, you know, people will have SIEM tools, they’ll have identity tools, they have so anything that we produce, it doesn’t have to be consumed only in our console or our platform. We integrate with all these things so that, you know, ultimately whatever we collect can go live in a splunk or a datadog or a SIEM system, which is, which is your favorite thing. So that from that point of view, you know, the look and feel of how we get consumed sort of fits into the existing security or DevOps or IT ops, you know, workflow in, in terms of how we’re different. I think the. I’ll sort of go back to the tool fragmentation thing, right, where you actually have data loss prevention tools, you have data lineage tracking tools, you have DSPM tools, you have browser security tools, you have tools of every sort which all, you know, try to solve or understand a multi agent, multi agent, multi surface workflow by looking at the thing that they have access to. And I think a lot of tools right in the space tend to fall into that design pattern. And I think with, especially with agentic workflows, right, what matters is access to the whole, not access to a fragment. A fragment will only give you so much information. And I think access to the whole is what you need to actually make the right thing. So I think that’s where we differ. We try to sort of understand this thing in a very holistic way. Multi surface, multi agent, multi framework, cloud. And it’s not just security, right? We’ve actually sort of married spend alerts, security alerts, everything together. And that’s what we call supervision. So we’ve taken a very broad view of it. It makes for a more, it makes for more work that we have to do. But ultimately I think it provides more value as well because the tool fragmentation is the enemy of real time supervision. You just can’t put Jigsaw together in time. And that’s where I think we differ.
Swapnil Bhartiya: Punachal, thank you so much for breaking this down and to our audience, if you want to see how classy supervises agents in real time, please check out Classy AI and Punacha. Back to you. Thank you for joining me today and I would love to have you back on the show.
Poonacha Kongetira: Thanks again, Swapnil. It’s been a delightful conversation. Thank you again for the opportunity and we’ll see you next time.





