Latest / Agentic Conversations (formally mlops.community) / Durable Execution and Modern Distributed Systems

Transcript

Durable Execution and Modern Distributed Systems · Agentic Conversations (formally mlops.community)

0:00
It's all about developer productivity, but different
0:01
aspects of developer productivity, right?
0:03
Here's some common patterns for building agentic systems.
0:06
OK, boom, agent SDKI want it interacting with the world.
0:11
I want it long running, reliable async temporal.
0:16
What you can do now is you can just go, you can fix that error,
0:22
save the file and then we go restart the server and that'll
0:26
just finish. Should we chat durable
0:43
execution? Let's do it.
0:44
All right, let's do it. Let's talk about durable
0:46
execution. Can you give me the breakdown,
0:48
the TLDR of what it is? So durable execution basically
0:52
just means that your software does what it's supposed to do.
0:56
At Temporal, we talk about making software crash proof, and
1:02
that means that whatever it is, the program starts at the
1:05
beginning and it's going to run to the end regardless of what
1:11
happens with failures, which are particularly common in the
1:14
cloud, right? You have servers that are flaky,
1:17
services that are overloaded, AP is that are down rate limited,
1:22
you name it. There's a mechanism within
1:25
Temporal for recovering from that.
1:28
And what's important about it is that the programmer doesn't need
1:32
to do extra work to do that. Of course you can write retry
1:36
logic. Of course you can think about
1:38
distributed systems like you can do it.
1:40
People have been doing, people have been building reliable
1:42
software. But how do you make it easy?
1:45
And that's really what the the breakthrough is with modern
1:49
durable execution in systems like Temporal.
1:52
Plan for the best, but expect the worst.
1:55
Folks that are operating at scale and, and in the cloud,
2:02
maybe not the complete worst, but often, you know, most of the
2:07
worst things that you can imagine.
2:09
Like a lot of those things are actually just going to happen.
2:11
Like that's just the reality of scale.
2:13
That's why they're going to exist.
2:16
What you're doing with durable execution, and I think I
2:18
probably should take a moment to just sort of explain some of the
2:21
mechanics of how it works. But but what you're doing is
2:26
you're basically taking that concern of dealing with making
2:31
things reliable and you're putting it in a piece of
2:34
software, right, which is, you know, say that that temporal
2:38
software, you're saying, OK, we have reliability over here, we
2:41
have business logic over here. And those can be treated as
2:44
separate concerns. And Temporal is open sources,
2:48
MIT licensed. You can run it on top of
2:52
Cassandra or Postgres for your persistence layer.
2:54
You can also use temporal cloud if you want.
2:56
But it's, it's all of the same functionality that you can
2:59
migrate back and forth. Let's talk about how it works
3:04
because this is one of the things that it definitely took
3:08
me a minute to wrap my head around it.
3:10
I think it takes most people a minute to wrap their head around
3:13
it. And then once you kind of get
3:15
it, it, it just, it makes a lot of sense.
3:18
So from the programming model perspective, what you're doing
3:23
is you're working with an abstraction that is going to
3:30
basically cover up a lot of the things that are complicated
3:33
about distributed systems. So you're going to be working
3:35
not with servers as your building blocks, but with
3:38
programming language level constructs like and in
3:43
particular, these are in our terminology, workflows and
3:48
activities. And each of those are are
3:51
basically just functions, so regular code in whatever
3:53
language you want. And there is a distinction
3:59
between the types of code that you put in those.
4:02
So activities are doing IO and basically they're arbitrary
4:06
code. What makes durable execution
4:09
work is that the workflow code is a restricted program model.
4:17
And in particular, the restriction that we have on that
4:20
is to say, if something goes wrong and we rerun that code,
4:27
provided we give it the same inputs as it had the first time
4:30
it ran, it's going to do the same thing again.
4:33
And so this is called deterministic execution.
4:36
It's what you get in, you know, normal code if you have, you
4:39
know, 4 loops. As long as you're not calling,
4:41
say, a random number generator. Or an LLM.
4:44
Or an LLM, which is sort of the obvious case for for an
4:49
activity, then it's going to do the same thing, right?
4:53
And so for example, if you are coding an agent with Temporal or
4:58
if you're using one of our integrations in general, that
5:01
agentic loop, right, that is workflow code, right?
5:06
And because what is it doing? It's it's iterating over calling
5:10
the LLM, calling tools, calling the LLM, calling tools until
5:14
it's done, OK, that's, that's a deterministic program that does
5:18
that. And then whenever those
5:20
activities which are say tool calls, maybe calling an API or
5:24
calling an LLM, whenever those are made, whenever that result
5:28
comes back, what happens in the Temporal SDK is that it takes
5:33
that result and it saves it out to the temporal server.
5:39
So that's where it's captured durably in temporal server,
5:42
which is going to be backed by a database or by Temporal cloud.
5:45
In the case of cloud, it can even be replicated to multiple
5:50
cloud regions, right? So, you know, we, we actually
5:53
see this when say you have a major cloud provider outage, you
5:56
have a a region go down, you can actually take a running program
6:00
like mid execution and move that from one region to another
6:04
region, which is just a whole nother level of reliability.
6:07
And when you think about it, we think about, oh, I could do,
6:09
maybe I could replicate my database, right.
6:13
Will a database move a running query?
6:15
Is there any database? I haven't done exhaustive
6:17
research, but that will move a running query from one region to
6:20
another when it fails. And what about exactly?
6:23
Yeah. Or when that region fails or a
6:24
business process. So that's the type of thing that
6:27
this model lets you do. And it lets you do it with your
6:31
regular programming, like regular code.
6:34
And I think that's, I mean, that's basically the thing
6:36
that's so brilliant about it where I give the founders and
6:39
the, you know, the other folks who are innovating on this like
6:42
a just a ton of credit for figuring this out.
6:44
If we're not using durable execution, what does that look
6:47
like? Yeah, there's a bunch of
6:49
different things that that people do.
6:51
So I'll say there's some folks who just build systems that are
6:53
just not that reliable, right? And those are the folks that I,
6:57
I built them in my day too. And that means that you are
7:01
spending a bunch of time chasing down what went wrong.
7:05
You're going to write some scripts against the database,
7:07
right? And you're going to say, hey,
7:09
you know, maybe I had a transaction.
7:11
I was, maybe I'm doing something simple.
7:12
Let's just say we always take the money moving example, debit
7:14
credit, right? Can I write a job that goes
7:17
through at the end of the day and figures out where things
7:20
broke and then writes a script to to fix all those I can do it,
7:24
right? It's like it's kind of doable.
7:28
Do I want to do that? Is that robust?
7:29
Is that reliable? Does that scale to a team and
7:31
complex functionality? What if there's like more
7:34
business logic? What if it's not just debit,
7:36
credit? What if there's, you know, some
7:39
checks that you know, know your customer, any of these kinds of
7:41
things, right? It it's going to get really
7:44
messy really, really fast. So then kind of another level on
7:48
top of that is people say, OK, well now I'm going to start to
7:53
use event driven architecture, I'm going to start having queues
7:56
and I'm going to put my process together this way.
7:59
And so again, can you do it? Like, yes, you can do it.
8:03
You can cover all the edge cases, You can have the dead
8:05
letter queues and you can have the compensation logic and you
8:07
can do all of that, right? Like you can do it with a
8:12
durable execution abstraction. That code just becomes really
8:16
simple. It gets cleaned up.
8:17
You make sure that activity code on a piece by piece basis is
8:20
item potent in terms of the operations on the database.
8:23
That maybe basically means you have some key.
8:25
If that key, you know the customer key, the transaction ID
8:27
is unique. It'll anytime it retries, it'll
8:30
just you know, it'll, it'll fail out.
8:32
It'll make sure it gets done exactly once and then it, it
8:36
really cleans that up. And then, you know, I, I'd say
8:43
another class that we're seeing now, particularly with the
8:46
agentic systems is that you have checkpoint based solutions.
8:50
OK, So what is a checkpoint? A checkpoint basically means
8:53
take my entire program state, save it down.
8:56
You also see this often in machine learning training, for
8:59
example. And you know, checkpoints are
9:02
OK, right? But they are coarse grained,
9:07
generally speaking. So if you are in the middle of
9:11
say, multiple tool calls or maybe you have a human in the
9:15
loop interaction, it's not clear that that point in the code is
9:20
going to necessarily be a good point to write a checkpoint.
9:23
And on top of that, you're going to have to write checkpoint
9:27
logic. And there's some frameworks
9:30
that, you know, do an OK job of sort of hiding some of the work
9:33
of writing a checkpoint logic. But in in the general case, you
9:38
know, you're still writing a function to take all my state,
9:42
save it out and bring it back. And then you're getting more
9:45
coarse grained recovery. So I thought this was a form of
9:49
checkpointing. How is it different?
9:51
Yeah. So I think you can define the
9:57
terminology potentially in in different ways.
10:00
If I were to think about say just set aside code and just
10:04
talk about maybe something like file systems or backups, right?
10:08
Where I could say, OK, well, I'm going to snapshot this file
10:11
system and then maybe I'll do some incremental backups or
10:14
incremental snapshot updates. It's basically doing it
10:21
incrementally in the sense that you have some, some starting
10:25
state, which in general is, is, is nothing, right?
10:28
It's just the program starts, maybe has some initial
10:30
arguments. And then as it runs and as it
10:33
interacts with other systems, with tools, with, with LMS, it's
10:37
getting sort of the incremental deltas to each state and that's
10:41
being saved. And then because we have certain
10:45
guarantees about how that program runs, we can apply those
10:51
deltas back to that state for programs that do run for a
10:57
extended period of time. So you have an agent that's
11:00
going to run forever. You may also with temporal find
11:04
points where you say, OK, you know what, this is where I'm
11:07
going to save a full snapshot of my state.
11:10
It's just gotten too big of a history.
11:12
And oh, and, and it's a good point for me to do it right.
11:14
And in some cases like that top of that, say, say it's a chat,
11:18
you know, the top of that loop where you say, OK, now we're
11:20
pausing the agent, let's see whether what the user wants to
11:23
do next. That can be a place where we can
11:25
say OK. And it in temporal language is
11:28
called continuous new. And now we basically do a, you
11:32
know, a full checkpoint. But it is, you know, the, the
11:35
durable execution model, it is a different abstraction and it's,
11:41
you know, the, the IT gives you what a checkpoint would give
11:45
you. But with it's a very different
11:47
way of doing it. And that's what we call it,
11:48
something. Is it right to assume that
11:51
basically you're guaranteeing the end goal in a way like
11:58
you're saying? OK, a checkpoint is more for
12:01
it's almost reactive, like I'm checkpointing along the way so
12:05
that if shit hits the fan, I can come back to that checkpoint.
12:10
But you're saying like we're going to guarantee you, we get
12:12
to the end. You don't necessarily need to
12:14
know if we if shit hit the fan along the way.
12:18
Absolutely. You don't need to know about it
12:20
and you actually also don't need to think about writing that save
12:26
code in most situations. I'll say there is this.
12:29
Like I said, you can do the continuous new, you can do
12:32
checkpoints for things that are going to run for a long time and
12:35
generate state for a long period of time.
12:37
Temporal jobs can run forever, right?
12:40
I, I said they make sure they run to completion.
12:42
It's whatever that is. That actually could be Infinity,
12:46
but but but yeah, if if you're doing, say you're doing, you
12:50
know, model training or something like that, you'd be
12:53
probably be familiar with, you know, you get to a certain
12:55
point, you say, OK, now would be a good time to save a
12:57
checkpoint, right? Maybe I've, I've done a passive
12:59
fan out and and and back, OK, checkpoint this thing.
13:03
Or maybe I've after so many iterations or steps, write a
13:06
checkpoint and then I have to write also the code to recover,
13:10
which is to read that checkpoint.
13:13
If I have one single program that does one thing linearly,
13:18
OK, maybe I can do that. Maybe that, that that's not so
13:21
bad, right? It's but if things are branching
13:24
out, right, if I'm doing hyper parameter optimization, I've got
13:27
like a whole bunch of these that are running in parallel.
13:30
And then maybe they also sometimes you communicate and
13:34
feed updates back to each other. Now sort of getting clean
13:38
checkpoints across a sort of concurrent program like that
13:45
basically doesn't really work. Yeah, it's like a It's like
13:51
Santa Claus. It's nice in theory, but it
13:54
doesn't exist. Yeah, don't tell my kids.
13:58
Yeah. Exactly.
13:59
We used to in Spain, there was a moment that we would joke when
14:05
something was like, not real. You'll be like, oh, it's the
14:09
parents. That was the same like Santa
14:12
Claus. It doesn't exist.
14:13
It's the parents kind of alluding to that.
14:16
So OK, I'm getting a better idea of it now.
14:21
You're a databases guy though, right?
14:23
Through and through. And I.
14:26
Have a lot of time in databases. Like marry these two worlds for
14:28
me. Yeah.
14:30
So prior to being at Temporal I had actually started a company
14:36
that was in the database space looking at serverless database
14:39
and also AI for database administration.
14:43
So Crystal DBA Company was acquired by Temporal last
14:46
summer. Congrats.
14:47
So thank you. So what was really interesting
14:52
there when we did we did that acquisition was actually the
14:56
missions of the companies were basically the same even though
15:01
the technology was actually quite different.
15:05
So at the end of the day, when we think about databases and and
15:13
temporal, it's about making the systems run reliably without
15:18
developers needing to think about it, right.
15:21
So if you think about where the that sort of just write the code
15:28
and put it in some system and it'll just it'll do the right
15:31
thing. Where does that happen?
15:32
Actually, it happens in these transactional database systems,
15:35
right? They give you those guarantees
15:37
of it'll run end to end. It'll make all the changes.
15:41
Now there are a bunch of drawbacks there.
15:45
So one is, is that you're often writing in some arcane language
15:50
that the basically nobody, you know, whether whether it's, you
15:55
know, PL. sequel or the, the Postgres, everybody's kind of
15:59
got their own variant of it that just works for that one specific
16:01
database. No standards.
16:03
And just a really, you know, take me back to the, to the 80s
16:08
or 90s typically, like in terms of programming language style
16:11
and capability. And you know, I can't, can't
16:14
define things the way I normally do so on and so forth.
16:17
So what you're getting with modern durable execution is
16:24
you're getting that guarantee basically of my software is, you
16:28
know, bulletproof. It does what it's supposed to do
16:32
and you're getting it with whatever programming language
16:34
you want. Now, I, you know, I, I, I will
16:37
say there, there are some things that databases give you in
16:40
addition. So for example, they give you
16:44
sort of a, a, a consistency model around the way that
16:49
different programs interact that the durable execution doesn't do
16:53
on its own. Maybe it will someday, I don't
16:55
know. But definitely being able to
16:58
just bring it to regular programming languages is just a
17:02
huge thing. That like guarantee that you get
17:04
is only in the database. That's, I mean, that's the other
17:07
big thing is that if, if you are monolithic, right, if if your
17:13
application is, you know, one database and 1, you know, front
17:20
end or something like that, then great.
17:22
What happens if I have more than one database?
17:25
Basically everyone does. 100% unless you're, you know, super
17:29
small, yeah. Like you're going to have,
17:31
you're going to have all the old systems.
17:33
Yeah, exactly. You're going to have your,
17:35
you're going to have your older systems and your newer, you
17:36
know, your, your legacy, the one that's coming next.
17:39
You have to be able to connect all that together and, and
17:42
that's why you really want to take that understanding of
17:47
reliability basically and basically just put it in a box
17:51
and say, OK, it's handled over here.
17:55
If you're on temporal cloud, you know, it's, it's handled by
17:58
these folks who by the way, there's a like more than half, I
18:03
think of the engineering organization at Temporal
18:06
actually just works on making the cloud thing reliable.
18:09
Oh, nice. And and and and scale.
18:11
Well, I would hope. That, yeah.
18:12
So, so, so there's just like there's like a whole bunch of
18:14
people who work on doing that and doing that really, really
18:18
well, which is why so many top brands trust Temporal to, to run
18:25
the durable execution for them. Who do you normally have using
18:30
it? Is it the Sr.
18:31
ES that are bringing it in? Like who's champion for
18:34
Temporal? So there are a couple of
18:37
patterns that we're seeing more emerge. 1 is that in
18:43
organizations that have platform teams, the platform team is
18:46
often the owner for temporal and.
18:50
Well, because they're the ones that get called, right?
18:53
Yes, and and they are. They're the ones who have a
18:56
responsibility. You have a platform team, so
18:58
somebody's gonna say, OK, reliable infrastructure,
19:01
somebody owns that, somebody's measuring it, somebody is.
19:07
But, but also I'd I'd say developer productivity, right?
19:11
Because the idea of a platform team is, hey, let's have some
19:14
shared infrastructure so that all of our other teams can move
19:17
faster and that we can kind of have some standards and best
19:20
practices around that. Different orgs do it in
19:22
different ways, but the productivity angle of Temporal
19:26
also really plays into that where you know, we see platform
19:29
teams that say, OK, we could, we could offer this to our
19:32
developers and and then all the application teams can just build
19:36
a lot faster. There's like flavors of airflow,
19:40
right? There's flavors of like Argo
19:42
workflows. How do you kind of like place
19:46
yourself in that market map? I'd say Airflow is relatively
19:54
domain specific, you know, ETL data movement and you could
20:02
build an Airflow with temporal with durable execution.
20:06
And, and we actually, I, I think some of our customers
20:11
effectively do that. They build their own sort of in
20:13
house frameworks for for different sorts of processes.
20:16
Oh, I'm not saying that that they're running.
20:19
Airflow exactly, but they will do Airflow like things maybe
20:22
with their own framework, you know, which connects to their
20:25
data sources and syncs and so forth.
20:28
We definitely have folks who build DAG executors on top of
20:32
Temporal. That's sort of a, a, a normal
20:35
thing to do. Temporal is it's, it's a more
20:39
general programming model. It's it's, it's sort of the one
20:41
of the key things. And so where you see that
20:46
displacing things like Airflow sometimes, is that OK?
20:49
If I needed to ETLA bunch of records, maybe Airflow's the
20:52
right solution for that, right? But if I am say, say I got a
20:57
dump of legal documents and media files and other sorts of
21:02
things, I need to go, I need to figure out what these things
21:04
are, maybe do some enhancement on them.
21:07
And then maybe I'll either dump them somewhere else or I will
21:12
maybe index them, You know, either an elastic or, or, or a
21:16
vector database of some kind. The code that you write for that
21:24
is not necessarily most naturally expressed as a DAG or
21:27
something like like just write Python code, right?
21:30
Call these different things and run it with durable execution.
21:34
And then, you know, you'll make sure that you're not missing
21:37
page four O 6 or or whatever it is.
21:40
OK, can you give me more examples like that?
21:42
Yeah, hyperparameter optimization.
21:44
So, you know, I can write a driver program for that as a
21:48
Python script. And as long as the server that
21:50
I'm running that on, maybe it's even my laptop, as long as that
21:52
doesn't crash, right? Great.
21:57
Now, if I want to say close my laptop and walk away or if I
22:05
maybe have that running for a for a longer period of time,
22:08
right, even over overnight, maybe even for a week.
22:10
And that job could, you know, who knows what will happen in
22:14
the cloud with that VM? Maybe I put it on a on a virtual
22:16
machine in the cloud. You don't have to basically
22:19
worry about any of that with temporal because what it really
22:23
does is, is it the the actual part of the program that
22:28
matters, which is the program state, right?
22:30
Essentially compute is it's all essentially ephemeral
22:33
fundamental. You can replace the compute.
22:35
What matters is the state and the state of that program.
22:38
Which iteration is it odd on on which roll out and all that is
22:42
going to be saved in the server. And then there's a, you know, a
22:45
server process that knows that if any of the compute resources
22:49
go away, you know that that it needs to go find someplace to
22:53
run that again. In a way it's like the idea of
23:01
like this declarative type of stuff where you just say, hey
23:04
look, I wanna declare this, I don't care how you figure out
23:09
what is gonna happen. Like abstract all that away from
23:12
me and just make sure that what I declare is what happens.
23:17
And, and to make that concrete, I'm gonna declare something like
23:20
here is my program, Python, TypeScript, whatever you name
23:23
it, here's my program. And I've put that on a on a
23:27
server. So, so the way it works in terms
23:29
of the model is that we talked about the temporal server that's
23:32
holding the state backed by a database or the cloud.
23:36
There is sort of the, the, the worker which is going to be
23:40
listening on that server and saying, what should I run?
23:44
And then you'll have a client which is going to be sort of the
23:47
declaration of go run this workflow.
23:49
These are the arguments. Go run that code with these
23:51
arguments. Once that acts, and once that
23:53
returns, it's going to go make it happen.
23:56
Yeah, it reminds me of the Kubernetes philosophy, very much
24:00
like just. Yep, here's what I want system
24:04
go figure it out. Exactly.
24:05
Yep, in terms of other examples, agents are are definitely.
24:11
Well, that was kind of where I was gonna go.
24:13
Is it probably gets a little bit more messy when you have agents
24:18
doing this right because. So it, it could so, but, but
24:23
actually it, it works pretty well.
24:25
So, so there's a misconception that's out there a little bit
24:27
that people have. And I, I understand it can be
24:30
confusing when you think about LLMS being non deterministic and
24:34
then you say, well, wait a minute, but there's this like
24:36
deterministic execution thing. And so how is that going to
24:41
work? Like is that even going to work?
24:43
Can I even use durable execution with, with LLMS?
24:46
I think as we talked about before, that agentic loop
24:51
actually is deterministic code. It's not the output.
24:55
The, the output of the LLMS, even if it's controlling so, so
24:59
the difference with an LLM and with an agent really versus say
25:03
other types of LLM enabled applications, is that the
25:11
control flow at the end of the day, do I continue, do I call a
25:15
tool is going to be dictated by the LLM responses, right?
25:20
Versus perhaps one of those document processing examples
25:25
where, yeah, you're still using LMS, but you're going to say
25:28
apply transformation, ABC, summarize and so forth.
25:31
And so, so that's, that's sort of very, it's actually a big use
25:34
case, right? But that's sort of 1 box of of
25:37
uses. And then and which is basically
25:39
non agentic AI. It's still AI, it's still
25:41
generated by it's still LMS, it's still really cool, really
25:43
useful new, but it's not agentic.
25:46
So agentic now the the LM is going to decide what to do next.
25:50
But effectively the way that works with with temporal is that
25:53
that is still that's like state relative to the workflow of LLM
25:59
said call this tool that comes back in an activity and then,
26:03
you know, we we run it and it's captured and it's captured
26:05
durably. Where we see a lot of additional
26:09
value for temporal in in agents is a long running, right.
26:16
So if you are say monitoring something or or or you have some
26:22
business process. And now we're seeing a lot more
26:24
of this too with, you know, the emergent open car type uses
26:28
where things are running on timers, right?
26:30
It's in the name. It's kind of obvious, but yeah,
26:32
but but like that, that that's just like super supernatural of
26:35
like, OK, this is going to run every half hour every day at
26:39
3:00 PM, whatever it is, it's going to check something and
26:42
then you have to wake stuff up. You have to do whatever whatever
26:44
you need to do, you have to remember where you were and then
26:46
you're going to go back to sleep for a while.
26:48
And the important thing there is that you don't need to have
26:52
compute resources for that. What matters while it's sleeping
26:56
is just OK, what is the state? Where was I?
26:58
So all that is saved in in the server and and and then, you
27:04
know, it's basically brought back and rehydrated to whatever
27:07
it was in that code path at that right time.
27:10
The other case that's pretty valuable is for human in the
27:15
loop. Really we talk about humans, but
27:18
frankly it's it's any sort of interaction with outside world.
27:21
So if it was a human, it could be OK, I am getting to a certain
27:25
point and then maybe I have a tool call that is actually going
27:29
to go generate a a, a, a document for signature and send
27:32
it out for E signature and then continue when it gets that back
27:36
right. And so maybe that's going to be
27:39
quick, maybe that's not going to be quick.
27:40
We don't really know. If it's not quick, we want to be
27:42
able to reclaim the resources which are basically in the
27:45
temporal. Those are going to be cache
27:46
compute resources and then it'll just come right back to where
27:49
that was and, and continue in that flow.
27:53
But you can also, you know, you can also set a timer on top of
27:57
that, which you say, oh, it hasn't been signed it, you know,
28:00
and it's been, you know, six hours or or 24 hours or whatever
28:03
it is. OK, great.
28:04
Now you know, we're going to kick a reminder or we're going
28:07
to expire it or actually somebody came along and said we
28:10
have to retract this. And so one of the things that
28:13
temporal lets you do that actually some of the other
28:16
durable execution frameworks don't quite have the same level
28:18
of flexibility is it allows you to have interactions with that
28:24
running workflow program through what what we call signals,
28:31
updates and queries. So you can basically write these
28:33
handlers that sit in that class. You've got your entry point kind
28:38
of your main function, right? But then you can have these
28:41
other pieces of code and they're basically they're they're
28:43
running in that environment. And so if that is, you know,
28:48
some sort of, oh, we changed our mind or, or whatever it is,
28:52
it'll just come right in there and it'll interact with all that
28:54
state in that program and it'll do whatever it needs to do, take
28:58
it back and and, and just, and just execute chip with regular
29:03
code. Tell me more about that, because
29:05
that that sounds fascinating is it's almost in a way you've got
29:09
this scale to 0 like serverless type of style.
29:13
And then you've also got these little side quests or what
29:19
different types of pathways that you can go down if else
29:24
statements, if do, if this happens, then we've got this
29:27
logic over here that you can go and you can run.
29:29
Yep, it's. It is in your workflow, right?
29:33
It is a regular. Let's let's focus on Python.
29:39
So with Python, you tend to have an async await style of
29:44
programming and so you can have concurrent things happening at
29:47
different times, right? And in temporal, what we've
29:51
actually done is we've replaced in in our SDK, we've replaced
29:55
Python's event loop, it's async event loop with a deterministic
30:00
one that basically makes sure that the interleaving on replay
30:04
is, is always going to be exactly the same.
30:07
And so that allows you to do any of the things that you do with
30:13
concurrent programming like, you know, having queues and handlers
30:16
and stuff like that. If you could, you could, you
30:17
could basically you get your full concurrent programming
30:21
model inside of this durable execution.
30:26
So, so you know, oh, I ran something, oh, maybe it's, maybe
30:30
it's taking too long for that thing to finish and I need to
30:33
get a response back to a customer, right.
30:36
OK, set it, set it just just sleep.
30:38
We, we replace the, the, the sleep function, right?
30:43
So that it's, instead of just doing the system sleep, it's
30:46
going to be temporal sleep. And then that means that if it's
30:50
short, you know, at least it'll be, it'll actually keep it
30:53
cache, it'll be deterministic and durable.
30:57
So if it did crash during that sleep, it would recover.
31:01
But then if it's long, we'll actually effectively
31:03
intentionally crash it. We'll clear the cache, flush it
31:06
out, reclaim the resources and then come back again.
31:09
But yeah, full, full, full programming model.
31:10
That's that's the thing that's really different about durable
31:14
execution. How are you seeing folks take
31:17
advantage of this? Because I instantly am thinking
31:19
about the open clause situation and and thinking, Oh well, what
31:24
I would do is just probably program in hey, every X amount
31:29
of time, just wake up the LLM or send off something to an LLM
31:35
with context. Here's what's happened.
31:37
Here's all of the definition. There are a bunch of folks who
31:43
build on top of temporal directly and who build different
31:46
sorts of experiences. You know, I can't go into the
31:50
specifics of the details, but I, you know, I can tell you that in
31:55
addition to open eyes codecs on the web, we have repple it and
32:00
and lovable and they they, they use temporal as as as do a bunch
32:04
of other folks. And so just using those
32:10
primitives, you can build very sort of from the ground up, very
32:16
robust agentic systems. Now, another thing that we've
32:21
actually done is we've done a number of integrations with some
32:27
of the leading agent frameworks. So for example, Open AI Agents
32:31
SDK, Pedantic AI, AISDK by Versal, those are ones that have
32:39
been released. We're continuing to work on
32:41
others. We have integrated with Brain
32:45
Trust on the observability side, we've integrated with Lang Fuse.
32:49
So our goal with our integrations is really to give
32:56
users choice of basically what pieces of the AI ecosystem do
33:03
you want to bring in and use to build your agentic system,
33:08
right? And let us handle the
33:11
durability. Let us make it reliable.
33:14
Let us give you the ability to use these sort of primitives to
33:20
to send messages and queries and kind of ask the agent, what are
33:25
you doing right now, right? And, and things like that.
33:28
Those are all things that come with a temporal programming
33:30
model and that by when we integrate with those frameworks
33:35
it makes it easy for you to access it.
33:36
Yeah, I was thinking exactly that, where you're almost using
33:42
the temporal state, feeding that to the agent to say here's where
33:45
we're at now, what should you do next?
33:48
Yeah, it's, it's really just separating different concerns.
33:54
So the temporal state is your program state.
33:56
I mean, another way to think about it is, you know, whatever
33:59
your stack and, and memory state is is effectively protected by
34:04
temporal, but it's it's your programming language state,
34:06
right? Where are you in terms of that
34:10
execution path? And then the agent framework is
34:14
about making it easy to put together, you know, multiple
34:21
agents and guardrails or increasingly now what we're
34:25
seeing the coding agents and the file systems and all these other
34:27
pieces, it's actually moving towards almost this new
34:30
category, which is the harnesses, right?
34:34
And so it's all evolving quickly.
34:35
We're we're we're evolving with that ecosystem.
34:38
But the key thing is, is really just kind of it's all about
34:45
developer productivity, but different aspects of developer
34:47
productivity, right? Here's some common patterns for
34:50
building agentic systems. OK, boom, agent SDKI want it
34:54
interacting with the world. I want it long running reliable
34:58
async temporal. OK, so now can you break down
35:04
like what do I do first? OK, so the way that you start is
35:10
you really have have two options.
35:11
You can either download the temporal CLI and run it on your
35:14
laptop, which is a totally good way to do it.
35:17
You can also start on Temporal cloud, but you do need a
35:19
temporal server of of some kind and then you get the SDK.
35:23
These days. What I would recommend that you
35:25
do, frankly, is that you just grab your favorite coding agent.
35:29
I create a project. We have a temporal skill and you
35:36
know, probably just ask it to to build you a hello world.
35:39
Look, we've got great documentation.
35:40
We've got tutorials on the website and so forth, which
35:44
which I definitely encourage people to to look at as well.
35:48
But they if, if you want to be forward-looking and if you kind
35:51
of want to see where we're going with some of this stuff is like
35:54
actually just say, you know, Hey, agent, teach me, teach me
35:58
temporal. Yeah, that's a common pattern
36:01
that I've heard folks talking about is how before they'll jump
36:04
into any new, whether it's a new programming language or a new
36:10
new tool, yes, they'll ask the chat, yes, give me some of the
36:16
the TLDR and then go a little bit deeper.
36:18
And then once you have this mental model of how it works,
36:22
you can then start using the tool much more effectively.
36:27
Grab the skill because that that will ensure sort of the
36:31
consistency that the LMS of the foundation models are, are
36:33
pretty good. They understand temporal pretty
36:35
well, but there are, you know, certain edge cases and gosh, I
36:39
mean, we, we, we know that LMS aren't always perfect and the
36:42
scale will will definitely accelerate that.
36:45
Yeah, it feels like right now in this conversation we've
36:48
established what it does and why you would want to use it, right
36:53
Then maybe the next step is all right now I'm using it.
36:56
What are some things that I should be focusing on while
36:59
using it? Yeah.
37:02
So I definitely recommend that people spend a little bit of
37:07
time wrapping their head around the model.
37:10
Some of this it just because it's a little bit different
37:15
sometimes. I, I, I think if you just focus
37:18
on and understand it, then you'll be good.
37:19
But, but just understanding like, OK, I'm going to have this
37:22
worker, right, Which is where the code actually runs.
37:27
I'm going to have a starter program that's going to be the
37:30
client that initiates that code. And then I'm going to have the
37:34
temporal server backed by, you know, whatever reliable back end
37:37
it has. And those are kind of the
37:39
different pieces. So, so making sure you
37:41
understand that part of the model, making sure you
37:43
understand that you have activities, activities do
37:46
anything and you have workflow restricted and, and that's kind
37:50
of the model. So really thinking about, well,
37:51
how do I break my program up into these pieces?
37:54
The simple question to ask usually is, does it do IO,
37:58
right? If it does IO, that means it's
38:00
going in an activity, right? Because that means that state
38:03
that's going to come in that we need to save and then yeah, you
38:07
know, work on modeling your problem.
38:09
We have a number of sample applications.
38:13
We have an AI cookbook that we're continuing to add recipes
38:17
to. And so those are good to sort of
38:20
sort of pull from and you can kind of see how, if there's
38:24
something that matches what you're trying to do.
38:26
And then the other thing that I encourage folks to do is to use
38:30
the temporal UI. So that's when the, if you start
38:34
up the CLI, if you go to the cloud, it'll just be there.
38:37
If you start up the, the, the server on your local
38:41
environment, you'll get a URL. You click that, you open it up
38:44
and basically what you can then see is you can see the program
38:48
executing. So you can see, you know, the,
38:51
the, the, the workflow, you can see the activities, you can dive
38:54
in, you can see the arguments, the return values, you can see
38:57
any sort of retries, you can see failures.
39:00
And actually one of the cool things that I encourage folks to
39:04
do this, this kind of blew my mind when I, when I first saw
39:08
it, is that suppose you write your code and you're, you're
39:12
like, you're just developing right?
39:14
And you did something wrong, right, Or, or, or your coding
39:18
agent did something wrong. There's a bug, it's a syntax
39:21
error, whatever Python blows up 3/4 of the way through whatever.
39:26
So what you can do now is you can just go.
39:30
You can fix that error. Save the file.
39:34
I know where you're going. Restart the server and that'll
39:37
just finish and so that's obviously can save you time in
39:42
on your local development loop. But also, if you think about if
39:47
I've set some job to run right, this is always my fear.
39:51
And you know, that's, look, I'm, it's great to use, you know, to
39:54
type annotations and other stuff in Python to try to reduce this.
39:57
But definitely like you kick that job off, it runs for a week
40:00
and now it's broken and because of something silly, right?
40:05
And now you're like, OK, well, I kind of have the pieces, I can
40:08
pull them together and I can write a new program that will
40:11
pick up kind of from where that one broke.
40:12
And like, I'll do that. But it's.
40:14
But with temporal you. With temporal you don't do that.
40:17
You just like fix the thing and then the thing finishes.
40:19
It remembers where it broke. It remembers where it broke.
40:21
Yes it can. It can.
40:22
It can move to the new version of the code, yeah.
40:26
It also makes me think there's a lot of time we talk about
40:29
memory, right, for agents and we talk about there's the
40:32
personalization side of memory and then there's the I did
40:37
something as an agent and so how do I remember how I completed
40:42
that kind of is moving in that direction a little bit it.
40:46
Is so one of the things that's that's interesting about
40:49
temporal and this is kind of where I think 2026, frankly, we
40:54
know it's going to be a wild year and and we'll see how
40:57
things play out. So the file system has been sort
41:02
of the main repository for for memory in most of these agents.
41:06
Certainly something like open clause is using the file system.
41:10
You know, if I'm using cloud code, it's sort of keeping the
41:13
session history and in the file system and so forth.
41:16
And you know, and and and that's OK.
41:19
And, and you can build file system enabled agents and
41:26
applications with temporal. But actually you don't
41:29
necessarily need a file system for a depending for for a lot of
41:32
agents. So if you're going to be
41:34
generating code, running scripts, doing sort of
41:37
sophisticated computer use type tools, then you probably want a
41:43
file system. If your agent is calling AP is
41:49
and and, and LMS working with databases, then you can probably
41:55
keep all the state that you need in temporal, right?
41:59
And certainly if it is sort of that episodic memory relating to
42:05
a particular session, then that should be totally fine for
42:10
memory that that sort of crosses sessions.
42:12
Then I think frankly that's the area where we're still sort of
42:16
experimenting and exploring things.
42:18
And, and frankly, the the whole ecosystem is both terms, terms
42:21
of how do you structure it and then where do you put it?
42:24
And how memory is such a a fascinating one because you want
42:29
that memory, but you don't want to leak that memory too if
42:32
there's different things that are, if you're going across
42:35
sessions and they're not the same person for that same.
42:41
Session you'll you'll get a level of isolation just kind of
42:46
out-of-the-box where basically every workflow, which is
42:49
basically every invocation of that you know of that workflow
42:54
is basically private and that that's just part of your
42:58
programming languages isolation model.
43:00
You can put more isolation on that, right.
43:03
So if you want to, you know, run inside of, of containers or
43:08
isolates or web assembly or like you, you, you can do that.
43:13
But I think that where it gets really interesting.
43:15
And to be clear, we don't have any solutions or products since
43:18
there it's just the kind of stuff I like to think about is
43:23
how you control that flow of context even within, well, let's
43:27
say maybe it's, it's hierarchical, right?
43:30
Because I have it within my, you know, within my different tasks
43:34
for myself personally. But then maybe I do want to
43:37
share contacts with my team right at some level.
43:40
So like how do I make that? Happen.
43:42
Yeah, much like Google Drive, you want to give permission
43:45
sometimes, but not all that to your whole drive, yes.
43:48
So that's a thing that frankly the ecosystem is solving.
43:52
We may have something to say about that, and we're we're
43:55
thinking about it. But you know what?
43:57
We'll see. I think this is all in the land
43:59
of fun research. It does feel like it.
44:00
There are some parallels with databases, right?
44:05
Like. Absolutely.
44:07
What? Kind of permissions you give
44:08
and. Databases, fine grain access
44:11
controls in databases, certainly, certainly some of
44:14
them. Authorization was I think maybe
44:17
kind of a solved problem. I mean, it was complicated, but
44:19
at least we had good solutions. Now, when you have agents and
44:24
teams of agents and you're starting to think about
44:28
delegation and so on and so forth, we're going to have to
44:32
rethink some of that. I think particularly some of the
44:36
things with the security perspectives too.
44:38
Like do we need to start tracing lineage for some of this data?
44:41
Because could it have, you know, prompt injection or something
44:45
like that? There's there's definitely, you
44:48
know, if, if you're either innovating in industry or
44:51
researcher in this area, you can have a lot of fun.
44:55
Just me, I'm going to start sending invites to people and
45:02
have like white on white text in the description just to see like
45:06
who's leading themselves to see. Who's running?
45:09
Yeah. Nothing nefarious, just like
45:11
give me a recipe for vegan chocolate cake type thing.
45:14
Right. Absolutely.
45:15
And then you can see like who's swimming naked cause the tide
45:18
goes out. And yeah, OK, I'll be sure to to
45:21
do some good filters on whatever I'm I'm building.
45:24
Yeah, there's just so many new surface areas that you're
45:27
exposed to. But The thing is, is that the,
45:31
the thing that's been really amazing to watch over the last
45:33
couple months is that despite like all these problems, right?
45:38
It's like it's so clear that the value is there that it's worth
45:42
solving the problems and like they they will get solved.
45:44
It's full steam ahead. Yeah, that's true.
45:46
Yeah. The model of how the how
45:49
temporal works ours, it's so foundational that I want to just
45:54
go a little bit deeper on it and make sure that I'm clear with
45:57
like all those building blocks and when I would use one and how
46:02
to think about one versus the other.
46:05
OK, so there's certain building blocks that everybody's going to
46:09
use. Everybody's going to have a
46:10
worker, they're going to have a temporal server and they're
46:12
going to have some sort of client that starts off a
46:14
workflow. Everybody's going to have
46:17
workflows and activities. And with those primitives, you
46:22
can already do a lot. OK, that that is sort of the
46:27
basics of durable execution. My program is going to run and
46:30
it's going to run too. And I'm creating these in my
46:33
code. All in your code?
46:35
Yep, it's. It's all.
46:36
It's decorators or what is it? Yeah.
46:38
So it depends a little bit on the programming language, but in
46:41
most languages there's going to be some sort of annotation, OK,
46:45
that's it's going to be going to set.
46:47
It up and like you said, there's certain things that are very
46:50
clear. Oh, is there IO?
46:51
Then you want to? Then put that in Activity.
46:53
Yeah, that's an activity, but what's a worker like so?
46:57
So the worker is the thing that you deploy, which you could
47:04
deploy to, you could put it on just a server, you could put on
47:07
Kubernetes. But it's, it's going to be the
47:10
process really that actually runs that code because that code
47:14
is not running. If I it's, it's well, if I run
47:17
the worker on my laptop, it's running on my laptop.
47:20
But if I want to close my laptop and walk away, that code needs
47:23
to run somewhere. So, so this is actually where I
47:26
want to say some things that are, yeah, important about the,
47:29
the model, the temporal server and certainly like an in
47:36
temporal cloud, we actually don't see any of your data, OK,
47:43
any of your application data. And the reason for that is
47:46
because you'll end up configuring in, in production,
47:50
you'll configure the client, the temporal client, to encrypt
47:55
everything before it gets sent to the temporal server.
47:59
And then you have the keys. We don't have the keys or, or if
48:05
you're hosting it yourself, you can do the same thing.
48:07
That system doesn't have the data.
48:10
So what does it mean if you can't see the data?
48:12
Well, actually you can't compute on that data either.
48:16
And so that's where you bring up the worker, right?
48:19
And the worker is running in your VPC, your trusted
48:23
environment and and, and that's actually where you're going to
48:28
decrypt the data. And then it's going to run, you
48:31
know, just like it would run ordinarily on decrypted data.
48:34
OK, so the workers where the code gets executed.
48:37
The worker executes the code. Yes, yes.
48:40
And that worker could be, you know, a simple way is, is to
48:45
deploy to some sort of container service and those can be set up
48:49
to auto scale and so forth. But but you can really.
48:53
You can deploy it however you want.
48:54
OK, so you're not dealing with the auto scaling?
48:57
We can give you some signals and so for example, in Kubernetes,
49:01
there is an auto scaling mechanism that can talk to
49:05
temporal server and can say, hey, this thing needs to be
49:08
scaled up. And, and this is actually, it's
49:11
an area where we're continuing to do more work and make it sort
49:16
of more and more transparent for people because ultimately what
49:20
we are driving towards. And frankly, there's a pretty
49:24
deep connection between durable execution and, and, and
49:28
serverless. And so that's really, you know,
49:31
I, I, I would expect, you know, sort of no concrete product Rd.
49:35
maps to, to share right now. But just even just just looking
49:38
at it and looking at the ecosystem as well as the things
49:41
that we're thinking about internally, it just it makes a
49:44
lot of sense to move it more towards the serverless model.
49:46
Well, it's almost like you guarantee the durable execution.
49:53
A way to get out in front of that is before stuff blows up
49:59
you auto scale in case. That's one of the problems.
50:02
I It's almost like you're preemptively trying to do things
50:06
so that you never have to restart.
50:09
So you, you could definitely predictively scale that, that's
50:12
sort of 1 option and and you could think about ways to do
50:16
that. But it, you know, as it pertains
50:21
to service that most server like, OK, if you go back to
50:23
serverless function as a service that is actually mostly
50:26
reactive, but I just found ways to scale it really fast.
50:30
And there's a bunch of tricks that you play and a bunch of bin
50:32
packing. But the way that I think it
50:34
really comes together is that what the sort of promise of
50:38
serverless was originally. And I think what got people so
50:42
excited about why they frankly, why that name attached itself to
50:46
function as a service, which was it actually wasn't, they didn't
50:48
come out and say, hey, this is serverless.
50:50
That was something that sort of the the community attached to
50:52
it. And it, it's this idea that I
51:00
should be able to write the program, save the program to
51:04
this massive computer called the cloud.
51:06
And then that just like the right stuff should happen,
51:09
right? It's like, why would you burn a
51:11
bunch of resources when my program isn't doing anything?
51:14
Like, like, don't do that. Why does my program like break
51:19
in the middle? Like don't do that, right?
51:21
Just just like do the right thing.
51:23
Like, and, and so we can get into all these definitions of
51:26
serverless. And I, I did my PhD on
51:28
serverless. I walked through the mall.
51:31
Is it doesn't mean it's stateless.
51:33
Does it mean this doesn't mean that at the end of the day,
51:37
like, and you know, people start, it's less of a thing now
51:40
because you know, AAI is now the new buzzword.
51:44
It was, you roll back, you know, eight years and it's all about
51:47
serverless, right? You can serverless wash stuff in
51:51
your marketing and whatever. At the end of the day, though,
51:54
it's just like the thing does what it's supposed to do.
51:56
That's all the serverless is that I don't need to worry about
51:59
server nonsense. The parallel there for what
52:03
you're doing with temporal is so clear.
52:05
It, it, it's, it's very connected and, and I think it's,
52:11
it is effectively solving the same problem.
52:13
It's solving the problem of the cloud is just introducing
52:19
complexity. It's giving us a lot of
52:22
benefits, right? It's giving us benefits in in
52:26
scale, it's giving us benefits in the resource elasticity,
52:29
which gives the cost. It gives us benefits of getting
52:32
access to all the types of cool hardware and GPU's and all this
52:34
all these benefits, right. But then you know, it, it does,
52:39
it has in the past had these fundamental, I actually, I'll
52:45
take that back, non fundamental limitations and costs that came
52:51
along with it. And what I think about kind of
52:56
the progression in the last 10 years and really what the what's
53:00
been happening the way I interpret servos is sort of
53:03
taking all those non fundamental awkwardness things away and that
53:08
that's basically what it is. Yeah, you get more room to do
53:14
cool stuff, but when you add this complexity, there's just
53:18
more ways than it breaks. OK.
53:21
So you have the worker that's a fundamental building block.
53:25
You also have different pieces and breakdown these other
53:28
pieces. Yeah.
53:29
So you've got the worker, that's where your code is running.
53:33
You have the server, that's where your state is being made
53:36
durable and and what's being tracked.
53:38
And then you have the the client.
53:40
And then what are you writing on top of that?
53:43
You are writing in terms of these simple primitives, the
53:49
activities, which is where you're doing the IO and the
53:52
workflow, which is the the the control of that, which is sort
53:58
of your main entry point to that program.
54:01
OK, so the workflow is what I'm writing, what we want it to do,
54:06
whatever it is, if it's that document processing pipeline,
54:10
it's do XYZ and that's when it's as it says, you know, workflow.
54:15
So kind of clear. Thing do begin to end.
54:18
It could be my agentic loop. I want you to loop until
54:22
somebody says stop whatever it is.
54:25
And this is on the client. Well, let's see.
54:27
So, so the workflow and the activities, those are running on
54:31
the worker, the client, which you can trigger also from within
54:37
work flows and activities. But what that's going to be
54:40
doing, it's going to be saying that sending the command say to
54:43
start the activity or or to to start the workflow.
54:47
That's and that's where you can have that sleep.
54:50
Yes, yes, we, we actually do have a, a new feature that's
54:53
coming out, which is standalone activities which run if you have
54:57
something simple that needs to to run without even being in a
55:01
workflow, you can do that and you can get the benefits of the
55:05
reliability like that thing is going to run it's guaranteed to
55:08
run it'll be retried and so on and so forth It's all in your
55:10
your dashboards and UI as well. But now we're kind of getting
55:13
into power user features. There are a lot of power user
55:15
features OK there, there are things like, you know,
55:17
schedules, you know, which is think of that like more
55:20
sophisticated Cron functionality.
55:22
We've talked about the signals and and updates.
55:27
We talked about the, you know, the workers being able to update
55:33
to a new version of the code. 1 of the things that we have
55:37
released recently is something called a worker versioning.
55:43
So sometimes you actually don't want to go to the new version of
55:46
the code or maybe you want to do a blue-green deploy or or
55:49
something like that. So for more, more sophisticated
55:52
operators, we provide a lot of control over that.
55:57
We have a feature called workflow pause, which means that
56:00
you can say, you know, either on command or when it maybe it
56:04
encounters some sort of exception condition actually in
56:08
your logic, you can say what what just stop this.
56:11
We're going to look at it before it makes progress, right?
56:15
So there's just, you know, there's a lot of things that are
56:19
continuing to be developed. We are working on some support
56:25
for larger data sizes, large payload storage, right?
56:30
So if you have something that is maybe again, like some of these,
56:34
these media files, you may not want to send them to the
56:37
Temporal server and store them there, even if they're
56:41
encrypted. You, you say, you know what,
56:42
that thing lives in S3, right? Or, or something like that.
56:46
But I want Temporal to understand it.
56:48
I want Temporal to track it. I want to see how large the
56:50
objects are and so forth. So.
56:51
So we have large so. In that case you just send the
56:55
metadata. There are different variants of
56:58
it, but but in in, yes, at the end of the day, what's going to
57:02
happen is is that say that output that got generated, it's
57:07
going to be the temporal client is going to be configured or the
57:11
SDK is going to be configured to go put that in your BLOB
57:15
storage. Remember the path to it and then
57:20
encrypt that. Put that in temporal server
57:22
instead of actually putting the object in temporal server.
57:25
Yeah, just have the pointer. Exactly, exactly.
57:27
It's yes. At the end of the day, we know
57:30
we're talking about pass by reference rather than pass by
57:33
value. So we're doing that, we're doing
57:36
streaming, which is another thing that's really important in
57:41
agentic use case. You actually have pretty good
57:44
support for it out-of-the-box. People do it all the time with
57:46
Temporal today, either using the, the basic primitives, you
57:51
know, updates and, and, and signals and queries or sometimes
57:57
using third party storage or, or third party streaming like
58:00
Reddit streams, for example. So there's a bunch of different
58:03
ways that you can do it. We're making it first class.
58:06
So that's another thing that you know that we're.
58:08
Working with use cases. For streaming like.
58:10
Audio. I so, so certainly audio is one
58:14
of the use cases where we have folks that that have agentic
58:17
applications that are audio applications.
58:20
And then it's also just any sort of updates that you're going to
58:26
get in between your main interaction.
58:31
So if I am say in a coding agent and that coding agent is telling
58:35
me that it's running a bunch of tools and checking these files
58:38
and doing other things, those are all from the perspective of
58:41
AUIA streaming update, right? So it's, it's basically saying
58:46
that you don't wait until the end of the workflow or, or until
58:53
a point of pause or, or human input in order to say what
59:00
you're doing. And then of course, you combine
59:02
that with things like the, the signals.
59:06
Now you can start doing interruption, right?
59:07
Because I said, oh, wait a minute, I don't want you doing
59:09
that. I want you doing something else.
59:11
Those are additional things where, you know, there's layers
59:15
upon layers of functionality that, that you can access.
59:18
I think the good thing is that you don't have to start with all
59:24
of that. And I think increasingly now,
59:28
you know, we'll see, but I expect that you're going to be
59:32
able to access pretty much all the features through your coding
59:35
agent just by asking for it. You know, we, we, we, we've been
59:39
doing this skill and it, you know, we, we put it all in there
59:41
and. We really.
59:42
Should be able to do it. The coding agents are pretty
59:44
good. The thing that I see is you have
59:47
to know what to ask for. So that's the new thing.
59:50
And that's why I think it's, it's really cool that we get to
59:53
talk about it. Hopefully somebody that's
59:54
listening goes oh cool, now I understand Temporal has that
1:00:00
feature so I can go ask my coding agent for that.
1:00:03
Yes, that's I think, I think it's great that you point that
1:00:05
out. Because not a lot of people are
1:00:08
writing code by hand these days. No, but no.
1:00:13
You, you still want these things to happen And so if you know
1:00:16
that they're there, yes, it's like it's latent and you can go
1:00:20
and you can probe the coding agent to say hey, yes, and use
1:00:24
the temporal streaming feature for.
1:00:26
This. Yes, absolutely.