Building an AI Guardian for Enterprise with Onyx Security CEO Maxim Bar Kogan

As you're exponentially doing more things with the AIs, you're going to start having really bad actions happen. We've seen some of that happen lately with agents accidentally publishing code and tokens that they weren't supposed to. Enterprises are starting to realize that that risk is growing exponentially and that they don't have any way to stop the adoption. They now have to do something to reduce the chance of these agent actions being illegitimate or incorrect.

We're allowed to look at a lot of historical data about how these agents have behaved. But enterprises today are not willing to have Anthropic or OpenAI keep that historical data because they know these are very data-hungry companies that will want to train on that data.

Hi listeners, welcome back to No Priors. Today I'm here with Maxim Bar Kogan, the co-founder and CEO of Onyx Security, an Israel-based startup of researchers, mathematicians, and engineers building agents to watch the AI agents. We talk about specialized model training, Mythos, alignment research, and the Israeli ecosystem in security and now AI. Welcome, Maxim. Thanks so much for doing this.

Thank you. Pleasure to be here.

Everyone is much more concerned about security and the impact of AI on security than they were a few months ago. The consensus risk story 2 years ago, when you started the company, was basically DLP for chatbots: What are employees putting into ChatGPT? Now we have clearly something that is not quite panic, but close to market-wide panic. How did you decide to bet on agent actions when you started?

Look, I think for us the pivotal point was AutoGPT. I think AutoGPT kind of let everyone's imagination, including ours, run wild.

Can you remind listeners what that was?

Sure. So, AutoGPT—and I'm sorry if I don't know the guy behind it, but I'm a huge, huge fan—they created the first, as far as I know, really autonomous agent running on LLMs. It was an agent that would let an LLM not generate text, but decide what to do, and then give that agent API access to do that thing—a tool to do it—and then do that in a loop. So it basically, in theory, could let agents do very complicated things, anything a person could do on a computer.

Granted, it didn't work that well. It was too early. The models were not good enough, and GPT-4 was not good enough. But I think it did give everyone a glimpse into the future: What if the models were good enough? Using that same structure, we could have very capable agents doing stuff for us.

I think in many ways Claude Code today is not dissimilar to AutoGPT back then. I think they were a bit early, before the models were ready, but the concept was right. The thought that stuck with me was that I was very AI-pilled even back then. I was thinking, “Oh my God, models are going to be way smarter than us when that happens. How do we oversee these very smart agents?”

They're smarter than us. They're very capable. How are we going to feel at ease about them doing stuff for us, especially when they start managing really important things? One day, they're managing your water supply, your electricity, your power grid, right? How do you control them? That was the thing I was obsessed about.

I was also too early. At the time, enterprises were not using any agents. There were hardly any agents out there. Talking with a lot of security folks at the time, they were like, “Oh, dude, you're way too early. This is not something that's going to happen.” So I said, “Is anyone going to do this before you run out of money?”

I think there was a good chance that I would have run out of money first, because I think there was an element of chance here. But then I think the market did happen. Suddenly, we had reasoning models that could do long-horizon tasks. We had Claude Code, which became the first really widely used autonomous agent, and then we had Claude Cowork and OpenClaw.

I think we're starting to see these types of agents that everyone was afraid to build. So everyone started building these low-code platforms that were much more limited and much more based on connectors. Those platforms ended up being quite limited, so we didn't get the productivity gains from them. But when we started getting the crazy benefits from these very unleashed agents that could do everything and had much fewer controls baked into them, even very large enterprises decided they were going to adopt them.

Anthropic's revenue is coming from enterprises that are paying for Claude Code to do a lot of the work that developers used to do. That was a bit about how we started, and we were definitely lucky that very autonomous agents appeared before it was too late.

Can you describe a little bit—because it's both close to impossible and then very useful in this period of AI to think about what deployment is right now and what's changing about capability? What's the one-liner on what the Onyx product does today, and how do you think about the long-term vision today?

Today, Onyx really does 2 things. Number 1 is that we train models and build agents that can oversee other agents. The goal is to say, “Okay, we need someone to be able to tell us whether all of these actions that are now happening by these AIs that we're adopting are legitimate,” because the number of these actions is growing exponentially.

Things that we thought might be useful in the past, like having a human in the loop, aren't going to work now that you're going to have 100 times, 1,000 times, or a million times as many of these actions.

Then we take that capability and productize it in a product that we call the control plane, or the secure control plane. We come to the enterprise and say, “Hey, let's find all of your AIs and autonomous agents and hook them up to Onyx, to this system where we can oversee what your AIs are doing.”

That way, you don't run into the risk that, as you're exponentially doing more things with the AIs, you're going to start having really bad actions happen. We've seen some of that happen lately with outages that were caused by agents just doing the wrong thing, agents accidentally publishing code and tokens that they weren't supposed to, and so on.

Enterprises are starting to realize that that risk is growing exponentially and that they don't have any way to stop the adoption. They now have to do something to reduce the chance of these agent actions being illegitimate or incorrect.

Yeah, I think one of the core reasons, obviously, the foundation model labs are going after code is because it is very powerful in general and can, in theory, do all things software can over time. The flip side of that is it can do all things software can, right?

Personally, I am already in the camp of having been overpermissive with my agents, such that they deleted data permanently and caused rework. So I'm like, “Oh, okay, I think I see. I need some guardian spirits around it.”

Given your deployments today and talking to large enterprises, what is the state of deployment? How much do you see that's within these more scoped, studio-like platforms versus free-ranging coding agents? How much are you actually seeing in large enterprises in different sectors?

Yeah. I think right now, in our typical enterprise, we see 3 categories. The first is various SaaS platforms that are typically more low-code, where people build agents in a drag-and-drop way. They're not really autonomous agents, right? They're kind of simple automations. I would think of them more as automations.

Then there are first-party agents people are building in their cloud, potentially because it's an application they want inside the company or even a product they're planning to release to customers that is agentic. The third category is very autonomous coding agents and assistants.

Of these categories, I would say that, roughly, at this point, over 50% are autonomous coding agents and assistants in the average enterprise. Probably 45% are those low-code automations, and the last 2% are really the first-party ones that they're building themselves, because obviously it's much harder to build effective agents. It's much easier to adopt agents off the shelf or build them with low-code.

We're seeing that the autonomous agents are also the fastest-growing category. It used to be that only developers used Claude Code, and we would see Claude Code growing like wildfire in our customer base. Now we're seeing Claude Cowork growing even faster.

We're starting to see, to our own surprise, people adopting OpenClaw as a legitimate, sanctioned tool in the company because the CEO is very driven to adopt AI. I think that today, autonomous agents are by far the fastest-growing category. They typically come without any controls today.

So enterprises already buy, let's say, $100 billion of security today. They have lots of different protections at the endpoint, network, cloud, and identity domains. What's relevant here for securing agents, or is none of it? How do you think about the existing protection set?

Security is always a space where you have some overlap between different tooling, but in this, you have the concept of defense in depth as well. So you want to have defenses at different levels of your technology stack to solve the problem.

And that said, I think in this space, a lot of enterprises are kind of helpless. Traditionally, if we have a software system that's running in our company, our first and most important control will be to limit what permissions it has, right? Because no matter what, even if it goes wrong, even if it's compromised, it can't typically do stuff that it wasn't originally allowed to do.

But with these autonomous AIs, with these assistants, with these coding agents, we kind of want them to have our permissions because we want to tell Claude Code or Claude Cowork to do something, then go have lunch and come back and see that it's done. We also want to give it so many diverse tasks that we kind of can't find the right set of permissions to do that. So suddenly, our identity security software is not very useful.

Then, if you think about endpoint security or API security, if we tell Claude Code that we want to recreate a database and it should delete it and recreate it, that's great. That's going to save our DevOps team and our platform teams a lot of time. It's a great benefit of Claude Code.

But if Claude Code is working on an unrelated task and suddenly thinks that maybe the right thing to do is to delete our database and recreate it, maybe we don't want that to happen. Unfortunately, our endpoint providers or API security tools don't know what Claude Code was thinking or why it was doing what it was doing, right?

A lot of these existing tools don't have the context to understand what these very flexible, unpredictable systems are doing. If you're not building some kind of controls that are built for these systems, then you're either going to end up limiting them a lot, making them much less useful to the enterprise, or you're going to miss a lot of pretty dangerous things that they might be doing.

As somebody who has worked in security for a long time, my first, very traditional instinct on a problem like this is: That sounds like a problem for a proxy with a policy engine. We make some rules, we make the rules smarter. Why doesn't that work, or did you try it?

There are a few things. A proxy is an integration method, I would say. There are some AI systems where you would want to integrate with a proxy if that's the easiest way to do it.

But, number 1, there are a lot of systems where that's just not technically viable, because AI today runs in the cloud, on someone else's infrastructure, or on your endpoint, and a proxy isn't always an option. The second thing is, okay, great, you're proxying, so you're seeing the data. You're seeing the data, but that's not the hard problem.

The hard problem is understanding what I should do now. It turns out that, in the case of AI systems, that's the hard question: What is the engine that needs to underwrite these different actions and say whether they're okay or not? We need to be able to understand what another system is thinking, what it is planning to do, and then have our own opinion on that.

And consider: We're trying to understand whether some of the smartest models in the world are doing the right thing. Who are we to do it? How are we going to do it correctly, right? And so that turns out to be a really difficult technical question.

Part of the solution for Onyx has been training its own models. What can you say about that?

If you tried today to build a solution to oversee and control how other agents are operating, maybe the first thing a lot of our listeners might think is, “Well, I’ll just ask Claude Code to do it.” In a sense, they would be right, because Claude Code is great. Maybe we can ask it to spawn a version of itself for every agent that we have, keep monitoring everything that agent starts to do, and intervene if it thinks there’s a problem.

That approach is obviously pretty naive, and there are some ways in which it totally fails that we could talk about, but it has some merit to it, right? It does seem intuitive that it’s a good idea to have capable agents reviewing what other agents are doing. It’s the same as having capable humans reviewing what other humans are doing, right?

But the problems that you’re going to run into are: How do I make this work from a cost, latency, and reliability perspective? Because if I need to run an agent for every agent you’re running as your security vendor, you’re going to be paying me more than you’re paying for your AI, right? So it’s pretty much a dealbreaker, and it’s also going to be so slow. You’re not going to be happy with whatever latency you’re going to get.

The challenge then becomes: How do I know when I need to interject with these smart agents to look at what’s happening? What you want to do is try to train models that are not very smart but are just good at one thing. They’re very small. They almost can’t do anything else other than say, “Should I have a smarter agent look at this?”

If you manage to bake that intuition into those small models—in the sense that they don’t miss a lot of stuff and they don’t call that other agent too much—then you can get to a really good balance. We’re very performant, we have smart agents overseeing things when needed, and our costs and latency are low.

Then that becomes the challenge, because you need to make sure that as the frontier models get smarter and the hard cases become more involved, you have models on your side that are small and effective at continuously being able to say, “Now is the time. This is the action where I think someone should take a closer look.”

That’s why Onyx trains models for this purpose, and most of the hard things that we’re doing are in this space.

You and I actually both love to play blitz chess, and I look at Guardian as a system that’s a little bit analogous. It’s not clear either of us is going to be competitive with Magnus in a real game. But if you play enough games with the right data, and all you have to do is make intuitive decisions under time pressure very, very quickly, it’s actually a different game, right? Do you think that makes sense, or am I reaching here?

Yeah, I hadn’t thought about it, but there are a lot of analogies. If you look at the top chess players in the world, most of the moves that they make are intuitive. They don’t calculate forward. They’ve seen so many games and played so many games that they already have a good sense of what the right move is, and that they’re not taking too much risk by making this move without calculating.

Then, if you look at those games, every once in a while they do stop for a really long period of time to calculate forward through a lot of options, because they know this is a critical move in the game. There’s risk. You need to think through what you’re doing, and you need to decide correctly.

I think that’s very similar. It’s the efficient way to run computation, right? You don’t want to spend too much intelligence where you don’t have to, and you want to spend overwhelmingly a lot of intelligence in situations where there’s high risk.

You guys are a team mostly based in Israel today. I think the world has accepted that there is a cohort of amazing Israeli security talent that comes out of the military and offensive security, and then you have repeat entrepreneurs like you guys.

I think the DNA at Onyx is a little bit different here. Your co-founder Gil came out of building synthetic data and working at NVIDIA. How would you characterize what the talent at Onyx is particularly good at? And are people actually training interesting frontier models in Israel now?

First of all, I think Israel maybe started a bit late in the game but is catching up quickly. There are now amazing companies in Israel building world models, building AI infrastructure that’s top of its class, and building chips. I think Israel in general is becoming very strong in AI, and we’re proud to be a part of that movement.

I think you’re right. Our company has a very mixed DNA between cyber and AI, which kind of reflects mine and Gil’s backgrounds. Most of the people in our company, particularly in research and engineering, come from a unit in the Israeli intelligence service where we actually deal with math and cyber and the intersection thereof. I think it is also reflected in the type of talent that we bring in.

I think it’s important for a few reasons. First and foremost, we want to be more than just a security company long term. We think that to solve this problem well, it’s going to require deep AI expertise, but the problem is not just cybersecurity. The problem is: How do we control advanced AI long term?

That problem, even if you just forget about enterprise security and the different gaps in the various controls that they currently have, from first principles, just sounds very important to me. I think it will be crucially important if you have AI companies that are $10 trillion companies. We think you want a company that is not the vendor of the AI itself to oversee and help you control what AI is doing.

And we think that’s an opening that’s a $100 billion-plus opening for a really important company. If you think about what it’s going to take to control advanced AI long term, then we’re just scratching the surface, because long term you’re going to have to also understand much better what models are thinking, what’s happening in the internals of these models as they’re operating.

So the industry is quite divided on this issue. I mean, amongst the people who think about whether or not mechanistic interpretability, or research into better understanding models, is possible, that's a question. It's something you believe in.

We believe that there's been a lot of strong progress in that direction. We believe that understanding the internal weights and activations—what the internal structure is, the mathematical structure of these systems—is going to be at least part of the solution. In many ways, we think that—and maybe we'll only know when we get there—but for our level of intelligence, it's kind of difficult to understand very quickly what the internal structure of a large language model is.

You mean our level, like human intelligence, or our level of your model? Okay, human intelligence.

Oh, yeah, exactly. I think as humans, it might still be very difficult to understand what weights and activations mean, and maybe mechanistic interpretability seems like it’s too hard or shouldn’t be possible. But as we're starting to have models that are much smarter than us, at least in some important ways, we think that we'll be able to start cracking mechanistic interpretability much more effectively.

I think it's going to be extremely rewarding, by the way, long term, for understanding intelligence in general—not just overseeing it, but just understanding what intelligence is, how it works, and what's the difference between the smarter model and the less smart model.

I completely agree that the opportunity to understand, trust, secure, and govern these superintelligent AIs is a very large opportunity. The security person in me says, “Well, then I have to give you all the permissions and understanding that I have to give these companies, too.” How do you get customers—the Fortune 100s you're working with already, or tech executives—to trust you now as a company with fewer than 100 people? Everybody cares about their own security and business.

Right. I think it's one of those things that should not be possible. In theory, there's no reason why a Fortune 10 or 20 company would work with us because, you know, who are we? We're a 2-year-old company, or a few people from Palo Alto Networks, Mandiant, and Cybereason.

But I think it's an opening that only happens when the pain is very strong. Their pain is so strong that they're going to say, “Oh my God, I just saw this company come out of stealth, but it's a problem that I have daily, so I'll give them a call.” Suddenly, you get inbound from these large customers, which is, of course, the best thing you could hope for as an entrepreneur.

I think it reflects, in my opinion, their understanding that a lot of the startups in this space are still small and new, but there's going to be a huge company here, and we want to find the right horse to bet on. We're going to take a look at these companies. And, number 2, if we don't do anything, then in a very short time this will disable our business.

At the end of the day, security people are in the business of revenue preservation. They understand that this is a bet between the two risks. They want to partner with someone that's promising and early rather than not doing anything.

The other thing, besides agent actions across their surface area, that every CISO I know is freaking out about—and every engineering leader is freaking out about—is what I would describe as the plummeting cost of vulnerability finding with these coding tools.

Yes. And that has caused a number of issues for vendors that are being compromised. How do you think people should react to this other issue?

I think Mythos is really—if you had asked me 10 years ago, automated vulnerability research looked like a dream that would take 20 to 50 years to happen. Maybe it's because we were doing a lot of that in Israeli intelligence and we liked to pat ourselves on the back about how difficult the job was, but it did look really far away, and suddenly it's coming all at once.

First of all, I think the market is not overreacting. I think this is a huge change in what this means for security teams. If you're a pragmatic security person today, you understand that you need to move very quickly. Your strategy might look something like: “I need to do the fastest, quickest fixes I can to mitigate the immediate risk.” So maybe I'll invest in the vulnerabilities that have been found. Let's try to mitigate them, whether it is through patching or through mitigating controls.

But then the real solution—and every security leader at a large enterprise knows it—is that we need to have the foundational pieces in place to avoid those risks. The foundational pieces are that we need to have identities locked down, we need to have a firewall, and we need to have endpoint detection.

For different asset classes in your enterprise, for different parts of your stack, there's a different foundational security mechanism that you need in place. For the AI attack surface that you now have, or for the AIs in your company, you also need foundational security. That's kind of the role we play in that space.

As part of your preparation for Mythos-level models and beyond, you're going to need a lot of foundational security tools to fortify the different parts of the enterprise, and we're playing that part in the AI space.

Do you have a point of view on the phased rollout or controlled rollout with Claude Code and Codex from Anthropic and OpenAI in this area?

I don't have a strong opinion, but I think, on the one hand, if we knew that there wasn't going to be anyone who would release a Mythos-level model soon, I think that would be great because it gives us enough time to prepare, build the know-how, build the playbooks, share that around in the community, and make sure that we're not starting to see airlines go down and power plants go down, with really disastrous effects that could happen.

The problem is that if anyone gets to a Mythos-level model earlier, then in retrospect it would look like a huge mistake, because we could have at least given companies the choice to start moving very quickly and give more companies access to Mythos. Now they're all vulnerable because, you know, there's a Chinese model that's Mythos-level and there's nothing they can do about it.

Hopefully, we'll manage to do the gradual rollout correctly. I would really encourage us to expand the number of companies that get access to this and make it much easier for people to get. I would advise everyone to assume that these models are coming anyway. The only thing you can do right now is invest in the foundational controls that will stop the downstream effects of the vulnerabilities that are going to be found in their systems.

Do you see any holdouts in large enterprises? I actually haven't spent a bunch of time talking to people about this recently, but I remember that a year and a half or 2 years ago, there were large companies that just said, “We're going to ban all of this stuff until it's safe.”

Yeah, I hardly see it anymore. In the financial sector, there are some companies that are more opinionated about what they allow. They still allow agents, but they're maybe more granular about it: “Maybe we're only going to allow these 2 tools.”

I personally think that the companies that are going to do well are the companies that are going to allow a lot of different tools because the landscape is changing so quickly. If you bet on OpenAI a year ago, that would have been the safest bet in the world, but suddenly Anthropic has much better models and better tools, and potentially a year from now someone else will have much better tools.

I think there's a price to pay. But I think if you're a large company, your risk profile is—and should be—different. When you're a startup, you want to have your agents do everything for you because you have everything to gain and nothing to lose. Whereas when you're large, like JPMorgan, you have so much to lose, and you can maybe take a bit more time to gain what you can gain from AI.

By the way, JPMorgan is adopting AI very quickly. I think it is okay for companies to have a more nuanced view, the bigger they are, of how they're adopting AI.

How do you think about that question for yourself—risk profile and pace? The environment is changing very quickly, and you see a lot of problems growing. The scope of the product and the research thesis here is already quite large.

We are kind of in luck in the AI security space because, yes, there are a lot of vendors and a lot of new technologies that are coming up, but the 2 core pillars of how 2026 AI works have not changed in the last few years.

We're still largely using LLM foundation models that are not entirely dissimilar to how they were a few years back. And we're still building agents in pretty much the same way, where we have an LLM decide what tool calls we're going to make and generate those.

That does allow a company today like us to skate to a lot of different applications that are utilizing these 2 primitives while still keeping the core technology that we're developing fairly lean and focused. Now, of course, there's always a risk that tomorrow there will be a completely new LLM paradigm, or a completely new agent paradigm, that could happen.

And that's why we do try to have strong opinions, loosely held, about what that looks like in 2027. We maybe have a good picture for 2026, but for 2027, we're very open-minded, and we think that's the right stance to take for the next 2 years until we see what AGI/ASI looks like.

Do you see the set of problems you're addressing—trust in the models and governance of them—as something that the labs could ever do, or do you think it's a structural thing? I ask because the number-one question among the startup ecosystem in the Bay Area today is: if you assume capability improves, or when the labs just get hungrier from their already ambitious stance, why wouldn't they do this too? I ask you the same question.

Today, if you're a private person or if you're a security buyer, there are some places where you don't want to trust the same person you're buying it from. If you're buying a car, you're not going to have the same guy you're buying it from certify that the car is good, right? You're maybe going to have someone else do it. If you're a security team, you're not going to trust the vendor of a product to tell you that this product is not going to mess up your environment. You're going to want to have an independent party whose whole business depends on telling you that this thing is correct, that this thing is legitimate, and on being right.

So that's the buyer psychology in the space that I think really goes in our favor. Then I think there are the core problems: why are models even making mistakes? Why are agents even making mistakes? I would broadly categorize it into 2 things. One is the jagged intelligence of these models, and there are sometimes very silly mistakes that they make. I think that problem will go away. I think we're heading for much smarter models that make fewer silly mistakes, and our role is not going to be to prevent silly mistakes. That will be taken care of by the model vendors because they're very incentivized to do it.

I think the other fast-growing category of things that we're seeing models do wrong is in places where they're actually not making a thing that is a silly mistake, but more, I would say, have an independent—you might even say semiaware or semiconscious—perspective on what should happen, and that perspective might not always align with your perspective. And I think that is a problem that we've seen grow hand in hand with models getting smarter. Maybe that's just the way it is: as you get smarter, you have more independent thoughts, and you're more conscious. I think that problem is actually seemingly very hard to tackle today, even for the large vendors.

And one of the key things that makes it easier for us to understand and detect these things versus the other vendors is that we're allowed to do certain things that they're not. For example, we're allowed to look at a lot of historical data on how these agents have behaved. But enterprises today are not willing to have Anthropic or OpenAI give them that historical data because they know these are very data-hungry companies that will want to train on that data.

And so I think there are some ways in which we're given more context and more latitude to know if something is happening that is wrong compared to the past, compared to how these agents typically behave, and so on—context and latitude that the vendors don't have—and that's really important in solving this problem.

And the last thing I'll say is that you're not dealing with 1 vendor. We're heading for a world where there's a multitude of different vendors for many reasons. You're going to have open-source models that people are going to use for cost reasons because they're cheaper, and you're going to have models that are better at different tasks and at different cost profiles. So it's going to be unrealistic to expect all the vendors to provide the same level of security and to assume that technology you're trying to adopt very quickly—especially when it comes from new vendors that obviously have not yet built all of that out—will have that same level of security. I think these are the reasons why I think it would be very difficult for this problem to be completely solved by the large labs.

Just to close, and also thinking about what people in Silicon Valley or outside of security may not know, you're building this from Tel Aviv, right? I think one of the deepest adversarial-thinking benches in the world is the Israeli ecosystem: Unit 8200, Wiz, Armis, Island, NSO Group, right? What do you think researchers, engineers, and businesspeople in the tech ecosystem outside of security—and in the labs in particular—are missing about what needs to happen in security and alignment, which is what you're talking about here?

What's really important when you're building security products in general—and I think what people in Israel have really good knowledge of—is just understanding how security teams work. Because at the end of the day, no matter what the technical problem you're solving is, you're building a tool for people, for an organization. That organization has a certain structure, certain teams, and a certain flow of responsibilities and information, and creating a product for this audience that doesn't just solve the technical problem but that they actually love is really hard.

You need to really care about the day-to-day of these different functions, and you need to have people in your ecosystem who have built products for them in the past, who know them like they know their best friend—who know what they do when they step into the office in the morning and drink their coffee. What systems are they opening? What does their boss want from them? What do their colleagues want from them? What are they going to get praised for? What are they going to get mad about? Then you need to take that and make it your product.

And I think that's one of the really hard things that people in Israel have learned to do, because they've had so much contact with these buyers and end users. I would just encourage people to be much more curious about the day-to-day of security people. It's a cliché to say it, but these people are actually saving us daily from attackers stealing our money and taking our data, and they're keeping our way of life as it is in this digital world. So, yeah, I think more love to security teams around the world.

I'm going to ask you to square that with something else you've told me, Maxim, which is that you're the most AGI-pilled person I'm going to meet in Israel. Embedded in what you said is a belief that we will continue to have defensive security teams for some number of years. So you do believe that?

I do think that security teams are also going to become completely AI-powered, but I do think that they're going to be run by AI agents, like everything else in the knowledge-work space, in the near future. But I do think that it's important to be grounded in today. When I sell a product, I sell it to a human audience with a few agents. By the way, we also invest in making our systems very convenient for agents to use, and it's important that I focus on delivering an amazing experience today for people who buy the product today.

As that audience becomes more agents than humans, it will be important for us to evolve and make it work really well for agents doing the work. So I think the core principle is the same: we need to really be mindful of who the end user is and what their experience is. For a human, it might be not overwhelming them with too much information that is irrelevant. For an agent, it might be not wasting too many tokens in their context when we talk to them. Maybe it's really the same thing. I think it's important that we always remind ourselves who's using the system and what will be the best experience for them.

Awesome. Thanks so much for doing this, Maxim.

Appreciate it. Thank you very much.

Find us on Twitter at no prior pod. Subscribe to our YouTube channel if you want to see our faces. Follow the show on Apple Podcasts, Spotify, or wherever you listen. That way, you get a new episode every week. And sign up for emails or find transcripts for every episode at no-briers.com.