# Durable Execution as AI Agent Infrastructure

**Podcast:** AI + a16z
**Published:** 2026-02-19

## Transcript

Building stateful applications require orchestrating calls across dozens of microservices with variable availability characteristics.
You can imagine state management became a big mess there.
Imagine a really busy kitchen at a restaurant.
All sorts of chaos going on.
The real world is complex.
There is all sorts of chaos going on in a restaurant.
But at the end of the day, there is a very clear outcome that restaurant is looking for.
Every order gets processed in a very specific sequence of steps.
Then eventually every order translates to being delivered to a customer exactly once.
This is exactly what durable execution provides.
We completely abstract out state management.
For you as a developer building an order management system, you just code up your business logic, and we are the execution authority of making sure every order gets processed exactly once in the presence of all sorts of chaos and failures in the system.
What happens when an AI agent fails halfway through a task?
If it's a short prompt, you start over.
If it's a three-hour deep research job burning thousands of tokens, you've lost real money and real time.
Durable execution solves this.
The idea started at Uber in 2015, where two engineers built a system that could remember the state of any running process and recover it seamlessly after a failure.
That project became temporal.
Today, Temporo powers OpenAI's codex, processes every snap story and runs transactions for Coinbase and Yum brands.
As AI agents get longer running, more autonomous, and more expensive should restart, the need for guaranteed execution has gone from nice to have to mission critical.
But scale is only part of the story.
The real question is what infrastructure the agent era actually requires and what it's still missing.
A16Z's Sarah Wang and Ragu Ragaram speak with Samar Abbas, CEO of Temporo.
Maybe to kick off, just for the audience, can you share a little bit more about what exactly is durable execution and why does it matter?
So Temporal is an open source platform which ensures durable execution of your code.
What that means is if during an execution of your function, if a failure happens, we remember all of the state.
And then we seamlessly and transparently resurrects that execution on a different host along with that state and continue executing exactly where it left off without you as a developer writing a single line of code for it.
So in a nutshell, that's the core value proposition of what we are trying to enable with Temporal as a platform.
In a modern application, the reason this is hard is because a modern application consists of so many distributed parts, correct?
Exactly.
And so that's why when you think about the core primitive we are building is super straightforward.
But to Ragu's point, now it is so broadly applicable to such a broad spectrum of problems out there.
To kind of bring this to life is imagine a really busy kitchen at a restaurant.
Okay, yeah.
And at any given night, a busy restaurant is probably taking hundreds of orders.
Every order might look different.
Some get prepared quicker, some takes a little bit longer.
They can come in, not in a uniform way.
Suddenly a lot of customers come in, you might see spikes of orders coming.
It's chaotic, yeah.
Yeah.
But at the end of the day, there is a very clear outcome the restaurant is looking for.
Every order gets processed in a very specific sequence of steps.
And then eventually every order translates to being delivered to a customer exactly once.
That's what the outcome they are looking for.
Imagine all sorts of chaos going on.
The real world is complex.
There is all sorts of chaos going on in a restaurant.
Stations might go down essentially.
And oh, a particular chef might take a break or some new person comes in without any context on how much of preparation has already been done.
What the thing that restaurant cares about is how many items are on the menu and how to prepare each one of those items in a specific fashion.
But handling all of those failures, handling these spikes, or handling all these failure cases of stations going down and coming up, or when failure happens, how do you make sure you have enough state to continue processing that order where you left off?
Those are not the things that restaurant cares about.
This is exactly what durable execution provides.
We completely abstract out state management.
We completely, for you as a as a developer building an order management system of a restaurant, you just code up your business logic and we guarantee all of that state, or each and every order gets processed.
We are the execution authority of making sure every order gets processed exactly once in the presence of all sorts of chaos and failures in the system.
So I love this kitchen analogy.
Can you maybe put into a real world example?
You know, obviously you and Max started Cadence, the open source project at Uber.
Can you share a little bit more in these concrete terms, maybe what some of the use cases were at Uber?
Both me and Max, I think funny thing is we started at Uber within a month of each other, the back in 2015.
Uber was going through a pretty interesting transformation.
Like as you can imagine, like any startup, they started with a monolith, and at some point the company started running because of that, like hyper growth, start running into both technical limitations of the tech stack to grow the company and even organizationally.
You want to build more and more things also.
So this is where the company started moving towards a microservices architecture.
And I think they went so extreme where by the time we joined, like they had more microservices than engineers in the company.
So as you can imagine, building stateful applications require orchestrating calls across dozens of those microservices with variable availability characteristics.
And you can imagine state management became a big mess there, essentially.
Right.
And at Uber scale, no less.
At that Uber scale, essentially.
So this is what kind of led both me and Max to kind of convince the leadership there that, oh, this is one problem we know how to fix.
And that's what gave birth to Cadence, which was the predecessor for Temporal, as a platform, oh, where the whole idea is you write a function, and we take care of durability for you, and we handle all those infrastructure failure.
That your function, we guarantee execution of that function from start to finish.
You don't have to think about that as a developer.
And that actually started opening up cadence for a broad spectrum of use cases at Uber.
Some of the good examples there is as simple as like tipping flow.
And by the way, this is a technology you can adopt in a very piecemeal fashion.
And Uber tipping flow use case was actually a very good example of that.
Was oh, they were integrating it, I think one of the banks in South America where the SLA was three days.
The entire system was powered out of Kafka, which is an awesome technology for processing large streams of data, retrying a single message for three days.
It is not designed for that.
Right.
So the very first use case there in that team is oh, like you try the tip, like the message to process and the banking API call.
But if the message comes in, you try, if it returns a failure, rather than keep on retrying there, you start a cadence workflow with a retry policy of three days, and then that's done, essentially.
Yeah.
But then over time, they actually ripped out the entire platform, which is dozens of those event-driven system, dozens of Kafka messages, and replaced the entire thing with temporal there, essentially.
Or cadence, yeah.
You're bringing up an actual second important attribute of temporal, right?
Which is very well suited for these long running transactions.
And we'll talk about that in the modern world later.
But uh the recoverability and the long-running transactions seem to be two things that are very attractive to your customers.
So, which is where I think the extreme end of that example was the Uber loyalty program.
Like you take a trip.
Uber one, yeah.
Yeah, the more trips you take, the more points you earn, and then you can those points for oh, five dollar rewards or other things, essentially.
That entire system was running on top of cadence, essentially, where like you were running a workflow for every Uber rider, essentially, which is there forever, and it is just taking events.
Every time a trip completion event comes in, it is a signal to that workflow, and that whole business logic of awarding points based on your trip data is all captured within that workflow.
There was literally no database backing that.
Our entire state for each one of the rider essentially is kept within that workflow itself.
And at least one interesting characteristics that you get of that is I think there was an incident where there was a business logic where you get an event for trip completion.
And the business logic has a bug where it will reset your total credits, your points to zero.
That would make a lot of people unhappy.
Yeah.
So somehow that bug got rolled out into production.
And then suddenly within an hour, Uber support starts getting called where are my points.
And imagine trying to recover from something.
Even though they immediately rolled back and then fixed workflows which were not touched, but the workflow which were touched are already corrupted.
I think one of the very interesting dynamics you get from a system like Temporal, which is built on the principle of like event sourcing, is we actually build a feature while during that outage is oh, because we know when the workflow made forward progress, what was a build ID?
Which made so we actually could reset the workflow, go back in time and reset the workflow to that point and replay all of the events after that point with the new code, and suddenly you recovered all of the corrupted workflows.
So like when you look in the platform, so that's the awesome thing about temporal as a platform.
We solve so much of the problems around versioning long-lived applications from user behors.
And those are the things which typically, I don't think there is any other technology which even comes closer when it comes to those class of problems.
I mean, there's a huge economic impact, if you think about even that example that you mentioned, right?
Turned customers, just any sort of complex workflow of touching a customer that fails midway through, starting over, the economic impact of that is huge.
Yeah.
Um I ha has there ever been a study that you guys have seen, like with or without Temporo that you can share?
One of the things we were able to deliver through temporal cloud is five lines of operational SLA.
Incredible.
And I think, and first of all, like what value you put to that level of reliability.
It's like if you go talk to people who experienced the cloud provider outages during fall of last year.
So painful.
They can clearly tell you economic.
And I think so that was actually one of the another big things that we were able to deliver last year, is we've been, at the end of the day, core value proposition of our cloud product is especially built around this reliability promise.
And during those outages, we have features like which allows you full business continuity in the case of full region or uh wide outages.
So we have a feature called multi-region namespaces, where people who were leveraging that feature, they were actually able to fail over their namespaces to be powered out of different regions, and they didn't had more than a few seconds or a few minutes of disruption for the service while those outrages were going on, essentially.
Wow.
Wow, that's massive value.
Yeah.
Especially when you're powering these mission critical applications.
And that's the key thing, is right.
Like uh today, like if you go talk to any organization which is now putting applications in production, just building these kind of business continuity things is a huge part of the roadmap, essentially.
And technically, the moment you start building these things on top of temporal, you are getting all of that value for free, essentially.
Yeah.
Which is very big for people who are looking for higher level of uh reliability and availability guarantees.
Yeah.
And you know, I think um with AI, the states are actually only getting higher.
Um, and maybe this is a good time to transition to Temporal's role in the agentic space.
Um, because uh, you know, Temporal is actually powering some of the world's most utilized agents uh currently, um, and the ones, you know, in the process of being built.
Um, and so I think one of the things that got us excited uh about Temporal is not just the product that you built five, six years ago, but its relevance to today is probably greater than ever.
Can you talk a little bit about that journey and um, you know, maybe even share a little bit about the agents that you're powering and I think just starting with why temporal is so perfect for the agentic framework today um and sort of the new stack that's emerging would be um would be really interesting.
Yeah.
So um actually here is the thesis for us here at Temporal is um if you think about, I think there's a massive, as you talked about, there's a massive platform shift happening right now.
Yep.
And if you what are the core ingredients of that platform shift is which is driving it is, yes, previously the way we used to build applications is oh, there is a business domain, and you write a product spec about how to automate certain parts of business processes.
You talk to an engineer, pass of all of that one thing, and then engineers turns it into a working app or working uh application, essentially.
With the whole agentic way, I think as these models are by the way, there are two things happening.
First of all, these models, they are coding agents.
Yeah, yeah.
Where you can generate these strongly typed app now.
Yeah.
Yep.
And the barrier to adopt temporal also goes down.
Yeah, exactly.
So basically now I think uh like there will be a lot more apps being generated, which is specialized for very specific needs, essentially.
And the other thing is as these models are getting smarter and smarter, what we have discovered is new, what we call the agenc apps, which is the agentic loop.
Which is you have a model, you give it a prompt with some context and a set of tools, and then you let that model kind of plan and then make those tool invocations to give you the right business outcome, essentially.
Though it's the agentic loop.
There's a second class of those apps there, essentially.
So I think this platform shift is happening.
The thing we are excited about at Temporal is two aspects.
Temple is a company which is obsessed about developers.
We at the end of the day, if you look at what's a core bottleneck for the company, is oh, a developer getting excited about the platform and building their next app.
Yeah.
And I think what this platform shift is going to do, and which we already start seeing, is a lot more developers are going to come in the fold of being developers now, essentially.
And which were pre traditionally or previously not developers, can now actually build these apps themselves.
We are super excited about that possibility.
The second thing is the cost of building these apps is going to be significantly lower.
Yep.
Which means there is going to be an explosion of those apps.
Both of those things is actually the core bottlenecks for temporal.
More developers building more apps, at the end of the day, the core value of software is now going to be shifting towards how do you put those apps, make it uh operational.
Yeah.
With all of the guardrails where an enterprise is ready to handle this explosion of apps which is about to happen.
And I think that is uh the thing that we feel durable execution is pretty uniquely positioned to capture that wave.
Yeah.
Yeah.
No, I think you're you've got a great point there about where the agentic application universe is headed.
Interestingly, especially the last I would say six months, right?
There has been a shift from these interactive agent applications that are essentially short-lived agents to these long duration agents that are just sitting in the background and doing a whole amount of processing, right?
And so that is a wave that's playing in your favor.
Because those agents now need the same thing that uh you built for Uber, right?
They need durability, they need long-running state management, they need to be able to recover for all sorts of scenarios.
And these API tool calls go off and come back in an indeterminate amount of time.
So you're very well suited for that shift.
So 100% Ragu here is um, if you think about it, probably last couple of years was where a human is prompting LLM, getting responses.
Now we have seen already seen the shift from that to now give it context and tools and now agentic loop where now these agents are doing work for you also, essentially, with the without human kind of continuously talking to those.
Which means we have already started to see these agents are getting longer and longer and doing more and more meaningful work and more asynchronous.
And to Ragut's point, this is exactly where state management of those agents is going to become a very big problem, essentially.
The agentic loop gets mapped very easily to the temporal workflow.
Yeah, got it.
And so we see, at least the way I describe it, if you take a step back, is I feel we are in the MS-DOS era of agents right now.
Where you have an operating system where you build these apps, you give it, you give full control to your application because it's in a sandbox, right?
At the end of the day, what you guys you can going to mess up only one machine or VM, essentially, or sandboxed.
So you give it that access, and but still there, people are seeing huge value.
Yeah.
A very good example is Clot Code, for instance.
Like, I'm pretty sure everyone after the holidays is super excited about Cloud Code.
And then yeah, it's an awesome example of an agent which you run on your either developer machine or the VM that you are working on, and it's actually doing very useful work for you.
It is actually starting to take uh instructions where it's actually running more and more longer lift, but still within the scope of a single uh sandbox.
I I think it's very natural where these models get more and more smarter, we will run out of what things we can do in a single sandbox, where there will be a whole swarm of those agents.
We have already have organizations who are already running hundreds of agents on top of Tempolo right now.
So we already see that uh industry is kind of moving into a multi-agent tech world.
Yeah, absolutely.
So are these is it a scale-out pattern, or is it each agent doing a different task?
And then there are sub-agents, or what is the pattern that you see when these these customers are using hundreds of agents?
So I think what we are doing, lots of specialized agents.
A very good example of that is let's say if someone is building an app which is, I want to book my next vacation.
And at this point, someone like people, someone that person don't want to reinvent the wheel.
Of course.
Oh, there is already lots of APIs available.
Yeah.
Which is doing reservation for airlines.
Or rather, who have all of the knowledge built for uh like hotels.
So why would even though, yes, if someone wants, they can generate all of that, but why essentially?
There is no business value in that.
So I think what we are going to see is like uh I think a lot of value will move to specialized agents, which is doing meaningful stuff, essentially.
Which means that you will be handing off work more and more, these APIs are going to get more and more longer lived, essentially.
Exactly.
Yeah.
And then you need a durable RPC to connect all of that together for building and uh business outcomes uh for the use case you are going after.
We clearly see the world moving in that direction, essentially.
And I think that's a big gap, right?
Right now, people are very excited in this MS DOS era of, oh, I'm just talking to my agent locally or within the sandbox and doing meaningful work, but we are clearly headed into a very distributed model of a swarm of agents collaborating together on solving complex problems.
Yeah, specialization is always the way of the world.
So there is no reason it would be any different this year.
Or this time around.
Yeah, at least the another thing that I see is at least these AI is very model similar to human, right?
It's about the context.
Yeah.
The more context you get, uh, give that uh you the real uh less correct things come out of it, essentially.
And it's the same thing, right?
Like as a developer, like if I am thinking about everything at the same time, I'm going to produce bad software.
Like I'm a very first principle thinker.
Yeah.
And which is you take a complex problem, you break it into smaller chunks, and then you work to solve these smaller chunks and compose complex solutions.
And I think this is exactly this agentic wave is moving towards, and this is where I think I clearly see the world heading heading towards.
We we totally agree with you, by the way.
Um before we move off coding agents, just since you brought it up, um, I wanted to ask a quick question.
Um, so you actually are powering some of the world's top coding agents.
Um, I don't know how many of them you can talk about publicly, but you know, obviously OpenAI has one, um, Replit, uh, there's sort of many different layers of coding agents out there.
Um, given your seat, what do you think differentiates these coding agents longer term?
And and why is uh durability and reliability so important in this space in particular.
Let's talk about like some of the characteristics of these coding agents and how they like what are the good characteristics you want to see as they evolve, essentially.
Initial version of these coding agents was people thought of that as just tap completion.
Yes.
Yes, right.
And then yeah, we will give like our developers in the company, oh, you go try out a coding agent.
They said, like, I already have tap completion.
Yeah.
So far we've come.
And but like, especially, especially after the holidays, everyone came back.
Max had this moment with Cloud uh 4.5 essentially is oh, like these coding agents is no longer like I think we are clearly entering a world where a product-minded engineer is now empowered to produce software without writing a single line of code for it.
Yeah, yeah.
Yeah.
And this is I this is an insane world.
So what we are clearly starting to see is you provided the right context and uh right prompts, you can get really complex problems done.
Like these coding agents then burns a lot of tokens for a we are clearly seeing they've started to work longer and longer.
Yeah.
Uh to produce the right outcome for you.
So that's time.
So one clear dimension to is is these agents are going to get more and more long-lived.
Exactly.
Yeah.
Where you will be handing off work in the background.
Yeah.
Because then what an engineer would be doing is suddenly the, I think the agentic engineer would be working on 15 things simultaneously.
Yeah.
Because you they will be basically working on something and then giving AI the right context and prompts and stuff to kind of work on a task and move on to the next one and the next one.
And the AI agent on the background like works on 15 things for you.
So that's where I think uh the productivity, that's why I believe the productivity we are going to see in the industry is just going to be insane.
Yep.
Yep.
It's gonna be an exponential leap over time, of course, compared to today.
So this is where, for example, if you uh one use case I can talk about is like about open AI, how they are leveraging and Poral essentially is Codacs.
Codecs is exactly that where, oh, like now these codecs agents are like orchestrating various tools, very complex um patterns for getting a task done completely in the background.
Nothing is running on your code.
There is uh everything is being spun off, tested, and everything for you on the background.
You need a reliable orchestration engine to kind of tie all of these things together.
So the way we are typically talk about that is these models tell you what to do, but you need an execution authority.
How does that work get done?
Yeah.
Yeah.
At a very large scale, that's the next problem.
Right.
So and um, so I so this is how Codecs uses.
This is exactly where doing millions of those codec executions at any given point of time with using the right resources, handling spikes and failures and all of those, this is exactly how they leverage temporal essentially.
So my belief is these eventually these coding agents are starting to where you hand off longer and longer streams of work.
And whoever is working towards that future is probably going to be the winner.
Yeah.
Makes sense.
Absolutely.
There's probably a cost implication too, right?
Given how token intensive it is.
The cost of starting over, right?
If you're not managing state is extremely expensive.
Retries, exactly.
Exactly.
Yeah, so when we talk to your customers besides coding, which, by the way, coding agents, I think you've sort of uh swept the field, at least anecdotally.
Um we also see a lot of folks using you for uh uh what would be conceptually equivalent of a deep research, right?
I have to go off and research the problem.
And customer success.
So, what are some of the common patterns that you're seeing there?
So I think, especially for deep research, is a very good example of where Temporal adds a lot of value.
Yeah.
First of all, to your point, you burn a lot of tokens.
Uh, but it's expensive.
And there are a few characteristics where Temporal kind of as a platform provides for deep research kind of use cases, agentic use cases.
One of the characteristics is interaction with a human.
Because a lot of those these one of the things is awesome, is like by the way, I talk to AI all day.
And AI is asking me questions.
And waiting for my response, essentially.
So before it kicked off, like other part of the research.
And I think so that maintaining that context across multiple human interactions and managing that state so you don't lose the work before, that's a huge value.
Temporal provides.
The second interesting characteristics, if you saw deep research, is that it kicks off things in parallel.
Yes, yeah.
Yeah.
Where you start a complex topic, oh, let me scrape this thing, or let me look into like call and make an API invocation.
So it basically does a lot of things in parallel and then collect all of that and uh into the next sequence of steps that needs to happen.
With Tempor, it's so natural uh for coding up like any complex kind of uh orchestration logic for the entire deep research agent to kind of conduct the research and consolidate the responses before uh reaching back to the user.
So I think, and we're especially provided with recoverability and state management for your entire thing.
The other, of course, thing is these deep research is now can also getting, I've already seen like now.
I come in, like give it my thing that I want to research, go make coffee.
And I come back and it's still doing some stuff.
Yeah, exactly.
So it is absolutely getting longer and longer lived, and then all the tokens you are burning, and you absolutely want recoverability of any point in research over there.
Yeah.
Yeah.
I think by the way, the the just going back to uh the Uber scale piece of it, um, what we've been amazed by as investors is just how quickly products like a deep research have gotten to enormous scale, and you really don't have anything out there other than temporal, able to handle that sort of production and scale at scale.
So uh uh thanks, Sarah, for bringing this thing up.
So if you think about this, is the thing which I'm super excited about.
Yeah.
Is when we build durable execution, like this is 15 years ago, what the what we are seeing is basically business transactions.
We are in the path of code, like every, for example, every snap.
Actually, Snap Story is a my my second category of use cases, but like every let's say Coinbase transaction.
Or Yum brands, which is KFC, pizza, Taco Bell, every time you place an order, that's a temporal essentially.
Wow, yeah, wow.
So it's, but still, it's order of magnitude of how many business transactions which is happening.
Yeah.
Uh for example, at Uber, it was trip scale.
How many trips were happening?
Yeah.
So it's awesome.
It's a lot of con, and since we are building a consumption-based business, we care about the throughput of those transactions, essentially.
But then the next category is what we call as internet scale.
And internet scale is things like Snap.
Like every Snap Story, and you can imagine New Year's Eve, how many snap stories being posted, essentially.
Each one of them is a basically business transaction.
And so we got actually pretty excited about that.
And this is where the last few years we've been actually focusing on can we run at that scale.
One of the awesome outcomes we have delivered actually last year, which we take a lot of pride on our uh engineering team on, we actually already have a cloud system which can handle spikes of 150 K actions per second on a moment's notice.
Wow.
Without any interactions or anything.
So we've been kind of focusing a lot on basically this internet scale.
Can we handle that?
The funny thing is, uh last year, a couple of years ago, actually I was talking to Max and said, Max, looks like we have overengineered on scale.
What's the use case?
Yeah.
Where we're needing this much scale.
And then, of course, the whole AI agent tick wave happened.
Now you're gonna be agent scale.
And I think this is where, like, I think if you look at some of the largest labs use us and the scale that we are talking about, snapscale is peanuts right now.
Incredible.
And so we this is we are talking about a completely different scale of consumption, which we is this is the thing which I'm super excited about.
This is the first time I'm out of my comfort zone.
Okay, now I'm having conversion with Max.
Okay, how do we 100x sub now?
Yeah, I never thought I hear uh snap scale as peanuts.
That's a good one.
Yeah, yeah.
The other interesting side benefit, and I didn't realize it until we started spending time together, is you guys keep a record of every step of the execution, right?
Um, as uh the workflow executes.
So there is a lot of, we hear a lot of hype and popularity about execution traces for especially for agents and anything that interacts with models.
All of that becomes is a there's a free benefit on your platform.
Yeah, right.
And this is by the way, we actually bring the entire companies together.
Even before AI, what we used to see is like when an organization adopts temporal as their core orchestrator, we bring companies together.
The entire like organizations in the company together.
Because like people literally share our uh like temporal UI to their business teams to show, oh, this particular bit because they will map business um like like business transactions to temporal workflows.
And then they literally will send links to their workflow execution histories as the visualization of what that workflow was doing and if they feel something is wrong, essentially.
So like this uh event sourcing, which is uh the mechanism we used for uh state management, essentially, it has this advantage of now everything in your system is auditable.
And everything you get so much visibility into your business transactions now, just because of that nature.
So what we actually saw, especially with AI, and when people start modeling their agentic loops as a temporal workflow.
Yeah.
Is because these agents are completely non-deterministic.
Yep.
Yeah.
Right.
And the moment you model an agentic loop as a temporal workflow, and temporal workflow is an awesome way to kind of have a durable agent, and suddenly now you have full visibility into everything your agent was doing, essentially, and then people are finding that to be super useful.
Yeah.
And it's useful in runtime, it's just also useful in making the agent better, right?
And training and so far.
Yeah.
So it has dual benefit there.
That is actually awesome that Ragu, you brought that up, is I feel like the amount of data we have of the execution history of those agents, I think we can eventually spin up a completely different product surface area for analytics, business analytics.
It's an gold mine of data to kind of figure out, oh, which how which of the my tool invocation is taking the longest time.
And which of my tool has the highest failure rate.
And we can s because we have all of that data, and we can run all of those execution histories to an analytics engine to kind of power all of that business development.
Observability is also a natural byproduct of your system.
Yeah.
Yeah.
So it's interesting.
I mean, we talk a lot about agent stack, and there are a lot of companies, amazing companies that come by saying we solve this part of the agent problem, agent stack problem.
You solve a massive amount of the agent stack, if you will, right?
Obviously, keeping these agents up and running, long running agents, observability, all these traces.
A good chunk of all the environment surrounding an agent gets simplified on your platform.
I I think by the way, this is the funny uh thing is like suddenly like everyone is scared of oh SaaS is dead or software is dead.
The public market certainly are.
Yeah, yeah.
So I think there's certain dynamics which is going on, which is certain things that we talked about is more developers.
That's a reality that's happening.
Yeah.
Explosion of applications because the cost of building an app software is going to go down.
That's a reality.
Where is the value moving?
There I think at the end of the day, the way I talk about that is uh at least the way I rationalize that is a lot of value is going to move to APIs.
Like, yes, if someone wants to build the next Google maps using agents, probably they can do it.
But all of the data Google have essentially to power those maps, essentially, that's the that's the value, essentially.
Same thing, like someone like Stri is, yeah.
If someone wants to build their next generation payment system, maybe they can do it.
But Stripe has all of the relationship with all the vendors or everything out there.
Yeah.
So I think there is real business value, which is going to be exposed through APIs and agents.
And I think at the end of the day, is to my earlier example, like if someone is now comes in and have all some idea about the next generation experience for booking a vacation, they will not go and reinvent the whole airline reservation API.
Right.
They will still going to use something.
Yeah.
So you don't think SaaS is dead?
I yeah, yeah, yeah.
Yeah.
So it might be.
A lot of people are very interested in that question.
Yeah, yes.
That's a definite statement right there.
I think I feel that.
I agree with you, Roland.
I feel on the contrary.
I think all of this other the other core things that I talked about, more developers and more applications, we are going to automate the world even faster.
Yeah.
This is going to drive insane.
We are already seeing insane amount of traffic consumption coming in.
We don't, it's not slowing down.
It's increasing.
Yeah.
And I think all of those applications is going to drive even more.
If you are providing the right valuable uh business outcomes through APIs, essentially, your business is going to skyrocket essentially.
So now taking that question to the Agentic stack.
I one thing which is a reality today is a lot of, if you look at agent tech platforms today out there are not differentiated.
Yep.
Agreed.
And I honestly feel like I think we are in this world where we are evolving so quickly.
Yeah.
By the time you take a bet on one of them, within six months, it will just disappear.
Because they are not differentiated today.
So that's why at least the approach we took at Temporal was we don't want to create yet another platform.
There are already too many out there.
I think every organization, based on their needs, they need to assess and find the right platform for them.
We solve the problem of state management.
Or we believe these agents are going to get more long-lived, more mission critical, more asynchronous.
We solve the problem of scalability, reliability, and putting these agents in production.
That's where we are differentiated.
So the strategy we took was integrate with everyone.
Yeah.
Of course.
And this is where I think we did uh an integration back in August last year with OpenAI's Agentich SDK.
We partnered with Pedentic to provide like a temporal plugin to basically where we could be the state management underneath the cover behind Pedentic as a experience, essentially.
And then we are working with everyone, essentially.
We have a team who's kind of basically building these integrations with every popular platform out there, essentially.
And I think for foreseeable future, we continue to go on that journey.
Yeah.
And the area that we are investing into is we need to simplify the experience of Temporal itself.
Today, um one of the bigger focus area for us is the entire developer loop.
Today we clearly see people want to build something, try things out, see, run it, and then iterate.
And I think today that loop is today, we have a very clear separation between application logic and the back end.
And we want to bring that together, we provide a fully closer developer loop of someone building an application, testing it, running it, and then deploying it to production.
So that is going to be a big focus area for us.
And this is where we put could potentially partner with uh a potential winner out there also.
By the way, I don't just to um maybe follow up on uh your point that there's just so much evolving in this space right now.
It's hard to know what is sand, what is stone, right?
And and you know, temporal is making bets on you know what you guys see as more set in stone.
Um but uh curious what if you have, you know, a perspective on is there an emerging sort of minimal um, you know, minimal viable architecture or infrastructure, if you will, of hey, I want to build a long-running agent.
Um I'm gonna have temporal for state management.
Maybe there's some sort of observability layer, code sand, but you know, uh curious like what that um if you're seeing any consistency in the tools that folks are using, and you know, maybe there's um things that people started with, right?
Frameworks, et cetera.
Are those even needed?
You know, curious how that's kind of shaping up, even though obviously it's quite a chaotic and crowded field.
Yeah, 100%.
So there are some patterns which have started to emerge.
For example, things like sandboxes.
Yeah.
Especially as these agents have now access to tools, it can destroy a company.
So I think if in any organization basically rolling out agents in production, better be investing into a sandbox or either building one or buying something other than that.
We are seeing that.
Yeah.
Yeah.
And same thing essentially is um we uh you mentioned uh prompt management.
Is a problem.
We see because it like the quality of prompts, evals is uh clearly an area where we see value.
People are driving value as they start implementing these agents at scale.
Yeah.
Another big area you mentioned is observability.
Yeah.
Is as these agents are fully non-deterministic, you better have a way to find out and have guardrails in the system and uh have observability into uh those systems, essentially.
So we are seeing, and this is where, by the way, observability has always been a problem.
Yeah.
Like, especially with even cloud architectures or even uh pre-agentec uh era, but these agents are going to push the boundaries out on observability at a completely different scale.
Absolutely, yeah.
And I think there is a huge scale problem there, which someone needs to come up with a creative solution of okay, how to even rationalize all of the observability requirements when this massive uh agent explosion and application explosion happens.
Yeah.
How are enterprises doing that now?
Is it mostly built in-house or they're using outside tooling?
People are trying.
At least what we see is there are a bunch of solutions there, which claiming that oh, we are the agentic solution or observability.
But uh, I think this is an area where people, at least I feel, are it breaks at certain scale.
Yeah.
There is this impression that, oh, the entire SaaS is going to collapse into agent.
Actually, I don't share that view.
And especially That's a hard take these days.
Please continue.
Why so?
Yeah.
If you go and talk to a traditional enterprise or a bank, let's say, they have certain business processes, which is very well defined.
Exactly.
Yeah.
And there is, they don't want, there is no reason to move those business processes to into this completely dynamic world, essentially.
And it's actually introduces such a gigantic risk in those organizations where I don't think they are moving to agents anytime soon.
But there's no need to move them to agents.
There's a reason it's called system of record.
You don't want to lose the record.
Exactly.
Yeah.
And so I think we I think we are going to see the split.
Yeah.
Or there are certain business processes which requires an orchestration or this deterministic way of building those and have the right guardrails and system of record, everything is auditable, traceable and stuff like that.
But then there are, of course, examples where agents are going to take off.
How big is each space, it's anyone's guess right now.
But the beauty for you is you're applicable on both sides of the industry.
And exactly.
And this is for us, this is why at least our whenever we talk to like uh executives on those traditional enterprises, okay, we solve both problems for you.
At the end of the day, you want an orchestrator which gives you guarantee.
You have a system of record, but there's execution authority.
We basically giving them an execution authority.
Yeah.
To your earlier point, I mean, there are so many business processes in an enterprise that surround the system of records that are done in a by humans, or not even done by humans because it takes too much time and money to do it.
That agents can now do.
All those become use cases for you.
Yeah.
And by the way, another thing I would add there is, especially if you look at now coding agents.
Now people can take any business process and generate a very strongly typed application for it with very little cost.
And I think there is going to be this tension also where people are going to evaluate do we really need an agent here?
Or you just built a new app because building an app is so cheap now.
By the way, just to hit on this, um, you sort of made this broader point of creating real business value with agents.
Um, and you also, you know, touched on sort of context management.
Um I I think it would be uh it would be a miss if we didn't talk a little bit more about context management.
Um context is such a buzzword right now.
We've probably seen dozens of startups talk about being the context layer, context graph, context engineer, you know, sort of the the full gamut.
Um but I I think again, you're in this unique spot to really talk about how to best give agents context.
And you know, what what do you see as um the way for you know agents to actually build proper context management?
For me, this was the biggest surprise we saw last year.
So both me and Max essentially um uh we were a big believer that uh temporal is actually a pretty interesting platform for data orchestration.
Yep.
Yeah.
And we ourselves didn't get excited about that space, is because at the end of the day, we are building a consumption-based business.
Right.
And the volume there are super low.
Like how many data pipelines you have, essentially, at any given point in time.
Right.
And the thing which actually surprised us the most is clearly one few things are happening.
Traditional data orchestration solutions are not powering context engineering.
Is because they are not designed for that scale.
Right.
Right.
The other thing we are seeing is now the context is coming from such a broad class of sources.
Oh, maybe it pulls from an API or a Slack message or I don't know, Google Docs, or like there's so many kind of connectors where pool people are pulling context from, essentially.
Everyone has their own reliability characteristics.
Yeah.
And I think a lot of those like uh like uh data orchestration solutions don't actually work well.
They're oh, they work really well that you have a data warehouse.
Exactly.
Yeah.
So they're built for it.
And then you can then do all sorts of transformation on the pair of the code.
They're designed for a different flow.
Exactly.
So I think what we are seeing is these agentic applications, the thing which is feeding them is real-time context engineering.
And I think that for the thing which was we are surprised, that is super high.
This is actually one of the big use cases for temporal.
People who have these different sources to pull out that data in a real-time fashion, massage it, put it into rags or whatever to power context for your prompts, essentially.
Is actually like those entire architectures.
Temporal is the orchestrator for those architectures, and it's insanely high throughput.
Yeah.
Wow.
And so that's uh to your point, essentially, is um we call these use cases basically collectively described that uh as retrievals or because it's retrieving data from a wide variety of use cases and to power these LLMs and uh the right context.
And at least those it's a pretty interesting or attractive uh category of use cases for us at Tempoho.
Yeah.
Yeah.
People are worried about uh context length and packing the context and so on and so forth.
So what you're saying is very relevant to the problem.
Yeah, and this is where I think one investment area for us in the product itself is large payloads.
Yes, yeah.
So durable execution today is awesome at building control planes or orchestrating uh basically uh complex or sequence of steps, essentially.
We are not a system to uh pass large amounts of data.
And I think especially for these class of use cases, there we clearly see a need for us to handle large payloads also.
Yeah.
Well, that's actually maybe a good segue.
Um, because you're already, you know, you're firmly powering some of the best agents today.
And I think what you just described um is actually core to why these agents are actually effective for um, you know, for for any individual customer.
Um, I'm curious, what do you think is ahead for long running agents?
Like what are you starting to see or anticipating that you'll see?
Like, what do you think, you know?
Let's say we do another podcast at the end, you know, in 2027.
How will the world of you know, agents change by then?
What are your smartest customers doing, in other words?
Yeah.
Um, you know, like uh uh having a magic eight ball to kind of predict it's super hard in this world.
Yeah, we'll we'll buy that from you.
Yeah.
Yeah.
But I at least um what we see is these agents are starting to do more and more meaningful work.
Yeah.
And which means they need to break out from their sandbox, essentially, and then the world is clearly moving towards a soar moff agents, essentially.
Yeah.
And I think this is where the thing which blows my mind is there's such a big massive opportunity is having a durable RPC.
How do you how do you stitch together these warma of agents, essentially, to basically doing state management across that?
And I think this is where at least I feel we have a project called Nexus, essentially, where we're trying to drive an industry-wide standard.
Even MCP, for instance, MCP originally started with tool invocation, which is very synchronous.
Yes.
And first of all, basic problem.
Today, now I have a tool which I make a request, response comes back in three days.
Yeah.
There is no standard solution for that.
MCP started to look into a synchronous kind of uh defining the protocol at least.
Yeah.
How do you implement that?
Right, exactly.
So I think temporal would be then awesome implementation for any asynchronous tool invocation, for instance.
Yeah.
So I think these tool invocation, first of all, is really natural that's about to happen.
It's already happening.
Yeah.
And but then I think the swarm of agents talking to each other.
Uh basically I uh we will see a lot of that.
Specialized agents doing specific things, and then people are orchestrating calls across um dozens of those agents to getting the right business outcomes.
And then suddenly now you have a distributed systems problem at a massive scale, essentially.
Yeah.
And so durable RPC, I feel it's a very key building block which is missing right now.
Yeah, there are others in the industry trying to introduce some standards around it.
Are you guys part of that?
So we we we've been trying.
Okay.
And this is where we have our own initiative right now with Project Nexus, but that's actually we want to coordinate with, because I think this is a problem industry is seeing everywhere.
Yeah.
We would love to work with like-minded people to drive.
We don't want to do it just only for temporal.
Yeah, of course.
We I think it's a very generic problem.
And I think there it should be driven as an industry-wide standard, essentially.
Yeah.
Yeah, absolutely.
Um, by the way, just I mean, this uh is more of a question based on your description.
Uh we're we're also starting to see um, you know, maybe you call them sub agents or these specialized agents, right?
And and they're um more focused on a particular task.
They might even use different models under the hood, right?
Because models have differentiation by use case as well.
Um, but but curious, uh if for your take, because this seems to be evolving a lot.
Do you think a lot of this development happens with the labs themselves or third-party applications that can maybe make use of the multi-model world?
Or of course, there's the third answer, it depends.
I think Jensen's uh describes this the best way I have seen it is this five-layered cake of this whole platform shift that's happening.
And there is value at different layers, essentially.
Yeah.
Is starting from like electricity to chips to cloud infrastructures to model and then the application, essentially.
Yeah.
By the way, at the end of the day, this whole stack, the value of that stack is going to be proven by how large the application layer gets, essentially.
Because that's the end value to a customer then, essentially.
And so I'm a big believer that this application, we have already talked about like things like a bridge, which is doing amazing work, essentially.
Yeah.
Around where doctor needs to focus on patients, not transcribing.
Exactly.
Yes.
And I really love their mission there.
And same thing, like we talked about even up, like legal, and I think this application.
Yeah, someone like a Harvey, for example, right?
Harvey.
Yeah.
And we, this is going to show up in a massive way.
Yeah.
And which is going to prove the value of all of us what we are building is going to be proven by that layer, I can't see.
Better know.
Yeah.
Very true.
And I so I think that has already started to happen.
It's in its infancy, but the whole bet is this layer shows up in a very meaningful way, essentially.
Yeah.
Let's switch to another interesting company building topic, which is very relevant to a lot of our listeners.
Originally, Max started as a CEO.
Then you guys did a switch, and you were the CTO, you did the switch.
Right.
And so that's uh fairly unusual, I would say, right?
What led to that?
And uh what is it about the CTO and the CEO position that you guys discovered that uh led you to do the switch?
Yeah, so um I think when we are starting the company, uh, by the way, like me and Max have a pretty long history of working together.
We've been like, I think working together for uh almost 15 plus years.
I remember when we're starting the company, we didn't even discuss who needs to be the CEO or who, like, or what is my role going to be.
When you're starting and so small, there's things needs to get done, and someone needs to do it.
I always assume I always assume Max, you are going to be the CEO, essentially.
And I think literally there was zero conversations that happened on uh who's the CEO or what's my role is and stuff like that.
Uh both of us are very product people.
Um we have built our entire professional career writing code and building products and providing technical leadership.
Funny things about both of us, we have never been people's manager throughout our professional career before starting the company.
How many people does temporal have now?
We are close to 400.
There you go.
Yeah.
We can't escape that.
Yeah.
It's landing on the job.
So we um I think then I think uh roughly like a two years ago, it's starting becoming clear my role and Max role.
Um we looked at it how we've been operating even before starting the company is Max is amazing, taking any complex problem, breaking it down, and then figuring out where the company needs to be five years on the road.
That's Max skill set.
I've always been the practical one, what steps we need to take to deliver on that five-year vision.
That's always been my role, essentially.
What we noticed, especially two years, as the company grew bigger and bigger, majority of the problem was not that we lack product strategy or where we are kind of headed.
Majority of the problem is execution risk.
As the company grew bigger, essentially.
And that is when actually Max himself got to a point where he said, Somewhere, I think it's about time, where I think right next step, the company needs a different flavor of leadership for the next phase of company building we are in, and you are the best person to lead that.
And literally that was 15-minute conversation.
Amazing.
Wow.
Incredible.
Well, I mean, hit upon the two most important questions to the CEO faces, right?
One is what should the company do, right?
And how do you get the company to do what needs to be done?
Yeah, yeah, right?
Yeah.
And it looks like Max was amazing the first part, and you're amazing the second part.
Yeah.
100%.
Yeah.
And I think one of the things which is really humbling thing for both of us, actually, is since we never, well, people's leader, we never delay to the challenges.
We have a lot of respect for people's leaders now.
Learning organizations and managing people is hard.
Yes.
Yes, yes.
There's no agent for that.
Yeah.
Exactly.
Maybe, maybe soon.
But maybe whenever you have a good question.
Well, there's the rent a human now.
I don't know if you saw that.
Yeah, it's so funny.
Rent a CEO.
Maybe just to end on a slightly spicy note, um, not necessarily related to management, but uh still um touching upon advice that you would have for founders today.
Um, and let me just set it up a little bit.
Uh so I won't ask you the question that everyone seems to be asking right now, which is are we in an AI bubble?
Right?
Who knows the answer to that?
Um, but I will maybe draw some parallels between today to that 2021 period.
Um, and uh those parallels would be uh in the fundraising environment, a lot of companies um raising maybe further ahead of traction than in other markets.
Um, and both a lot of uh commercial activity that is positive, but also fear in the market that good times will end soon.
Um and so we see a lot of this push and pull among our portfolio and founders.
Um curious given temporal is one of the few companies that came out of that 2021 period uh winning um, you know, full stop, right?
You have blown past from uh a revenue perspective, valuation perspective.
Um, but of course it was a journey.
And so curious what advice you might have for founders who are building companies today.
And you know, what do you think should be optimized for in partners that you look for, rounds that you're raising, uh, and you know, any advice you have.
Uh in all honesty, I think the experience post-2021 is actually helped us uh be a better company.
Uh one really clear example, which actually is our margins.
We I remember back in 2021 when capital was cheap, everyone was of this mindset is growth at no all cost, essentially.
Yeah.
And we ourselves were kind of uh guilty of that a little bit.
And we had like multiple negative hundred margins, I think.
Like many did, yeah.
And and I think that exp that shift that happened actually to helped us build a become a more resilient company.
Yeah, and we've completely like turns, we have amazing margins right now, essentially.
And we are able to turn that company um because of that experience, essentially.
But at the end of the day, the thing which has not changed for us is focus on solving customer needs.
And what having the clarity on what value you are bringing to the customer.
Yeah.
Doesn't matter uh like uh downtime or up or up market or down, like I don't obsess about that a lot.
Yeah.
Yeah, you definitely want to have cushion on capital, but uh we our strategy for this race is different.
It's not about the cushion, it's about we believe there's a gigantic opportunity.
Can we go after that opportunity uh in an aggressive fashion?
Yeah.
And I think that's what, by the way, like this capital race is not going to change our plan for this year.
Yeah.
It's not like we suddenly, but at the same time, I think we are going to especially both me and Max, we are product builders.
We are actually pretty happy at Uber building uh cadence over there.
Because we are s we feel solving problem, pretty meaningful problem there.
Yeah.
But at the same time, at the end of the day, the re core reason for us to leave Uber and start a temporal was Uber's business is to get people in car.
Building a general purpose workflow solution is not part of their mission or vision.
Yeah.
And we believe there is such a gigantic need for this thing in the industry, and we were s we believed it so long.
We were doing it even before Uber, essentially.
And that's when we decide to take the leap because we feel we could never get funded enough to realize the potential of what we are building.
I honestly feel like I think the temporal today, the thing like a big portion of our this fund is going into RD investments, essentially.
And I think we are just getting started over there.
We have so many ideas about the kind of value that we can bring in.
And especially this fund is kind of sets us up and to capitalize uh on the opportunity which is in front of us.
Absolutely.
Well, we agree with you that there's a gigantic opportunity, and we're so excited to be a part of it with you.
Um, thank you for joining us on the pod, Summer.
Yeah, thank you.
Yeah, thanks for having me.
So yeah, thanks for having me and really excited to be part of this journey with you folks, essentially.
Thanks for listening to this episode of the A16Z Podcast.
If you like this episode, be sure to like, comment, subscribe, leave us a rating or a review, and share it with your friends and family.
For more episodes, go to YouTube, Apple Podcasts, and Spotify.
Follow us on X at A16Z, and subscribe to our Substack at A16Z.substack.com.
Thanks again for listening, and I'll see you in the next episode.
As a reminder, the content here is for informational purposes only.
Should not be taken as legal business, tax, or investment advice or be used to evaluate any investment or security and is not directed at any investors or potential investors in any A16Z fund.
Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast.
For more details, including a link to our investments, please see A16Z.com forward slash disclosures.