Rebuilding the Cloud for AI Agent Code

For two decades, the cloud has been shaped by human developers writing code and managing its deployment. Now a growing share of production code is generated by LLMs with little human review. Because that code is not fully trusted, it increasingly runs in isolated, sandboxed environments. Meanwhile, AI agents are starting to operate infrastructure directly, by spinning services up and tearing them down on their own. Together these shifts raise the question of whether the cloud needs to be rebuilt for machine operators rather than humans. Render https://render.com/ is a cloud platform designed for application deployment, by handling scaling, self-healing, and security to reduce operations work. Render has been adapting to the AI era by building tools that let agents deploy and debug applications directly, with added guardrails and security. Anurag Goel https://x.com/anuraggoel is the founder and CEO of Render. In this episode, Anurag joins Sean Falconer to discuss why so many teams end up rebuilding the same infrastructure on top of Kubernetes, what changes when AI agents become first-class users of infrastructure and the guardrails that shift demands, and why the economics of AI are pushing developers toward higher-level platforms that trade fine-grained control for speed and safety. Sponsorship inquiries: [email protected] mailto:[email protected] The post Rebuilding the Cloud for AI Agent Code https://softwareengineeringdaily.com/podcasts/rebuilding-the-cloud-for-ai-agent-code/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  For two decades, the cloud has been shaped by human developers writing code and managing its deployment. Now, a growing share of production code is generated by LLMs with little human review. Because that code is not fully trusted, it increasingly runs in isolated, sandboxed environments. Meanwhile, AI agents are starting to operate infrastructure directly by spinning services up and tearing them down on their own. Together, these shifts raise the question of whether the cloud needs to be rebuilt for machine operators rather than humans. Render is a cloud platform designed for application deployment by handling scaling, self-healing, and security to reduce operations work.

• 0:44Speaker 00

  Render has been adapting to the AI era by building tools that let agents deploy and debug applications directly with added guardrails and security. Anurag Ghol is the founder and CEO of Render. In this episode, Anurag joins Sean Falconer to discuss why so many teams end up rebuilding the same infrastructure on top of Kubernetes. What changes when AI agents become first-class users of infrastructures and the guardrails that shift demands? And why the economics of AI are pushing developers towards higher-level platforms that trade fine-grained control for speed and safety? This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

• 1:41Speaker 01

  Anurag, welcome to the show.

• 1:43Speaker 02

  Thank you, Sean. It's great to be here.

• 1:45Speaker 01

  Yeah, absolutely. I've been looking forward to this. So I wanted to go back a little bit in time and ask you a little bit about your history and maybe how some of those experiences led you to the founding Render and everything that you're doing there today. So you were roughly, I think, around like the eighth employee at Stripe?

• 2:03Speaker 02

  Yes.

• 2:04Speaker 01

  Yeah, that's like, so by the time you left, how many engineers were managing AWS? And I guess like, what did that experience kind of teach you about cloud complexity and the actual cost companies are putting into just simply like managing this beast of the cloud?

• 2:18Speaker 02

  Yeah, so at all times when I was at Stripe, around 15% to 20% of the engineering team was simply managing VMs on AWS and all the complexity around that, storage and networking and load balancing. And it didn't really get easier. And obviously, as Stripe's scale grew, the complexity increased and you needed to continue to hire people to continue to help you scale. And it just never stopped.

• 2:51Speaker 01

  I also think, you know, if you think about like Stripe or even other examples of great engineering organizations like that, they're probably one of the best engineering organizations in the world. And if they're running into this problem, clearly, it's a, it's a problem that's going to essentially impact everyone if they can't figure this thing out.

• 3:09Speaker 02

  Yeah, and just to be clear, I do think that Stripe did the best they could at that time because that was really the only way for them to run in the cloud reliably and scalably. But as technology changed, as containerization took hold, it became clearer to me, and I'm talking about the 2017, 2016 era when a lot of people were containerizing their apps, but then they had to deal with Kubernetes complexity to actually run these containers in production in a way that was scalable or secure or reliable. It became clear to me that you could give app developers, and specifically app developers, not DevOps engineers,

• 3:53Speaker 02

  because Render has always focused on application developers. You could give application developers the same powers that they would get from the most accomplished world-class internal DevOps team. And you could do it in a way that was entirely self-serve for them. And they could simply focus on pushing their code and then get out-of-the-box primitives for scaling, for self-healing, for all kinds of state management. And they would get, you know, effectively, one of the best DevOps teams in the world productized. And that's what Render ended up becoming.

• 4:35Speaker 01

  Yeah, I guess like, before kind of getting into specifics on Render, what kind of breaks down? Like, you have people using containers, using containerized orchestration platforms that are well sort of established in the industry like Kubernetes. But at the same time, it seems like at scale, that's a very hard thing to just manage. So given that there's all this industry investment into Kubernetes, like what is it that specifically kind of breaks down as teams start to try to scale the management of that?

• 5:04Speaker 02

  Yeah, so we do manage a lot of Kubernetes clusters ourselves and we see this firsthand. I think it all depends on what kind of application architecture you're working with. If it's a really simple application, then it can run anywhere. It can run on Kubernetes, it can run on Heroku, it can run on other cloud providers. But as you start to become bigger, if your business is growing, you start needing more configuration around which applications can talk to each other. You start needing the notion of, well, your CICD needs to work in a certain way. You need to have certain environments be protected. You need certain services to be not available to the internet.

• 5:49Speaker 02

  You need observability across all of this. And then you need to be aware of when something goes down, you need to get alerted. And then you need to go solve that problem yourself because you have to then understand, well, you stood it up on Kubernetes and you need to understand sometimes exactly how Kubernetes works under the hood to know, well, this network policy change is what caused this DNS error. And with Kubernetes, you have to manage all of these things yourself. You spin up, even on code and code, manage Kubernetes clusters. You have to write a lot of YAML by hand that describes how to deploy your applications.

• 6:27Speaker 02

  But that really what that YAML is doing is describing a lot of the internals of the Kubernetes architecture and the Kubernetes concepts themselves. And then as your application scales, things become bottlenecks. And then you have to kind of manage those bottlenecks by understanding exactly what that is. You might never have encountered it, but suddenly you have a lot of internal DNS traffic because your application grew. And now your core DNS isn't working anymore. Well, who takes care of that? And then you have to go figure out how to configure core DNS to serve all that traffic. So it's every layer of the infrastructure stack within Kubernetes and even below it. Because you also have to figure out how to keep your VMs patched when things happen.

• 7:11Speaker 02

  And you have to deal with node pools and you have to configure different nodes for different things. And you have to make sure that your nodes are also well utilized. You have to pay for a lot of extra capacity because that's what Kubernetes likes to do. And you end up spending way more on just managing lots of unused Kubernetes capacities just so you can deploy your application the next time.

• 7:33Speaker 01

  Yeah, and then I think companies end up spending a lot of time on COGS optimization because their, their cloud bills grow escalating and getting out of control. I made this point recently about sort of data infrastructure where we have all these great data tools today. But the complexity of actually managing our data has not decreased as we've gotten better tooling. It's actually gotten harder because there's just simply more data, there's more complexity involved. And now we have like a bunch of tools that we also have to kind of understand how those things fit together. So it kind of sounds like the same problem when it comes to managing network infrastructure.

• 8:09Speaker 01

  Like, we have all these great tools, we have elastic scalability, but there's a lot of complexity making this sort of juggernaut of different services work together at a reasonable way, especially at scale.

• 8:22Speaker 02

  Yes, exactly. And different parts of your application might scale differently. And so you just have to manage all of that across the board. And even understanding Kubernetes is not something you can sort of just do. You can't really build your Kubernetes YAML using AI because AI makes mistakes and you have to understand when it does make a mistake because something will stop working at 2 AM at night. And then AI won't really be able to tell you what it should change because you just wrote it with AI. You have no idea how the thing works. And then you, you don't really want to be vibe coding your infrastructure when something's down.

• 9:00Speaker 01

  Yeah, yeah, and I would think that, I'm sure, we'll touch on AI because you can't really have a conversation in technology without touching, talking about AI these days. But as people are using AI to generate more code, we're creating essentially more abstraction from the details of the code. So there's going to be, I think, more buffer between like really understanding the deep internals of how that thing was built and run in the interest of essentially speed, which then when things go wrong, of course, makes it even harder to kind of debug and understand what's going on.

• 9:30Speaker 02

  Exactly.

• 9:31Speaker 01

  So I've heard you mention that you've observed that every company that runs on Kubernetes ends up building some version of like an internal pass that all kind of look roughly the same. Why is it that teams end up insisting on building their own thing? It kind of reminds me a little bit of in the early days of Auth. Every engineer wrote Auth eight different times across like every company. And eventually, you know, services came out that take that thing off of people's plate. But why is it that we're still in this place where people are writing these, you know, internal passes?

• 10:02Speaker 02

  I think there's a little bit of, well, this is how we used to do it, so why change? And there's also a generational thing. A lot of people learn to build cloud infrastructure using the tools that AWS gave them. And then, you know, Kubernetes was sort of this state that we ended up in. And you just sort of assume that that is how you always do it, or that that's how you will always do it. But I also now see from Render's perspective, we actually see teams moving from large Kubernetes clusters to Render because they get all the functionality that they're looking for without having to deal with the complexity of Kubernetes.

• 10:47Speaker 02

  And interestingly, that's happening more and more now, just partly because, and I'm sorry to bring up AI again, but so many more people are building so many more applications with AI that this whole notion of statically managing your cluster using a DevOps team is breaking down. It's breaking down very quickly because the DevOps teams are stretched thin, beyond capacity everywhere. And they're just trying to keep up with the core application, but then everyone else is like, well, I have this other application I want to start up. Well, good luck, because you can only do so much with a small DevOps team, or even a large DevOps team.

• 11:20Speaker 01

  Yeah, I mean, I think that if you look at sort of the traditional software development lifecycle of discovery, design, implementation, testing, productionization, that kind of thing running in a loop. If historically, the coding part, the implementation piece was like kind of slow and hard.

• 11:35Speaker 02

  Yes.

• 11:36Speaker 01

  The other things around it could kind of be relatively slow because it was not as slow as the thing in the middle, which was actually writing the code. But now we've compressed that time. So if people are generating, instead of having two apps to generating, you know, two apps a week,

• 11:49Speaker 02

  Exactly.

• 11:49Speaker 01

  the crippling slowdown, the company suddenly becomes the DevOps team. And how do you actually run the platform?

• 11:55Speaker 02

  Yeah, and that's exactly what we're seeing. And it's why Render has grown more in the last two years than in the previous six. So it's actually really interesting to see so many more companies come to us now that already have existing DevOps teams. That was not the case two years ago.

• 12:12Speaker 01

  Yeah, it's interesting. So I mean, you mentioned that in terms of why is it that companies are still continuing to build their own internal passes? Perhaps because of the the history essentially of people being kind of trained to do it. And this becomes sort of the default of like, oh, this is how you have to do it. You know, one of the knocks I've heard historically against your platforms as a service that have tried to ease the challenge of kind of running infrastructure has been that at some point, the company outgrows that and you have to get to a place where you're managing the knobs directly. Do you think that is going away? Or do you think that's an unfounded reflection on the reality of a platform as a service?

• 12:50Speaker 02

  Yeah, for the majority of applications out there, you really don't need something like Kubernetes. And Render, especially as we've continued to add more functionality, more customization, more flexibility, more power to render. We've continued to raise the ceiling on what's possible and we continue to do that as a platform. Now, I know I've seen other platforms where you hit that ceiling much, much, much sooner. For example, with Heroku, you can't get more than 14 gigs of RAM if you wanted to build an application that did that, or your application was restarted every 24 hours.

• 13:32Speaker 02

  And there was just a very small number of compute plans that you got out of the box. Private networking isn't available in the self-serve version. There's no way to store data on a disk. So there were so many reasons for why you grew out of Heroku really quickly. And Render's always built for people who are building complex, ambitious applications. And we want to make sure that you never outgrow the platform because we think that we can continue to raise the ceiling on what a platform can do. And we've been able to do that with a lot of our customers and some of our, I mean, OpenAI and Stripe are amongst Render's customers. Obviously, they use other cloud providers, but we also have companies like Base44,

• 14:14Speaker 02

  which is one of the largest vibe coding platforms in the world. They're running a lot of their compute, all of their compute for their web apps on Render. And they're able to scale with Render. They're now part of Wix and Wix has some infrastructure on AWS, but Base44 runs really well on Render and they want to stay on the platform, even though now they have access to this massive DevOps team inside Wix that has access to AWS.

• 14:41Speaker 01

  What are the things that you have to do specifically to make it so that people don't outgrow you? And how do you think about sort of balancing? I guess like blurring the lines between automating it, making it really easy and hiding some of the complexity while also giving enough controls to your customer to not outgrow you or not get frustrated with some opinionated view of how this should be done?

• 15:04Speaker 02

  Yeah, that is really the crux of how we think about product and specifically progressive disclosure of complexity. So to give you a really simple example, something that happened recently, we gave a customer a specific control that was only available in our REST API because they were creating services through the REST API. They're not using the dashboard. Their use case is actually quite complicated. And they want to use Render, just like they would use AWS, where they would spin up a VM and install things on it and spin up an application there. With Render, you can do all of that in a single API call. But most of our users don't need that specific thing that they want.

• 15:49Speaker 02

  And so we're not going to expose it to everyone in the dashboard. And so stuff like that, where you kind of think about who needs something and what's the surface area of how they're using Render? And how do you expose that feature in a way that is fully productized, fully supported? But it may not be something that everyone has to think about all the time.

• 16:10Speaker 03

  Agents are getting smarter every day, but even the smartest agents get stuck without the right context and the right tools. That's where Notion comes in. With the recent launch of custom agents, Notion became the collaborative AI workspace where teams and agents work side by side. And now their new developer platform is turning that workspace into infrastructure developers can build on. What stands out to me about Notion's developer platform is how much they've built underneath the surface. The platform ships with a set of new primitives that change what you can actually do. Workers are Notion-hosted sandboxes where you run custom code, database syncs, agent tools, webhook triggers, without spinning up your own infrastructure. The CLI lets developers and coding agents read from Notion, take actions and deploy workers through one interface. And with the external agent API, you can bring agents like Claude or Codex into Notion

• 16:55Speaker 03

  as workspace participants with real permissions and triggers, not just a sidecar tab you're copying from. Pulling in research sources tracked externally, syncing them into Notion and having an agent help triage what is worth covering, all in the same place the team already works. Learn more about Notion's developer platform today at notion.com/sed. That's all lowercase letters, notion.com/sed, to try Notion's developer platform today. And when you use our link, you're supporting our show, notion.com/sed.

• 17:25Speaker 03

  If you're running Postgres in production, you've probably felt the moment analytical queries start fighting your transactional workload. Most teams end up adding a second database and all the pipeline complexity that comes with it. Tiger Data, creators of Timescale DB, takes a different approach. We extend Postgres with hybrid row and columnar storage, so one table handles both writes and analytical scans. Native compression cuts storage costs up to 95%. Continuous aggregates keep dashboards live without bash jobs. And it scales to petabytes without you re-architecting. Companies like Cloudflare, Octave Energy, Schneider, Axpo and Flowco run production workloads on Tiger Data today. No stale data, no second system to operate, just Postgres. Managed for you, ready for the workload you're building toward. Try it free at tigerdata.com.

• 18:09Speaker 03

  You're shipping faster than ever with AI coding agents, but those agents don't vet the packages they pull in and they don't have security context built in. Ori by Endor Labs fixes that. It plugs directly into your editor via MCP, catching vulnerabilities, blocking malicious packages and flagging exposed secrets in real time. No separate tool to switch to, no dashboard to babysit, security that fits how you actually build. Teams using Ori see 10 times fewer security tickets and six times faster fixes. Free for developers. Get started at www-endorlabs.com/auri.

• 18:42Speaker 01

  I guess it's a little bit like, you mentioned the sort of progressive disclosure. It's kind of a little bit like how video games work where you start on level one, you have kind of limited amount of functionality. And then over time, as you get more comfortable with the controls, they add more and more complexity to it. And by the, you know, I don't know, level 15 or something like that, you're an expert. But not everybody's going to get there. And, you know, some people just want to come into level one and have a good time.

• 19:05Speaker 02

  Yeah, exactly. And the other thing that is changing is a lot of people are now using Claude or Codex to manage their render deploys. And we have skills and MCP servers that allow them to do that. And the complexity is hidden away a little bit further from them, even though Claude and Codex can actually look at all the different things in our API and make the right calls and they could create our infrastructure as code format called blueprints. And they can describe the application of blueprint. So you don't have to understand what a blueprint even looks like. But the main thing is that Render operates at a much higher level than, say, AWS. We operate at the level of the application.

• 19:48Speaker 02

  So you don't need to, even if you're using Claude and Codex, you don't really need to understand a lot of complex infrastructure concepts. You really need to focus on how really your application runs on Render, which is a very small surface area typically, depending on the complexity of your app. And you can debug it fairly easily, given the tools that we have. And these days, again, because of the tools we've built for AI agents to debug Render, people are able to do a lot more themselves. And again, I should clarify that we're building all of this for application engineers. We're not building for DevOps people. So the kind of tools that DevOps engineers might want, we don't worry too much about not having them.

• 20:29Speaker 02

  But if you're building a standard AI native company or a SaaS or whatever it is, there's a 95% chance that you don't need to go to AWS. And there's a smaller number of companies, like if you're building an infrastructure company yourself, if you're building, say, a database company that needs to really go down to the metal and figure out exactly how the database clusters are going to work together and use some esoteric AWS incantation, then you should not be using Render. It's not for you. But if you're an application developer, you can really use Render and continue to use Render as your application grows.

• 21:07Speaker 01

  Yeah, it makes sense. I mean, I think that there's always going to be a spectrum, right? Of the types of applications that we're building. Are you building core infrastructure? Are you building more of an application? And do you need scale for users? You mentioned AI management of infrastructure there. Like, how do you think about as people leverage tools like Claude, code, cursor, anti-gravity, whatever it is, more and more? I think the tools that are going to be really successful in kind of this agentic engineering era are the ones that are like easy to use as a default experience from the agentic engineering experience itself. So has that been something that you've thought about at Render? Like, how do we make ourselves essentially usable by AI and AI agents to be successful in this new wave?

• 21:49Speaker 02

  Yeah, we think about it a lot because our users are already using us with Claude and Codex and Anti-Gravity. They prefer it because they're already in there. They're already coding using these tools. And so why not deploy using these tools? And why not debug that your deploy is using these tools? So we've made it so that our MCP server can give you all the information that you need, that we expose the right kind of tools that allow you to spin up new applications. But we're also now thinking about how you can build systems that can be reverted if your agent makes a mistake without losing data or without causing some sort of massive disruption to your infrastructure.

• 22:32Speaker 02

  We're also thinking about how if we can identify that it's an agent user, then you can say, well, if it reaches this level of severity or this level of cost, then I need a human in the loop to approve it. So those are some things that I think not just Render, but everyone will have to build as agents start using these applications more and more, using their API or CLI or MCP server.

• 22:56Speaker 01

  Yeah, I mean, a lot of people talk about like guardrails around these things. But I think from infrastructure, like guardrails around the cost as well. Because, you know, when I accidentally spin up something that suddenly you have a huge bill for because some agent made a decision that was not necessarily the right decision. So for MCP, was there specific things that you had to do? Design-wise, that was above and beyond what the Render APIs were capable of?

• 23:19Speaker 02

  Yeah, so when we first launched our MCP, there were certainly some things that we did not put into the MCP that you could use our API for. But in general, our MCP is able to do a lot that Claude and others wanted to do. One of the big things that we did was the ability to really pull logs and deploy data in a way that can then help you troubleshoot failing deploy. And you can get metrics from the MCP as well. And so what we find is that a lot of people use our MCP to debug what's going on, especially when they're developing the application. And they're in this loop of like quickly pushing code and then seeing what happens. And so it makes it really fast for them to develop on Render

• 24:04Speaker 02

  because all of that stuff is available as tools in Claude. And Claude can correlate deploys with what happened in production.

• 24:14Speaker 01

  Yeah, I mean, that's a common pattern that we see at Confluent, which is, you know, where I work my day job as well. I think the number one use of our MCP server is probably outside of exploring the data that you have would be around debugging. And I've even seen recently some clients out there putting into their contracts with vendors that they're considering purchasing from within the contract. Essentially, need to know what is their support for agent debugging.

• 24:41Speaker 02

  Yeah, makes sense.

• 24:42Speaker 01

  Yeah, I mean, it's just the way the world's kind of going. Like, why leave the tool that you're in all day to go into logging some dashboard?

• 24:49Speaker 02

  Yeah, exactly. And I think dashboards are great for maybe when you're first trying to explore a new tool and you want to understand the different concepts. But once you have a good sense of what's going on, and maybe these days you don't even need that because you can build the exploration into your API or your MCP server. Just like any MCP server can expose the tools that are available to the LLM.

• 25:17Speaker 01

  How do you think about balancing, just from a product standpoint or in a resourcing perspective, where to put your resources? If the world is kind of largely going towards some sort of unified experience of from the terminal, from the CLI, interacting through these agents, does that mean that you put less time and effort behind the user interface, your web-based interface into Render to put more time behind your MCP and your APIs, which are going to be more the native experience that agents are interacting with you?

• 25:47Speaker 02

  I don't think that we're treating it that way. We still want to continue to improve our dashboard because I think people do like a visual experience for certain things. And again, if you want to see a lot of information in a very specific way, then often very purpose-built, info-dense views that are designed with that workflow in mind might be more efficient than using Claude or an MCP and might be faster. So I don't think that we can do either or. So we're actually increasing our investment in both. We're hiring people, we're hiring design engineers to continue to grow the dashboard

• 26:31Speaker 02

  and with all the new tools that we're supporting. And I don't think developers are saying, look, I'd never want to use the dashboard. They're just adding another interface. And it depends on maybe where they are in their journey. If they're coding and pushing code, then sure, they need that MCP server. But sometimes when something goes wrong, sometimes they do need to go into the dashboard or they do need to see all the metrics in one place or they do need to look at all the logs manually. So that's not going away.

• 26:59Speaker 01

  Yeah.

• 26:59Speaker 02

  And there's an element of discovery that I'd say is still a lot easier to do visually than through Claude or through tools that are fundamentally text-only.

• 27:10Speaker 01

  I agree. I mean, I still think the UI is the store window of the application where people kind of discover things. And the other thing, too, is sometimes an open-ended chat is not necessarily the best user experience. It's great if you kind of know what you're looking for. But if you don't, then it's easier to be sort of prescriptive and point people in the right direction when you have a user interface.

• 27:32Speaker 02

  Yes, absolutely. And you can really focus on the workflow that the user is trying to go through and make your dashboard very specific to that. And that's a lot easier to do. And it makes the user more productive than giving people a generic MCP server to do whatever.

• 27:52Speaker 01

  Yeah. You started moving workloads to bare metal, I think in mid 2025. And I've heard you say that it was more about control than necessarily cost. Because in that scenario, what do you mean by control?

• 28:07Speaker 02

  Yeah, so I do want to maybe issue a correction there. So we didn't actually move customer workloads to bare metal until just a month or so ago.

• 28:18Speaker 01

  Okay.

• 28:18Speaker 02

  Yeah, so we've been waiting, but it's happening now. And the cost versus control thing is really interesting because we are finding more and more reasons to run things on Metal itself because of the nature of untrusted code and its need to run in micro VMs. And micro VMs certainly run better on Metal. Even though they can run in a nested VM scenario, the performance characteristics are different. And they're always, almost always going to be much more performant running directly on Metal. In the case of like Firecracker with a KVM hypervisor, it's a lot easier to do that on bare Metal than on some like nested bird situation.

• 29:02Speaker 02

  So the control that we get is we are able to tweak the hypervisor. We're able to control the different elements of the machine in a way that is very specific to the kind of workloads that Render runs. And you could get Metal machines in the cloud from AWS or others. And I am pretty sure we're going to utilize those machines as well. But in the long run, I think that we want to be able to look at even things like placement of your application and your database, maybe if we can, even on the same rack. Now, you don't get rack-level placement controls, as far as I know, on AWS. So it's stuff like that where you can really hyper-optimize things

• 29:48Speaker 02

  and go down to the level of, okay, well, this is the best possible performance or cost structure or the kind of CPU. That's really the kind of control you get when you own your own Metal. And with AWS Metal, you also, I think you get some, but it's just, it's the Metal that AWS has. And you don't get, for example, a concept of different machine sizes. AWS machines are all the same size. The largest possible plan is the Metal plan. And you can get a Metal plan that's either larger than that or smaller than that.

• 30:25Speaker 01

  Okay. I think you also recently launched Render Workflows, which is durable execution for long-running staple processes. What was the motivation around that? I feel like durable execution, probably in the last year, is finally having its moment. Is that being driven in part by the investment companies are making around AI? Or is this something else that's sort of driving this interest in durable execution?

• 30:47Speaker 02

  Yeah, so what we're seeing is applications themselves are now very dynamic in nature. So when you build an agent, for example, and your user asks the agent a question, the first question might pull up 10 records, the next one might pull up 400, and then the tasks themselves could also be really diverse. It could be a web scraping task or a headless browser thing, or maybe just data crunching that requires 128 gigs of RAM. So instead of what used to happen where these asynchronous tasks were as simple as sending an email or processing a payment, our asynchronous tasks have become very, very diverse and heterogeneous.

• 31:32Speaker 02

  And as a result, it's become very hard to build these asynchronous processing systems using standard background workers and queues. And that, I think, is why durable execution is becoming really popular. People want to run a series of tasks and then they also want to be able to provision different kinds of compute for each task. And with render workflows, all you need to do is define your task in code. And so any task that you want to run, you can define it in code, and then you can trigger it in code as well using render's SDK.

• 32:14Speaker 02

  And render just takes care of the execution without you having to provision any compute yourself. So you don't have to stand up workers, you don't have stand up queues, and we give you all the flexibility around how many times you might want to retry the task or the concurrency level for each task that you want. And in many ways, when you try to do this with a queue-like system, you end up building very diverse sets of worker pools, each with its own memory or CPU requirements, so you can process the diversity of your tasks. And with durable execution on render using workflows, you don't need to worry about any of that, it's much simpler. And we take care of the compute for you, we give you a great observability view

• 32:58Speaker 02

  into exactly how your tasks are running, which ones are failing, which ones are being retried, the inputs and output to each task, for each task. And it's a really great experience for people who are simply trying to run non-deterministic flows in response to user requests.

• 33:17Speaker 01

  Would this be something that's directly competitive with the durable execution frameworks that are out there, like a temporal restate orgs? Or is it more aligned with both like GCP AWS have as now like stateful functions? For example, where I can call a function and it can control the state and recover from failures and so forth?

• 33:37Speaker 02

  In some ways, I think it's the best parts of both. Because for temporal, for example, yes, you have the control plane. But the biggest issue that we hear about from people who have used temporal is that first, it's really hard to get into, that's a very steep learning curve for temporal. You have to change your application to match exactly how temporal works, when really all you need is retries, or you need a certain level of observability, and you need to make sure something runs, and then you just need to be able to define a sequence of tasks. Temporal can also just really become overkill. And then temporal doesn't actually manage the compute for you. You have to spin up your own worker pools, and you have to design your worker pools

• 34:21Speaker 02

  so that, again, you kind of almost run into the same problem, like how big should your worker pools be? And if you're keeping them running, are they being utilized or not? And so it's the same problem that you run into with Kubernetes, where you just have these things running all the time, but it's not clear if they're being utilized. So there's fundamentally some of the same issues with temporal that you see in some ways with Kubernetes. And with render, it's different because render is executing your tasks, and behind the scenes, render is making sure that we only charge you for the task execution time. You don't have to worry about worker pools, you don't have to worry about running out of memory. You can define your memory at the task level, and that's what you get.

• 35:05Speaker 02

  And over time, the other thing we want to do is also allow you to scale up in memory dynamically. So you don't have to predefined. So let's say you're processing a really large document for a task that typically takes six gigs of RAM. You might want it to spike up to 12 gigs of RAM, and render will do that for you for that task, and only charge you for that task consuming 12 gigs of RAM. So it's much more flexible, it's a lot more accessible as well, because you define your tasks in code simply by adding a decorator or a pure wrapper over your existing function. So in that way, it's actually as simple as something like celery or bull and queue management, but you don't have to manage queues, obviously. So we've tried to build something that is incredibly accessible,

• 35:50Speaker 02

  but still gives you what you want out of durable execution, which is this notion of maintaining state across a sequence of tasks that could execute for days or weeks, and then also letting you make sure that it is actually durable, that you can retry these things, you can define concurrency, you can define the inputs and outputs in a way that are all typed. So I think it's going to be really interesting to see how people prefer, and we already have people moving to us from temporal. I think it's going to be really interesting to see when we launch workflows in GA in a couple of weeks. By the time this comes out, maybe it's already in GA, what people use temporal for versus render workflows.

• 36:30Speaker 01

  Right. And then, do you think as you support this, and even the hyperscalers are supporting some version of durable execution, at least like a lightweight version, is this something that just becomes kind of like the default experience for developers building any of these types of applications? Where regardless of where they're building, there's some form of durable execution available for them out of the box?

• 36:52Speaker 02

  Yeah, in many ways, it becomes like a Postgres database. So you just have to have a primitive in whatever cloud you're using to do this kind of work, because it is becoming so common now, and it's a completely new pattern of how people are building applications, which is why we invested in it so early. And we think that it's really important to offer it as a platform primitive, as opposed to you trying to glue together open source things to run them on render.

• 37:22Speaker 01

  And then was this from a ground up project, not forked from anything?

• 37:26Speaker 02

  No, no, everything was written in-house, we haven't used anything else. We're not even using like a tempor or anything underneath, everything is built end to end using our stack.

• 37:37Speaker 01

  What are you using for state management, if you can share?

• 37:40Speaker 02

  We are using, in some cases, we're using Postgres. And I think so far, Postgres has actually been relatively good for what we need. We haven't had to use like a more complex state management primitive yet. And then, yeah, there are places where we use Redis as well, but really, I think Postgres is the bulk of it.

• 38:06Speaker 01

  So we touched on this earlier, but the idea of as agents start to use infrastructure, you know, you need guardrails, you need these like cost controls. And you mentioned undo mechanisms as part of this as well. So what are some of the new things in terms of being of the undo stuff? And how does that work in like a safe way? So that agents can actually start to manage infrastructure in a way that you could trust?

• 38:29Speaker 02

  Yeah, that's an interesting one, because let's say that an agent wants to delete a database. If the database isn't around, no one's using it, you could show the agent that the database has been deleted, but then you keep the database around for 30 minutes or maybe 24 hours. So that if someone decides that the agent makes a mistake, then the agent can recover and issue a recover command on the database. So just like keep things around longer, that's the simplest example I can think of for undo. There are other patterns, like, okay, well, what if the agent decides to delete your web service? And this web service has a custom domain on it, and suddenly your traffic is gone.

• 39:13Speaker 02

  I think even there, you can make recovery a lot easier by having this notion of application infrastructure state that you can replay back really quickly. So that's where infrastructure as code becomes really useful. And so render's infrastructure as code format lets you define all your services in just a few lines of code. And the agent will then be able to simply add the service back. So in some ways, it's very similar to making a code change that leads to a bug and reverting the code change.

• 39:44Speaker 01

  Right. Do you have to also think about, and obviously this is something that you'd probably want to do anyway, but does it become even more, something you have to think about is the speed with which you can stand up pieces of infrastructure and tear it down when you might have agents that are trying something, deploying it, realizing it's not the right deployment model, tearing it down and then redeploying and doing that sort of like continuously almost in a loop.

• 40:09Speaker 02

  Yeah, absolutely. I think the reason we've invested so much over the last year in making bills and deploy is much faster is partly this, because these things need to be able to come up much faster when agents are trying them. And it's good for humans too, but agents are just operating at a very different speed, right? And so the faster you can make actions in your system, the more agents are going to prefer it. This is also why I think even with agents and maybe agents writing Terraform, agents will always prefer higher level systems like Render to spin up a web service or spin up a workflow, because trying to do that on AWS will take much longer because you have to wire up a bunch of things together and each thing takes a while to come up.

• 40:55Speaker 02

  And you might even need to spin up whole Kubernetes cluster to do what you're trying to do on Render, especially if you're doing some kind of like private networking. And so I'm not worried about agents when people say, oh, agents are just going to make AWS easier to use. Well, guess what? I think agents are going to prefer the most token efficient way to get to a certain outcome. They're outcome driven. And if Render can serve that outcome in a way that is much faster, it's a single call, it's much more deterministic for the agent, because it doesn't have to configure 5,000 variables. Then that's what they're going to prefer over something that operates at a really low level, at the level of a VM, where the agent might need to decide what kind of VM it needs to spin up and then what kind of plan on the VM and then what kind of, you know, just like, there's a lot of stuff that

• 41:40Speaker 02

  the agent would have to do on AWS.

• 41:43Speaker 01

  And maybe more back and forth with asking the

• 41:46Speaker 02

  Much more back and forth with the user, many more chances of error, because there are so many more steps. And so the more steps it has to go through, the more likely it is to make an error in any one of those steps.

• 41:57Speaker 01

  Yeah, I think that definitely true, and especially I think that this might not be the case for every company right now, but you mentioned the token cost. I do think the kind of free lunch era of tokens is going to be coming to an end relatively soon. Like I think that

• 42:11Speaker 02

  Oh, it has already, yes.

• 42:13Speaker 01

  Yeah, yeah, like I think companies, you see this in the news now, companies are blowing through their yearly budget of tokens in like a month and then not necessarily being able to map that to the ROI of, you know, what value they're getting out of it. So I think companies are going to be looking for ways of how do we optimize our token costs? And the things that are greedily chewing up tokens, people are going to be looking for alternative ways to solve those problems.

• 42:36Speaker 02

  Yeah, I think token economy combined with correctness makes the case for much higher level interfaces, which is why I think Render is seeing the growth that it is.

• 42:48Speaker 01

  Yeah. So if you're right about a lot of this, and the next version of the cloud doesn't necessarily look like AWS, agents really change our interface to infrastructure. What do you think things look like if we fast forward three or five years, which is a long time in our industry? But what is your sort of vision of where we're going with all this?

• 43:07Speaker 02

  It all starts from the applications that people are building. And these days, a lot of applications are AI native and they're agents. And agents require a lot of different primitives. I think a lot of code being run in the cloud is already untrusted. I think more code, three to five years, there'll be more code run in the cloud that has been generated on the fly without any human input, which means that it'll need to run in sandboxes or isolated environments all the time. And you will require much more governance across the board.

• 43:48Speaker 02

  And I think that in our current cloud, because of humans trusting other humans to kind of do the right things, we just don't have governance across the board. And the kind of abuse mechanisms that exist today are still, this is changing, but they're still limited by human actions, but that's going to change as well. And so it's just going to become, everything is just going to operate at a much faster rate. And it's going to become much more dynamic. And what that means is that the infrastructure underlying all of this has to become more dynamic as a result. It has to become more maneuverable by agents, obviously.

• 44:32Speaker 02

  And it has to also become more resilient against abuse and security issues. Because again, we're seeing that today, a new kernel exploit is coming out every week. And you really can't protect yourselves against AI driven exploits unless you have AI driven protections yourself. That's kind of where we are. And that's going to become a much bigger deal. I mean, we already see all the supply chain attacks, but what we're not seeing is the next level of dynamic network level attacks or some kind of other attack that hasn't even been invented yet, that attacks a different part of the infrastructure stack. So the cloud is going to become more scary, but there will be good actors as well.

• 45:15Speaker 02

  And a lot of the code that's being executed in the cloud is going to be generated on the fly and people are not going to understand it all the way they understand it today. And I just hope that it all still works somehow.

• 45:27Speaker 01

  Yeah, absolutely. Well, all right, this has been fantastic. Anything else you'd like to share?

• 45:33Speaker 02

  Well, I can talk a little bit about Render. We're seeing just the most growth we've ever seen in our history in terms of revenue. We have more than, as of June, we have more than 400,000 developers signing up every week. We have nearly 10 million live services on the platform. And we're able to help so many more people and organizations move faster and bring their applications and grow their applications and make them really capable in the cloud. And I hope that if you've never tried Render, that you will. It's just render.com. And we're looking forward to helping the cloud evolve in this new era that I just talked about.

• 46:11Speaker 01

  Yeah, fantastic. Actually, one question follow up of that, with all this growth in the signups, and obviously more people building applications, are you also seeing a persona change in terms of the types of people that are building applications? Like, is this truly democratizing access to anybody with like an idea, essentially being able to actually build something? And at least POC or experiment with it?

• 46:32Speaker 02

  Yeah, there's definitely a huge movement of people who are not quite the consumer vi-coder, the people who are technical and who can kind of understand pseudocode, which means they can kind of understand what's happening with Claude. But then we're also seeing people using Claude and Codex to teach themselves coding, because it's now become a lot easier. You can just ask Claude, hey, you did this, explain this to me. And I think Codex also has, or maybe Claude too, they have like a learning mode in them, where instead of just coding it, it'll actually teach you along the way. So in many ways, I think the definition of a software developer is expanding.

• 47:13Speaker 02

  And I'm not talking about people who just want to buy code on places like Loveable or Base44. I'm talking about people who want to build apps for their business or internal apps for their business use case, or even external apps, like product managers are the perfect example, where they're technical, they've had maybe a computer science degree, but they haven't been coding professionally. Well, now they can, and they are, and they're building applications that would be impossible for them to build earlier. So the whole industry and the nature and the number of applications is expanding really, really rapidly. And I think Render is actually kind of fortunate, because we're in the right place at the right time to take advantage of this wave of people who just want an easy place

• 47:56Speaker 02

  and a fast way to deploy these applications and bring them to the people who want to use them. Because none of these people are actually going to use AWS to deploy their applications. That's not what they're looking for. So so many new developers are really being trained on a new kind of cloud as opposed to AWS back in the day.

• 48:12Speaker 01

  Yeah, I mean, I think that's exactly right. You know, even within the organization I work for, well, one, I'm generating more code than I have in a very long time. And then I think that's across the board with all the PMs that I work with. But also I think that we're kind of creating a world where a lot of software is like ephemeral, because it's easy to spin up stuff. Like, I created like a dashboard the other day to measure engagement with a particular product, that I could have had someone within the company build in Tableau or something like that at some point, but I can just spin that up easily using something like Claude Code, run it on Render and have that thing ready to go. And for two days, and then when I'm done with it, I can throw it away. And it's not like this huge investment that I spent time on.

• 48:56Speaker 02

  And it's interesting, we're seeing that, what you just said about ephemeral applications, we're seeing that people are creating a lot of apps that live for shorter durations. And that's, you know, Render is obviously great for that, because you only pay for when the application is live. You don't have to worry about all this other infrastructure just sitting around, waiting for you to deploy another app on it. But then a lot of people are also able to create long-running applications that are helping their businesses. And it's really great, really exciting, motivating to be at the center of all of it.

• 49:31Speaker 01

  Yeah, absolutely. Well, again, thank you so much for being here. This was fantastic.

• 49:36Speaker 02

  Thank you for having me. This was a great conversation.

• 49:39Speaker 01

  All right, cheers.