Every IT organization runs on tickets. A developer needs a database, a business user needs the logs, someone wants to know why the application is slow, and each request waits in a queue until a DevOps engineer picks it up. Venkat Thiruvengadam has spent years building a company around the idea that the request doesn’t have to wait, and on this episode he described where that ends up in one sentence.
“So the idea is that the users have the same experience, they go to a help desk ticket, but in this case they are not assigning a ticket to a human being, they are assigning a ticket to an AI agent.”
Venkat Thiruvengadam, at 10:08
Venkat is the founder and chief executive of DuploCloud, which he started in January 2018 and which is based in San Jose (LinkedIn). Its homepage now calls it “The DevOps Agent Platform.” Before DuploCloud he spent 2005 to 2013 at Microsoft, where his LinkedIn says he was one of the two founders of the Windows Azure Networking team in 2008, then worked on the controller for Cisco’s ACI at Insieme Networks and on infrastructure automation at Zenefits (LinkedIn). In November 2023 DuploCloud raised a $32 million Series B led by WestBridge Capital and StepStone Group, with Mayfield, for $49.5 million in total (TechCrunch). On this episode he tells me why the ticket queue exists, what an agent needs before it touches production, why DuploCloud gives its agents away, and what he’d pay someone to build.
Where we sit, so you can weigh what follows: YSecurity helps startups pass the security and compliance reviews enterprise buyers run, from the first questionnaire to SOC 2 and ISO 42001. In the split Venkat draws in this episode, that puts us next to the evidence and the auditor, working with founders whose DevOps engineers carry the controls underneath. I hosted this one on my own. By Venkat’s count of seven and a half years at DuploCloud, we recorded around the middle of 2025, and the episode aired on January 27, 2026.
An accidental entrepreneur
I asked what inspired the journey, and Venkat started by saying he hadn’t planned one. “I’m an accidental entrepreneur. So I didn’t really set out to build a company. I’m a developer by background.” He was working for a much larger company after his time at Microsoft and decided to write some software of his own.
“My goal was to build a software, maybe sell to about like four or five people, five companies, and then make as much as I would make in my job, and then sort of like go from there.”
Venkat Thiruvengadam, at 2:12
Then more people wanted the software than the plan allowed for. “The Valley’s ecosystem comes and finds you and then pushes you towards entrepreneurship quite naturally.” He found advisors, mentors and investors, the business kept growing, and “here we are.” I asked if he was a solo founder. Not at first: “I had a friend of mine who helped me bootstrap the company in the first few years, like for the first two or three years,” a friend who “gave me a lot of introductions, helped really get this off the ground.” After that, “since maybe for the last five, six years, I’ve largely been on my own.”
The resume behind the accident is a networking one. His LinkedIn starts with Siemens in Gurugram in 2001 and research on an IP multicast tunneling protocol at the Illinois Institute of Technology, then Microsoft from 2005 to 2013, Insieme Networks from 2013, where he worked on the software-defined networking controller for Cisco’s ACI, and Zenefits from 2015 as a principal engineer on infrastructure automation for microservices. DuploCloud’s about page says that as an early engineer on Azure he wrote “significant parts of the compute and network controller stack” (DuploCloud).
One engineer, 50,000 workloads
I read the DuploCloud website aloud for listeners, “AI-powered DevOps built for today’s engineering teams,” and guessed he’d built it because he kept running into the same problem at Microsoft. “That’s right,” he said, and went back to the beginning. “I joined Microsoft straight out of college. So I joined this research group as a software developer there. And then that research group went on to become Azure.” Back then it was on-prem, and the cloud started with about 100 servers in Redmond.
“And then, before I knew, by 2013, it had already grown to like 5 million virtual machines or something like that.”
Venkat Thiruvengadam, at 3:48
Microsoft introduced Azure at its Professional Developers Conference in October 2008, under the code name Project Red Dog, launched it as Windows Azure in February 2010 and renamed it Microsoft Azure in 2014 (Wikipedia). Venkat watched that growth from the inside, and what stayed with him wasn’t the size. It was how few people ran it. “With a handful of people, these big enterprises manage millions of workloads with latest and greatest of security and compliance across the globe.” He got used to it: “I’m like, yeah, one engineer, 50,000 workloads, like such a large infrastructure, this is a norm, this is how life is.”
Then he moved to the Bay Area and saw the ratio everyone else lives with.
“But then when I came to the Valley, that’s when I realized that in mainstream IT, it’s like every 15, 20 engineers, you’ll find another DevOps person who’s operating an infrastructure.”
Venkat Thiruvengadam, at 4:23
“Security compliance takes like months, if not years,” he added, and that’s where the company came from: “I think there’s a interesting problem to solve, based on what we have learned before. Why don’t we actually do a software for it and try to make a difference?” He gave TechCrunch the same comparison in 2023: Amazon and Azure run millions of workloads with about a thousand engineers, while “in an average enterprise every 50-odd servers require at least one engineer” (TechCrunch).
A techno-commercial person
I asked whether he thinks of himself as a security person. “I think of myself as a techno-commercial person. This is a term that a good friend of mine uses. So I’m a technical person who can basically put a technology for a good commercial use.” That use, for him, is DevOps, security and compliance. He was candid about the depth: “I wouldn’t say that I’m necessarily that deep down, dealing with security algorithms and RSA and the DH, Diffie-Hellman group and stuff like that. I’m not at that level.” His way into security was networking.
“I understand security pretty well because my background is networking.”
Venkat Thiruvengadam, at 6:08
For much of the industry’s history, he said, security lived in the network, with firewalls and flows. “Back then it used to be like Palo Alto, Cisco, and so on, where you would basically put a box and just send all the flows there.” His team in the cloud took the other road: “Then we moved it to host-based security with security groups and distributed ways of doing security.” He counts that as something he “substantially contributed to, and now it’s become a standard, like distributed security and so forth.”
His customers pulled him toward compliance. “I would say 97% of our customers are in a regulated industry.” And he drew a distinction I hear from founders all the time, in the words of someone who sells to them.
“Security is like never-ending. You can do as much as you like and it may never end. But compliance is more like, okay, there are certain guidelines, you need to meet them, and then you sort of like, people feel comfortable.”
Venkat Thiruvengadam, at 7:04
That’s a useful way to explain the difference to a board. Security has no finish line. A compliance framework like SOC 2 has a defined set of criteria, an auditor who checks them and a report at the end, which is why it’s the thing enterprise buyers ask for first. We wrote what SOC 2 is and who it’s for for founders meeting it for the first time.
Your Vanta goes green
I’d noticed DuploCloud’s own SOC 2 Type 2 on its website and asked how it works with the standard governance, risk and compliance (GRC) tools, “like the Vantas and the Dratas and the Secureframes and all of that stuff.” His answer is the cleanest division of labor I’ve heard for an audit.
“I think the way I would say the value is distributed is that they’re a GRC tool whose job is to collect evidence and pipe it to the auditor so that they can do their audit. And our job is to implement those controls, right?”
Venkat Thiruvengadam, at 7:48
He has “a couple hundred customers, and almost every customer has some GRC tool.” The pitch follows from the split: “If you use DuploCloud, then your Vanta goes green, or your Drata goes green, and then you can get all the evidences and so on.” In his words, “We are the DevOps engineer equivalent, while they are more closer to the auditor.” I put it as DuploCloud being “a little bit closer to where the rubber actually hits the road,” and he agreed: “Yeah, that’s right. If we do our job, that means you have your evidences.”
Today DuploCloud’s security and compliance page lists controls for SOC 2, HIPAA, PCI-DSS, NIST, ISO, HITRUST and FedRAMP, and describes a compliance agent that scans for drift and “generates real-time evidence” mapped to those frameworks (DuploCloud).
From where we sit, this split is the part founders most often get wrong. A GRC dashboard shows whether a control passes. It doesn’t configure the control. Teams buy the tool, connect their cloud, watch the dashboard light up red, and discover that someone still has to turn on encryption, write the access reviews and fix the logging. Whoever does that work, a DevOps engineer, a platform like DuploCloud or a team like ours, is the work the auditor ends up testing. Our guide to how long a SOC 2 audit takes walks through where the time actually goes.
The ticket trap
Then I asked him to explain how DuploCloud speeds up DevOps itself, and he started with how the work arrives today.
“So what they would tend to do is that they would tend to write a ticket, be it in Jira, ServiceNow, and so on, and describe the problem.”
Venkat Thiruvengadam, at 9:04
The requests are the everyday ones, “deploy a microservice, or help me debug this particular issue, or show me the logs, or I want to build out a new application stack, and so forth, give me a database.” A DevOps engineer picks up the ticket, solves it in the infrastructure and updates it. The engineers do have automation, “but that automation is largely for their use, right? So they are the consumers of that automation.” Some of it reaches users as self-service, “like GitHub Actions and CI/CD pipelines and stuff. But a lot of it is based on tickets, right?” And the queue never empties: “you go to any organization, any IT organization, they are like inundated by the number of tickets, right? I mean, ServiceNow is a huge business, Jira is a huge business, and so on.”
His answer keeps the experience and changes who answers.
“They describe their problem, and the agent synchronously, in real time, solves the problem right then and there in a fully conversational interface.”
Venkat Thiruvengadam, at 10:19
The back and forth that used to happen between a developer and a DevOps engineer over hours or days happens in the conversation. “So that’s sort of the dream,” he said.
From scripts to agents
The natural next question is what happens to the DevOps team, and Venkat answered it himself. “So now what role does a DevOps team play in this particular case? Their role is to sort of build those agents.” DuploCloud ships agents for common use cases, “but after all, they are the subject matter expertise of their own infrastructure, they have their own customizations and so on.”
“So the DevOps teams sort of, so to speak, graduate from writing scripts to building AI agents.”
Venkat Thiruvengadam, at 11:06
“And then AI fortunately allows us to build a lot of solutions very quickly,” he added. It’s a familiar move in our own work, too. The engineers who know an infrastructure best are the ones who should write down how it works, and an agent is one more place to write it down, with the difference that it runs.
The orchestration underneath
So what does the DuploCloud platform do, if the agents belong to the customer? “DuploCloud platform, in simplest term, makes it very easy. It provides a lot of orchestration in order to do that.” Then he listed the questions an agent can’t answer for itself.
“Like, okay, who is the user who’s calling? How do you authenticate? You know, how do you pass context to the agent? Which environment are they talking about?”
Venkat Thiruvengadam, at 11:26
A user says, “hey, tell me why is my application slow,” and the agent has to work out which environment that application runs in, get access to it and decide what tokens it can use. “Is it just in time?” Then the request changes shape, “from wanting to look at the logs to maybe rebooting something else,” and the agent needs “all those drivers and API calls to make to Kubernetes and cloud providers and so on.” His summary of the product: “So there is a rather thick orchestration, which is, so to speak, tying the pieces together. And that’s what we provide.”
Every one of those questions is also an access control question. Who is asking decides what the agent may see. Which environment decides what it may touch. Just-in-time tokens decide how long it may touch it. When we review agents for customers, those are the first three things we check, and our credential inventory for AI agents is a 30-minute way to answer them for your own.
There is no SaaS
I raised the worry I hear most from founders and security teams about agents in production, “I don’t wanna call it hesitation, but maybe like caution,” and the questions that come with it: can I run this on-prem, and how do I make sure the agent doesn’t do anything by accident? Venkat called it the core of the job. “First is that, I mean, that’s our bread and butter. That’s our job, to make sure that the agents work, they are safe, they’re reliable, they don’t do bad things, right?”
His first answer was where the software runs.
“You know, even before AI, coincidentally, our software was always on-prem.”
Venkat Thiruvengadam, at 13:00
“So this software always ran in customers’ cloud accounts,” he said. “So there’s no SaaS,” I said, and he confirmed it: “There’s no SaaS. Exactly.” The reason was the customers he started with. “Because we were already dealing with very sensitive infrastructure. So that problem sort of like goes away. We never had that problem to start with.” TechCrunch described it the same way in 2023, installed in a customer’s cloud account and reached through a portal or an API. For a buyer that matters more than it sounds. When the platform and its agents run inside your own account, your network boundaries, your logs and your cloud provider’s controls apply to them, and the vendor questionnaire gets shorter.
Read-only is where most stop
His second answer was the part DuploCloud counts as its own. “Second thing is that one of the value additions and the IP that we have built in is that, like, how do you safely bring human in the loop?” Most of the field, by his account, never gets that far.
“And a lot of these AI SRE platforms, because of this specific problem of safety, they end up limiting themselves to read-only use cases.”
Venkat Thiruvengadam, at 13:32
An AI SRE tool, short for site reliability engineering, is an agent that watches production and helps when something breaks. Reading logs and dashboards is safe, so that’s where most of them stay. DuploCloud started from the other end. “But we, I mean, like historically, have always thrived in provisioning, write use cases and so on. So it was rather natural for us to build a workflow and a human-in-the-loop experience, wherein people can enable agents to do a lot more.”
This is the question we hear most from security teams evaluating agents, and it’s the one we wrote up in are you actually going to give the agent write access? The tickets that clog a queue are the write ones: create the database, deploy the service, change the config. An agent that can only read can explain the problem and hand the ticket back. An agent that can write, with a person approving each change, can close it.
The IP is the framework
Then I asked about the models. “So what about the LLMs? So the LLMs are driving the agents, and they’re kind of the brains behind it. Do they run on-prem, too?” “Everything, right? And in fact, everything runs on-prem,” Venkat said, and when I asked about an open model like Llama 3, which Meta released in April 2024 (Wikipedia), he said the choice is the customer’s. “Yeah, I mean, it’s up to them what LLM they want to use.”
“In fact, I would basically say our IP is not in our agents, basically, right? We give the agent for free, we give away the code for the agent.”
Venkat Thiruvengadam, at 14:18
“They can change the models. We give them hooks to change the model.” What DuploCloud keeps is everything around the model: “Our IP is in the vertical integration and the framework that they would use the agents, or they would build the agents. And this is something which is very custom and specialized for DevOps.” He sees the same shape in the AI coding tools, “like Cursor, Windsurf,” which he calls vertical integrations for software development, and in a car.
“Tesla is a vertical AI application for transportation, right? Self-driving cars, for example. So what is special about Tesla, for example? It’s not just the AI and the model.”
Venkat Thiruvengadam, at 14:59
It’s “how it integrates with navigation, with the brakes, with the accelerator, with the engine, with the doors, and parking and signals and so on, right?” The sensors that tell a red signal from a green one aren’t the model either. “Similarly, if you take Cursor, how do they generate PRs? How do they generate commands and so on, right?”
A reasoning engine, not a product
He finished the thought with the line I’d put on the wall of any team building with AI.
“AI is a reasoning engine that drives all this, but you have to do all these things also.”
Venkat Thiruvengadam, at 15:33
“And that’s what I’m trying to say, is that we can use any reasoning engine that you would like, but we are really like the framework around it.” I tried to say it back: “I think what you’re saying is AI is a tool, not a product. AI itself doesn’t actually solve anything.” He finished my sentence. “By itself. It’s not going to like make an API call. It’s not going to take you from, drive your car, or it’s not going to write code for you.” The model tells you what to do. The framework does it, with the permissions, the context and the approvals the work needs.
From a security point of view this is good news. If the model is swappable, the controls can’t live in the model. They live in the layer you own: who can call the agent, what it can reach, what needs a person’s approval and what gets logged. That’s also the layer an auditor can test, and the one we review when a buyer asks how a startup governs its agents. Our post on least privilege for agentic AI covers how to scope it.
The internet was not the bubble
I asked whether there’s a big misconception around all the hype. “I think what I probably believe is that those, like, outlandish applications of AI, they’re not as close as people make it out to be, potentially. But it’s also not as far as the pessimists believe they are. So I would say the answer is somewhere in the middle.” The money was a separate question for him: “Whether the economy around it is sustainable, is it fair? That’s a very broader question.”
“Is it the 0% interest that we’ve lived for the last 15 years? Is it that? Or is it actually real GDP, that we sold stuff and then we made that money?”
Venkat Thiruvengadam, at 17:02
“All of a sudden, these businesses have gone from a few hundred billion dollars to like several trillions of dollars,” he said. “But I think it’s a giant bubble,” I said. His answer was the most useful framing of the bubble question I’ve heard on the show.
“I mean, dot-com was the bubble, right? But it was the dot-com part that was the bubble. SaaS was not a bubble. Internet was not a bubble.”
Venkat Thiruvengadam, at 17:20
In his reading, the models are this decade’s internet. “And people started building all these dot-coms, which really had no differentiator, and then that was a bubble, and a lot of people are building such AI applications.” What lasted was what came next: “But what came out of the bubble was real SaaS software, which became the standard for the next 20 years, for example. So I think we will come out of this with real AI applications, which would be the future for the next few decades.” Is there an intermediate bubble on the way? “I don’t know. Maybe.”
The record behind the analogy: the dot-com bubble peaked on March 10, 2000, and the Nasdaq Composite fell 78% from that peak by October 2002, giving up all its gains from the boom (Wikipedia).
“That’s really elegantly put,” I said. He added the economics in six words, “When money is cheap, bubble forms,” and I described what that looks like from the investor’s side: people who “catch wind of like AI, and they can see a demo with ChatGPT,” decide they have to get in, and all decide it at once. Then I made the point founders feel every month, that “it’s actually quite difficult to build an AI product or an AI service that operates in the green, right?”
“We as engineers, or maybe entrepreneurs, I think our job is to deliver the best possible value with the best possible technology, and potentially disrupt things.”
Venkat Thiruvengadam, at 19:06
“I think that part, I have no doubt,” he said of the costs. What a company sells for, he said, “depends on the time in the market.” An amazing technology can sell for a low price in a downturn, and a so-so one for five or ten times more at the peak. “So I think as engineers, what we can control is the product and then the value that we deliver.”
The iPhone before the iPhone
Timing reminded me of a film. “If you haven’t seen the documentary on General Magic, like, it’s the story of the iPhone before the iPhone was the thing.” Anyone who looks at its blueprints or its demo, I said, would call it “pretty much an iPhone, but it was long before its time. It was just way too early. Spoiler alert, I guess, you know.”
General Magic was founded in Mountain View in May 1990 by Bill Atkinson, Andy Hertzfeld and Marc Porat, developed precursors to USB, software modems, small touchscreens and multimedia email, and went out of business in September 2002. The documentary opened at the Tribeca Film Festival on April 20, 2018 (Wikipedia). It’s the cleanest example I know of Venkat’s point about timing: the right product, years too early, can sell for very little.
Good days, okay days and the other kind
I asked about the proudest day of his journey with DuploCloud. “I think, I don’t know if there is any one day per se. I mean, there are like ups and downs, so to speak.” People imagine founders getting up every morning thrilled, he said. “But no, that’s not how it works.” You get up and wonder whether it’ll be a bad day, an okay day or a great day, and over the years he’s had all three.
The good ones are specific. A round of funding: “I mean, it’s a validation that a lot of smart people are excited, they believe in you, and so on.” Revenue milestones: “for example, 1 million, 5 million, 10 million, 15 million, like these are all like very interesting milestones.” The team, which is remote, getting together: “We get together once a year in US and once a year in Asia, around India someplace.” The size of it: “So then you see that, okay, you’ve suddenly gone from like one person to, let’s say, 150 people and so forth.” And winning deals, when a customer “appreciates you, or really likes you, or gives you a reference.” The hard ones are just as specific: “Maybe a customer leaves you. Maybe you don’t really get, in terms of the sales, where you want it to be.”
“It’s absolutely a roller coaster to build something new,” I said, “to build a company and to bring people together.” Venkat had a story about that.
“and then his thing was that, you guys are entrepreneurs, what’s wrong with you? Why did you do this?”
Venkat Thiruvengadam, at 22:04
The speaker was the NVIDIA CEO, whom Venkat met “because he had invited a few companies from my investors.” I offered my own theory: “You have to be a little bit crazy. There’s like an optimal amount of crazy, where you get like crazy enough just to pull that trigger, but not so crazy that you fall off the deep end.” Venkat listed the reasons it takes that much.
“And yet the chances of success are like so small, right? I mean, they’re like minusculely small. And the bad part is that you can fail anytime.”
Venkat Thiruvengadam, at 22:30
“You may be doing great today, and then suddenly a big company releases a feature which is like so close to you, and then like it’s free.” I’d been there: “You’re like, well, why didn’t they just buy my company instead of release that feature? Oops.” Or the technology moves: an on-prem company doing well watches SaaS arrive, or a SaaS company watches “an AI-native company which raises like $100 million of seed.” His conclusion: “So anything can change anytime.” And then, I said, “you have to stand in front of everyone as the founder, as the CEO, and still describe something positive. Say, here’s our path forward. Here’s how we’re going to win.”
What keeps him going is a kind of evenness. “I think the general idea is that you sort of get used to all days, right?” A bad day passes, a good one fades, “So, yeah, I think overall it’s been a good journey.” At founder events, he said, “The guys who are happiest are really the young ones, right? They just don’t know yet what’s coming, right?” His advice to them: “I’m like, yeah, dude, just wait two more years.” I compared it to something I love. “I kind of equate it to riding a motorcycle. It’s just incredibly risky, but it’s the perfect expression of freedom.”
The unsung hero
I asked who has guided him, and he started at home.
“First and foremost, I think I’m able to do any of this because of my family, my wife, the way she takes care of everything else. I mean, that’s like the unsung hero.”
Venkat Thiruvengadam, at 25:56
Then the people who helped in the three years he bootstrapped. “Like, I had a mentor, Sri, who sort of like introduced me to his team. And today, 70% of my engineering team is from his previous company that he sold to, for example, Hitachi, right?” Advisors and friends came next, and investors: “I feel I’m incredibly lucky with investors as well.” When he looks back, “I think I probably only remember everybody whom I’m grateful to.” The retention numbers back up the mood. In engineering over seven and a half years, “we lost maybe like two people or three people voluntarily, which has been pretty good.”
“That’s an incredible track record, and that speaks mountains to your leadership style,” I said. He passed the credit along, to the chief technology officer, the people who manage customers, sales and marketing, and one person in particular: “I think I’m so grateful to our first salesperson, right, who heads our sales, right?” And he came back to where we started. “It’s just one thing led to another and sort of got me here. So it was largely because of, I think, a lot of people had a lot of goodwill.”
Advice for younger Venkat
If he could meet his younger self, Venkat would split his career in two. For the first part he was a pure developer who “cared about some specifics of the product, or my perspective around that, and like, how do I convince everybody else about that perspective, so to speak.”
“And then when I actually became an entrepreneur, and when I had to sell software to people, they couldn’t care less about my perspective about things. So I had to care about everything, about their perspective.”
Venkat Thiruvengadam, at 28:49
“So maybe I feel that I could have learned that before, while I had a job.” I suggested a big company might not have offered him that customer-facing exposure. He agreed that customers taught him, but said the habit doesn’t need them. “But generally speaking, I think this is a culture, a behavior, a personality trait that you can maintain wherever you are.” Colleagues, seniors, your own team and the team next door all have a perspective to care about.
He was honest about the limits of a large company, too. “Your chances of making an impact at a customer level, if you’re a developer at Microsoft, is minuscule, effectively.” But the people taught him a lot. He named one colleague, his manager’s peer: “I always learned so much just by watching those people. They just wanted to make forward progress, bring the organization forward, and so on.”
Teams, Slack and the money machine
“You know, it’s just a different experience to work in a big company than it is in a startup,” I said. Venkat said you don’t think as broadly in a big company. I said you’re more of a cog in a giant apparatus designed for one thing. “And like, when you have a giant machine that’s making money, like, rule number one is don’t screw up the money machine.” So the appetite for risk isn’t there, and “That’s why innovation very rarely actually comes out of big companies.”
Venkat gave the example he knows from the inside. “I mean, if you compare Teams and Slack, Slack was so popular because it genuinely was a very innovative software.” “Teams is fine, and nowadays it’s gotten much better,” he said, but it reached millions of users fast for a different reason. “It’s simply because Microsoft bundled it in Office. Everybody was using Office.” “Right. So they cheated,” I said. He wouldn’t go that far. “Well, I mean, I don’t know if it’s cheating. It’s just a go-to-market strategy.”
The public record has a version of that argument. Microsoft announced Teams on November 2, 2016, as a direct competitor to Slack, and launched it worldwide on March 14, 2017. In July 2023 the European Commission opened an antitrust investigation into whether Microsoft unfairly used its office suite to increase sales of Teams. The next month Microsoft said it would make Teams an optional part of the Microsoft 365 bundle, and in June 2024 the Commission charged Microsoft with antitrust violations for the bundling (Wikipedia).
Venkat’s point wasn’t legal. It was about what each setting asks of an engineer. On a team that can sell on distribution, management may say, “okay guys, just get it out. I know I can sell.” A startup engineer can’t lean on that. “They have to show real value to the customer.” And he was clear about his old employer. “So again, there’s nothing, they’re the greatest company in the world, in my opinion. And I think I am incredibly indebted for being there, my time there, so much I’ve learned.”
“But all I’m saying is that for the same job profile, your motivations and your behaviors can be different depending on where you are.”
Venkat Thiruvengadam, at 32:36
A next-generation Kafka for agents
A lot of founders listen to this show, so I asked a leading question: “is there any tool out there, or a service, that you just wish someone would grab onto and build?” “It depends on which day you ask me,” Venkat said, and that day it was agents talking to agents. He was deep in “some sort of agent chaining, where then, like, messages have to be passed across like multiple agents and so on.” The requirements came in one breath: “They have to be authenticated, permissions have to be done, also the messages have to be reliable and so on.”
“Can I actually have some sort of a next-generation Kafka, wherein I can throw in a bunch of agents and then basically say that, just send the message from this agent to that agent, and then deal with everybody in intermediate in a reliable way, right?”
Venkat Thiruvengadam, at 33:32
“I don’t know, maybe it exists and maybe it doesn’t exist.” Kafka is the reference point because it solved the same problem for services. LinkedIn built it, released it in January 2011, and it graduated from the Apache Incubator in October 2012 (Wikipedia). For agents, the closest public effort we know of is the Agent2Agent protocol, which Google announced in April 2025 and moved to the Linux Foundation that June. It defines how agents built by different vendors discover each other, exchange messages and coordinate tasks (Wikipedia, A2A). A protocol is the handshake. Venkat’s ask goes a layer further, to a broker that authenticates each agent, enforces what it may send and guarantees the message arrives, the way Kafka does for services.
He’s living the problem. In October 2026 he posted that two of his own agents were arguing, one sourcing sales leads and one with access to his LinkedIn, and that he had to step in.
Man! My AI agents are arguing with each other!
Venkat Thiruvengadam · October 24, 2026
For security teams, his list is also a threat model. An agent that can message another agent needs an identity, a scope for what it may ask for and a log of what it sent, and the one receiving needs to know the message is real. Those are the same questions we answer for agents that share one API key, one hop further.
They don’t work for existing code bases
He closed with a view that surprised me. “I think people are very excited about like the AI coding tools and so on. But you know what? They don’t work for existing code base. I mean, I can tell you.” “Really? They don’t work for existing code bases?” I asked. They’re good for building something new, he said, and much less so when you hand them the code a company already runs. I joked about putting vibes in production.
“Yeah, probably you can replace the developers who are writing like fresh code and so on. You can make the existing guys like productive and so on.”
Venkat Thiruvengadam, at 34:37
“But it’s not like I can wake up in the morning, then say that, okay, these are the 15 tickets that I need to do, or 15 feature sets, I’ll give it to Windsurf and it’s done, and I can just go to sleep or something like that, right? It’s not like that. So maybe someday, when we can get there, that would be something really great.” It’s the same argument as the rest of the episode, pointed at code. The model can write. Knowing how this particular code base works, what it touches and what breaks if it changes is the integration, and that part still takes people. Our guide to vibe coding security covers the controls that keep AI-written code from shipping the wrong thing.
What happened after the tape
The episode aired on January 27, 2026, and went up on our YouTube channel on August 28, 2026, with chapters (YouTube). DuploCloud spent the year between those dates rebuilding itself around the help desk Venkat described. Its homepage now calls the product “The DevOps Agent Platform,” with the line “Scale DevOps without scaling headcount,” and says that “Agents absorb routine ops work. Your engineers keep the judgment calls.” The platform runs self-hosted on a customer’s own Kubernetes or fully managed by DuploCloud, and the stack it shows has five layers: a UX layer, Agent Studio, an agent framework, ARMOR and a model router (DuploCloud).
In May 2026 Venkat started writing the design down. The first chapter of his series argues that enterprise operations are collaborative, and that the personalized coding agent that took off for developers is single player (DuploCloud). His post about it puts the share of repetitive DevOps AI queries at 80%, which is the case for sharing one live session instead of every engineer asking the same question on their own.
"I'm running out of my year's worth of token budget." and the solution - Rationing? That is like taking away a developer's laptop. Might as well give them PTO.
Venkat Thiruvengadam · May 21, 2026
The second chapter, a week later, is the one that reads like the episode. It names the runtime ARMOR, for Agent Runtime for Multiplayer OpeRations, and puts the ticket at its center: “The ticketing system is the heart of the ARMOR architecture.” Every interaction with AI happens inside a ticket, a multi-user session with its own context, audit trail and cost tracking. Each ticket works inside a defined scope of systems, credentials and permissions, and “No command executes without explicit user approval,” with auto-approvals, allowlists and blocklists set per ticket (DuploCloud). That’s the human in the loop from 13:30, written down as architecture.
I am sharing Chapter 2 of the series: ARMOR, which stands for Agent Runtime for Multiplayer OpeRations.
Venkat Thiruvengadam · May 29, 2026
It’s also the clearest follow-through on “our IP is not in our agents.” On the tape, DuploCloud gave its agents away and kept the framework. A year later the framework sits on the vendors’ own agent kits, and the part DuploCloud builds is the multiplayer layer, the scopes and the approvals around them.
In June he turned to the people in the middle. His post on platform engineering says developers are well served by coding assistants and a whole ecosystem that carries code to production, while the DevOps and platform engineers who build internal platforms have nobody supporting their code on the same trip (DuploCloud). His answer is an extension framework on top of ARMOR and a DevKit that runs the whole platform on a laptop, which is on GitHub (DevKit).
Software Developers are very well served.
Venkat Thiruvengadam · June 23, 2026
In July he pointed to Y Combinator’s request for startups, which says AI hasn’t had its multiplayer moment yet, as the idea ARMOR was built on.
YC is now explicitly calling out that AI has not gone multi-player and calling out startups to solve this.
Venkat Thiruvengadam · July 23, 2026
And in September, 800 people registered for The AI Conference’s hack day, where the DuploCloud team came with a version of the platform that runs on a laptop.
We have 800 participants registered for the Hack day. Come build with us. Now you can download and run DuploCloud in your laptop
Venkat Thiruvengadam · September 28, 2026
DuploCloud’s own YouTube channel is older than the agent platform, but two of its 2024 videos show the two halves of this episode: the compliance work and the operations work.
The ratio Venkat got used to at Azure, one engineer for 50,000 workloads, is what happens when software answers the routine requests and people decide the hard parts. That’s the bet he’s making for everyone else, and the security work underneath it is the part we see every week: know who is asking, scope what the agent can touch, have a person approve each change, and keep a record an auditor can read. Get those right and the ticket can go to the agent.
Did you catch it? A six-question quiz
Interactive · six questions
Did you catch it?
Six questions on what Venkat and I actually said, with the timestamp for each answer. The answers are under each question for anyone reading without JavaScript.
-
By 2013, how many virtual machines had Azure grown to, by Venkat's account?
- About 50,000
- Like 5 million
- Over a billion
b. "And then, before I knew, by 2013, it had already grown to like 5 million virtual machines or something like that." Transcript, 3:26.
-
In Venkat's split, what is the GRC tool's job?
- To implement the controls
- To collect evidence and pipe it to the auditor
- To write the security policies
b. "I think the way I would say the value is distributed is that they're a GRC tool whose job is to collect evidence and pipe it to the auditor so that they can do their audit." Transcript, 7:42.
-
Why do many AI SRE platforms stop at read-only, by Venkat's account?
- Read access is cheaper to run
- Regulators require it
- The specific problem of safety
c. "And a lot of these AI SRE platforms, because of this specific problem of safety, they end up limiting themselves to read-only use cases." Transcript, 13:14.
-
Where does Venkat say DuploCloud's IP sits?
- In its agents
- In its own model
- In the vertical integration and the framework
c. "Our IP is in the vertical integration and the framework that they would use the agents, or they would build the agents." Transcript, 14:16.
-
In Venkat's bubble analogy, what was the bubble around 2000?
- The dot-coms
- The internet
- SaaS
a. "But it was the dot-com part that was the bubble. SaaS was not a bubble. Internet was not a bubble." Transcript, 17:18.
-
What does Venkat wish someone would build?
- A cheaper GRC tool
- Some sort of a next-generation Kafka for agents
- A faster coding assistant
b. "Can I actually have some sort of a next-generation Kafka, wherein I can throw in a bunch of agents and then basically say that, just send the message from this agent to that agent, and then deal with everybody in intermediate in a reliable way, right?" Transcript, 33:07.
Can your tickets go to an agent?
Venkat’s help desk only works when the questions underneath it have answers: who is asking, what the agent may touch, who approves a change and where the record goes. This scorecard asks eight of them about your own operations. It takes about two minutes.
Scorecard · eight questions
Can your tickets go to an agent?
Answer for the agents you run today, or the first one you plan to run against your infrastructure. If two answers fit, pick the lower one.
-
When an agent acts on your infrastructure, whose identity and permissions does it use?
- A shared admin or service account
- Its own service account, broadly scoped
- The requester's permissions, scoped to the ticket, with short-lived credentials
"Who is the user who's calling? How do you authenticate?" See The orchestration underneath.
-
What happens before an agent changes something, like a deploy, a new database or a reboot?
- Nothing, it just runs
- Our agents are read-only for now
- A person approves each change, and auto-approval covers only a written allowlist
The human in the loop is what lets an agent write. See Read-only is where most stop.
-
Where do requests for your DevOps team arrive?
- In chat messages and hallway asks
- In several ticket queues
- In one help desk, as structured tickets an agent could read
The ticket is the unit of work, for a person or an agent. See The ticket trap.
-
Does the agent know which environment a request is about?
- It has one set of credentials for everything
- A person tells it each time
- Environments and owners are mapped, and it gets access to only the one it needs
"Which environment are they talking about?" See The orchestration underneath.
-
Does every agent action land in a record an auditor could read?
- No
- Some actions, in the agent's own logs
- Every action, with the ticket, the approver and the result, kept with our other audit evidence
"If we do our job, that means you have your evidences." See Your Vanta goes green.
-
Who writes and maintains your operations automation?
- Whoever wrote the script, years ago
- The DevOps team, in scripts only they run
- The DevOps team, as reviewed agents and workflows anyone can request through the help desk
"Graduate from writing scripts to building AI agents." See From scripts to agents.
-
Where does your agent platform run?
- In a vendor's cloud, holding broad credentials to ours
- In a vendor's cloud, with scoped credentials
- Inside our own cloud account or Kubernetes, under our controls
DuploCloud always ran in the customer's account. See There is no SaaS.
-
If you changed the model behind your agents tomorrow, what would break?
- Most of it, because the rules live in prompts written for one model
- Some workflows would need rework
- Nothing important, because the permissions, approvals and logs live outside the model
"AI is a reasoning engine that drives all this." See A reasoning engine, not a product.
An agent with write access would be holding your shared credentials and answering to no one, and that's fixable. Start with identity: give each agent its own account, scope it to the request, and make every change wait for a person. Then put DevOps requests in one queue an agent can read.
The foundations are there, and the proof is thin. Map environments to owners so an agent only reaches the one a ticket names, write the auto-approval allowlist down, and send every agent action to the same place as the rest of your audit evidence.
Your agents work the way Venkat describes, and you can show it. Keep the approvals honest by reviewing a sample each month, and test that a swapped model can't widen what an agent is allowed to do.
How much of your queue could an agent take?
Venkat’s mainstream IT ratio is one DevOps person for every 15 to 20 engineers, most of them working a ticket queue. This calculator sizes your own queue and what an agent with a person approving its changes could take off it.
Calculator
How much of your queue could an agent take?
How many engineers file DevOps tickets, how many each files in a month, how long one takes your DevOps team, the share an agent could close with a person approving, and what an hour of DevOps time costs.
180 tickets a month take about 270 hours of DevOps time, or 1.7 people's worth. An agent closing 50% of them with a person approving would take about 135 hours a month, worth $194,400 a year at this rate.
The defaults are placeholders. The one DevOps person for every 15 to 20 engineers is Venkat's picture of mainstream IT from the tape, and at 60 engineers it means three or four people, so the queue is only part of their week. The agent share is the number to argue about. In a May 2026 post Venkat put the repetitive share of DevOps AI queries at 80%, and the approval step is what makes the write tickets safe to count. A month of one person's time here is 160 hours.
From Azure networking to ARMOR
Everything on this page sits on one timeline, from Venkat’s first networking job to DuploCloud’s agent platform. Filter it by thread.
Timeline · 2001 to 2026
From Azure networking to ARMOR
Filter by thread. Dates are from the public record except where marked as part of this show.
- Siemens
Venkat starts as a network engineer in Gurugram (LinkedIn).
- Illinois Institute of Technology
Research assistant on an IP multicast tunneling protocol (LinkedIn).
- Microsoft
Software engineer in Redmond, in the group that becomes Azure (LinkedIn).
- Windows Azure Networking
Venkat is one of the two founders of the team, by his LinkedIn (LinkedIn).
- Project Red Dog
Microsoft introduces Azure at its Professional Developers Conference (Wikipedia).
- Windows Azure launches
Renamed Microsoft Azure in 2014 (Wikipedia).
- Kafka
LinkedIn releases the message broker Venkat would like reinvented for agents (Wikipedia).
- Insieme Networks
Member of technical staff on the controller for Cisco's ACI, at the startup Cisco acquired that year (LinkedIn).
- Zenefits
Principal engineer, infrastructure automation for microservices (LinkedIn).
- Microsoft Teams
Announced as a direct competitor to Slack, and launched worldwide on March 14, 2017 (Wikipedia).
- DuploCloud
Venkat founds the company, bootstrapped for its first three years (LinkedIn).
- General Magic
The documentary about the iPhone before the iPhone opens at Tribeca (Wikipedia).
- The Teams investigation
The European Commission opens an antitrust investigation into Teams and Microsoft's office suite (Wikipedia).
- Series B
$32 million led by WestBridge Capital and StepStone Group, with Mayfield, for $49.5 million in total (TechCrunch).
- Llama 3
Meta releases the open model I asked about (Wikipedia).
- Charged over bundling
The Commission charges Microsoft with antitrust violations for bundling Teams into Office (Wikipedia).
- Observability
DuploCloud's Advanced Observability Suite (YouTube).
- Episode 64
Daniel Marashlian on building Drata, the GRC side of Venkat's split (episode 64).
- Agent2Agent
Google announces an open protocol for agents to talk to each other, and moves it to the Linux Foundation in June (Wikipedia).
- We record episode 87
"in like the last seven and a half years, we lost maybe like two people or three people voluntarily."
- Episode 81
Eric Olden on putting AI agents into production safely (episode 81).
- Episode 87 airs
This conversation.
- Episode 89
Graham Neray on agents that delete the database and then lie about it (episode 89).
- Multiplayer AI
Chapter 1 of Venkat's series on why enterprise DevOps needs shared AI sessions (DuploCloud).
- ARMOR
Chapter 2, with the ticketing system at the heart of the architecture (DuploCloud).
- Extensions and DevKit
Why platform engineering never took off, and a platform that runs on a laptop (DuploCloud).
- Episode 99
Ged Ossman on AI onboarding and a shared protocol for agent context and permissions (episode 99).
- Multiplayer, per YC
Venkat points to Y Combinator's request for multiplayer AI (LinkedIn).
- Episode 87 on YouTube
With chapters (YouTube).
- Episode 104
Yash Kosaraju on why a16z's security chief doesn't trust the approve button (episode 104).
- Hack day
800 registered for The AI Conference's hack day, with DuploCloud on a laptop (LinkedIn).
- Agents arguing
Two of Venkat's own agents disagree, and he settles it (LinkedIn).
What to do this week
Five things, in the order Venkat’s own platform would check them.
- Give every agent its own identity. No shared admin accounts. Each agent acts as itself, scoped to the person and the ticket that asked, with credentials that expire when the work does.
- Put one approval in front of every change. Let agents read freely, and make every write wait for a person, with a short written list of what may be auto-approved.
- Route DevOps requests through one help desk. If requests arrive in chat, hallways and three queues, an agent can’t see them, and neither can an auditor.
- Map environments to owners and access. When a ticket names an environment, the agent should get that one, for that long, and nothing else.
- Send agent actions to your audit evidence. The ticket, the approver, the command and the result, kept where your GRC tool and your auditor already look.