Building durable Agents with Workflow DevKit & AI SDK - Peter Wielander, Vercel

Channel: aiDotEngineer

Published at: 2026-01-06

YouTube video id: kmV-qg4uoNI

Source: https://www.youtube.com/watch?v=kmV-qg4uoNI

Thank you all for coming. Hello. Hello.
>> Got you.
Uh, I don't know about you, but um, my
ride agents, I like focusing on the
capabilities and the features, and I
like not thinking about um, all of the
extra effort that goes into getting
something that works locally into
production. And something that's very
useful for that is uh, a workflow
pattern. And that's why we developed the
workflow def kit which is what we're
talking about today. Presumably if
you're here you've had similar issues.
Um and today uh we are going to um turn
a agent uh coding agent um into a
workflow supported coding agent
throughout this session. So
this slide. So we um have a open- source
example um ready to go. Uh this is on
the versel/examples
repository. Uh so you can clone that and
check out the VIP coding platform app
insight. Uh we're going to be using this
app um for today's demo.
Um and after we're done we get first
class observability built in and also
durability reliability. uh we get a lot
of extra features like resumability
um and
draft kit makes it very easy to add
human in loop workflows and similar uh
things.
So if you think about our uh general
agent loop um that we've all seen
before, we mostly have calls back and
forth from another LAM um to our to
calls and our backend uh code, right?
Which would include MCP servers, human
approval, any kind of async tasks.
And uh the usual way to go about this is
to uh wire up some cues um and a
database especially if you are doing
longunning agents right that might run
for hours um and you want to scale and
you're running on serverless for example
uh you want something some kind of
reliability layout in between which
usually is filled by cues um and then
you'll also need to add a lot of error
and retry code you'll need to store all
the messages that people are sending and
also between states and you probably
also need to add some kind of
observability layer in between. All of
those things we are going to do today uh
using only a single library which is the
workflow development kit. Um it's open
source um and it runs with any of your
TypeScript um front ends or backends and
can also run on any cloud. Uh we're
going to be deploying to Brazil today,
but this could just as easily run or any
of your cloud stacks um orbase or any of
your custom stacks.
Um all right, so who here has heard of
the workflow pattern or has used a
workflow library before? Show of hands.
All right, that's less than half. Um I'm
going to quickly explain what a workflow
pattern is um to uh make it clear what
we're doing and then in about 2 minutes
we're going to go into the code. So um a
workflow
pattern is essentially a sort of
orchestration layer um that separates
your code into steps that can run in
isolation and can be retrieded um and
have their uh data persisted and a
orchestration layer um that we call a
workflow within platforms have different
names for that. And in our case here, um
the the workflow parts would be whatever
the loop is that calls um the reason the
LM calls and then goes back to the tool
calls and then back to the LM calls. And
the steps would be our actual tool calls
and our LM calls. Um
right, so looking at the agenda for
today, um we're going to be jumping
jumping into the code. We're going to
add workflow development kit which is
going to be quite fast and then we have
a lot of time to talk about uh cool
additional features that it adds like
resumable streams out of the box um how
to suspend and resume at any point um
and how to add web hooks for human in
the loop uh processes. At the end
there's going to be ample time for Q&A
but there is a reason that you're here
in the workshop and not looking at this
online which is that you can ask
questions. Please do so at any point. Uh
feel free to raise your hand or just
shout out the question. Um and we'll get
rid of
all right so as I said uh we're working
off the baselample repository and we're
going to be working off of the conface
branch. Uh why this branch? I stripped a
bunch of the access code on the example
to make sure that we can focus on the
most important parts. And every
checkpoint from this workshop will have
its own branch. So uh if you're not
coding along directly, you can also
check out the steps step by step and
then check the diffs and see what
changed between.
All right. So
um I have already run uh npm dev locally
on this uh um platform just to show you
what it looks like. I'm going to run a
simple query. Um so this is a uh coding
agent, right? It's like a code editor
but without the code editing and it can
take a prompt, generate some files and
it'll eventually show you a iframe with
the finished app that is deployed. Um,
so it's it's mostly UI with a few simple
tool calls um that we'll look at in a
second. And the file system and output
uh runs over the cell sandbox, but you
could just as easily run this locally.
Uh, looking at the code, I'm going to go
and check out our actual branch.
Looking at the code, uh, we have one
endpoint that accepts our chat messages,
right? Then it does some some regular
sort of model ID checking with us to see
whether the model is supported. And in
the end it's going to simply create an
agent. Oh yes.
>> What was that branch one more time?
>> The branch was
conf.
Yeah. And you can see we'll we'll move
on to these com/2- etc. Uh just look for
the numbers and you'll find all the
checkpoints.
Um yes. So our main endpoint just
accepts some messages and calls the AI
SDK agent which is essentially the same
thing as a stream text call. Um we'll
pass some tools and internally it'll
just loop for stream text to call stream
text call. uh and then it'll uh stream
the all of the chunks generated back to
the client in a format that is easy for
the client to understand. This is all
sort of AISDK regular code um that you
could replace with a different library
if you want. Um that is mostly there to
support the UI. Um but again all of the
actual agent stuff is very simple and
happens here. So
uh oh let's also take a look at the
tools that we have. Uh we have four
tools uh create sandbox get sandbox URL.
These are very simple. They just wrap uh
bell sandbox.create and get URL and
similar with run command essentially
reps uh sandbox.r run command and
generate files um will generate uh a
file from a simple prompt. And we're
going to take a look at one of these
root calls as an example. Uh we have a
we have a prompt that looks somewhat
like, you know, a markdown file. Sort of
what to do, what not to do. Um and
my hotkeys are not working. And
back to the tool call. We also have an
input schema that's a Z schema um for
what BI is supposed to pass. This is all
very standard. and then an execute run
which wraps sandbox one command with
some error handling.
So that's essentially our entire agent
code setup and then in the front end we
just call use chat from AI SDK to
consume the stream and display uh things
in the UI. So uh let's get started
adding workflow to this. Um any
questions before I get started?
Cool. All right. Uh, so step one is
we're going to run npm install for
workflow and add workflow
which will give us the latest version.
Uh, workflow is the main library and add
workflow are some helpers for uh uh some
some rappers for
that work well with the workflow
development kit.
So now that we have this installed, uh
we are running a Nex.js app here. So
we're going to uh extend the compiler to
uh compiler workflow code by doing use
workflow or with workflow. Um which we
can import from
workflow next
and that'll set up next.js. Yes.
>> Verifying question. You are in the
example applied coding directory.
>> Yes.
>> So adding this will let the compiler
know to also compile our web um
separately which we'll get into more in
a second. And then for convenience, we
can also add a TypeScript plugin to our
TS config um same package and that'll
give us some better autocomp completion
for our workflow code.
And so we talked about uh a workflow
being
um having an orchestration layer and
having a number of steps. Uh what we're
going to do first is we're going to
write the orchestration layer. Um, in
our case, that is essentially just the
agent, right? Does the loop that calls
steps um back and forth. We're going to
add a new file. Uh, you can call it
whatever you want. And we're going to
take our
agent call and move it over there. And
I'm going to call this our uh code
workflow,
which is going to be all of our workflow
code.
And then I'm going to go and auto
complete a bunch of imports.
Thank you, AI. So we're just passing
most of the uh arguments that we would
otherwise get from here over there. And
this completes the refactor. Essentially
having done nothing but pull out some of
the workflow code into our file. So this
is where it gets interesting. Um, now
that this is a code, this is a separate
function, we can use the use workflow
directive
which will mark this for our compiler as
a workflow function.
So what this does is under the hood,
yes. Oh, sorry.
uh under the hood it um compiles all of
the code related to the function into a
separate bundle and it ensures that
there is no imports to anything that
would have side effects because the
workflow orchestration layer needs to be
deterministic. So it can be rerun um in
a in a uh deterministic fashion and
there's no worries about state uh
pollution.
So now that we have this um we would
need to now mark our LLM calls as steps
and because the calls are happening
inside the agent um this is a little bit
harder to do here and so we uh ended up
writing a
durable agent class which is essentially
the same thing as agent with a use step
marker in the actual LM calls that it
does under the hood.
So, now that we have this set up, we're
going to
await the actual streaming and let's see
if there's anything
we need to do.
Um, checking for errors. Oh, yes, we
need a stream to write to. So,
previously we could just write to the
stream that the API handler gave us. Uh,
now we're going to have to create a new
stream to write to. Um, we export a get
writable function from workflow which is
which gets a stream implicitly
associated with the workflow to write
to. And we're going to get get into that
a little bit more in a second. But for
now, we'll just pass that to our agent.
And we're going to see if this is right
type.
Um, presumably
not.
Um and then finally
back in our actual workflow
we need to call our workflow in a way
that the uh framework understands which
for us is a call to start
with the arguments being passed
separately which is essentially telling
it to start a new workflow
on this on this function and start can
be imported from workflow/ API Okay,
so now we essentially have uh the
workflow fully hooked up and a lot of
this was just pulling out some of the
codes and adding a directive.
Yeah.
Um
has volunteered to help anyone who's
like following along and has some
debugging questions. Um just reach out.
>> I'm on the team as well. So let me know
if you guys are following one.
>> I'll be around to help.
>> And finally,
this start call returns a run instance
um that has the stream that just um end
up writing to that we can return to the
UI. So this completes our workflow um
definition. And now uh we also said that
we would need to mark things as steps.
The durable agent class already marked
the LLM calls as steps. But our tools
right now are not marked as steps.
Thankfully, this is very easy. Uh in the
execute function for each of these
tools, you can just write use step and
that will let the compiler know that
this is a separate chunk to uh of code
to uh execute in a separate instance.
Right? If this is deployed to
production, this would run in a separate
serless instance and the inputs and
outputs would be cached if it already
ran and it would be retrieded if it
failed. So I'm going to go and
go through the other tool calls and also
add use step to these. Thankfully we
only have four of them.
And that should complete our
transformation.
So now we can go and run the mpm dev.
See if this works as expected.
We're going to reload our page.
And it seems like nothing changed. Let
us actually run a query.
And we can see that it's still streaming
as expected. So uh for us developing
locally right all we had to do is pull
out a function um and then add some
directives. But now if I deploy this um
to any adapter again was or an AWS
adapter or maybe you have your own um
this will run uh in isolation with
durability and all of those good things.
And something that's really nice for
local development also is that if I go
and
if I go and I'm going to go into the
same folder here and I'm going to run
npx workflow web which is this cli call
to start a local web UI to inspect our
runs. Um and you can see that our run is
currently still running. Um and every
step everything that is marked as a step
will have a uh span here and you can
inspect the inputs the outputs and any
associated event. And we can see that
our workflow just completed I think and
yeah this gets built in. Yes.
>> And just for clarification every time
you're prompting your vibe coder that is
is one instance of the workflow that
runs to completion. So then so each one
is Yeah. It's
>> exactly Yeah. And you could model this
uh in any way you want. Um you can also
model your entire like an entire user uh
sort of uh session as one workflow and
uh have the workflow sort of do a loop
wait for the next query um and then
again you know we can run code for weeks
if we need to essentially um
and I'm going to go into uh some tools
for that in a second.
So now that we have this uh set up uh
you can see that um on the right side we
do not get any sort of helpful uh
feedback. But um if I visit this link
and see that our app
has likely been created correctly
um or or it failed because of some
errors
and
either way we're not getting any output
on the right side. So uh the reason this
is happening is that we are streaming um
the agent output to the client but our
tools aren't actually doing any stream
calls right now. So what we could do is
similarly in our tool calls uh we could
get the writable
um which would which will get the same
writable instance as any other uh as the
workflow itself. Um there is an infinite
amount of streams you can you can create
and consume in a workflow. Um and you
can also like you can tag them with a
certain name and then fetch them from
there. Um but this will get the default
instance.
And once we have a writable we can
actually connect to the writable
by getting the writer. And now we can
write any kind of information um to the
to the iPhone to be consumed. I think we
want something like data create sandbox
I think is what I hooked up in the UI
and then
we'll call ID
we want the sandbox ID do it here. So
this is me just writing a data packet
that our UI knows how to consume. So now
that I did this and I if I reload the
app and start this again, we'll see that
at least the sandbox create call
presumably gets filled in correctly at
the start.
>> Yeah,
>> you said that there are stream that you
can create and
what do you mean by that?
>> Right. Yes. So um a stream
the workflow sort of the adapter they
use for workflows in local development
right this would just just be a file in
production this might be a reddus
instance
>> um supports the workflow calling it to
create a new stream for example in
reddus right and then passing that
stream back and so anytime you call get
writable it'll create a stream for
example again in radius with the ID of
that workflow and it'll pass that So any
step can attach to that and any client
can attach to that
>> and in local uh host this would be
written to a file and read from a file.
>> Sorry you're setting up right now.
>> Right. So pre previously we had a a API
handler that took some messages called
the agent and then streamed back
messages from that API handler. Now we
have an API handler that calls it starts
a workflow and it'll pass back the
stream that this workflow creates. Um,
what this allows us to do also I think
that was not working correctly. I'm
going to restart the server just to see
if that's the case. Um,
>> anything else so far getting this set up
to where where needs any help with
getting set up?
>> Seems good. Um good point you made uh
something this allows us to do is that
the stream is not bound to the API
handler. This means that at any point we
can resume this stream. If you lose
connection to your API handler and then
the user reconnects this stream still
exists and we could reconnect to the
stream to resume the session. This is
also part of the durability aspect where
everything you do in a workflow you can
resume at any point.
I'm going to restart this query and hope
that it works this time. Yeah. So, now
that I hooked up this data packet, you
can see this special UI handling for
creating a sandbox uh works. But even
after it's done, it's not showing up
that it's done. This is because we're
only writing the initial loading state
packet. So, I could go through all of
our tools and I could add more packets
and just, you know, make the UI richer.
Um, but I'm going to go and check out a
different branch which is the uh conf-
sleep branch. Uh, just the next step uh,
which already has these
actually I'll go for the workflow one.
Sorry, conf /2-workflow
which already has all of these writer.
Calls populated. There's no difference
otherwise. Um, so now that all of our
tools have these right calls, the stream
would again presumably look the same as
it did when we started out in this app.
Um, all right. So, now that we have
streams working again, everything is
working as expected and we have more
observability and we can deploy this
with durability. Um, I talked about
resumable streams before. We're going to
see if we can get this stream to resume
so we have durable sessions.
So, the only thing we need to do to uh
make that work is to go to our API
endpoint.
Um, and what where we get the run
instance, we're also going to return
the workflow ID
as a as additional additional
information. So I can I can return run.r
run ID for example. This is just again
any way you do this is fine. Um, I'm
adding it as a header here because we're
already returning a stream. But anyway
you pass the ID to the UI um is
something that the UI can then use to
resume the stream from.
So what we do from here is uh the UI
should be able to decide whether to
whether it has a run ID and whether it
should resume a stream. So we're going
to go and create a new endpoint. Um
let's call it
ID for type slashexisting ID. Then we're
going to make a folder stream and we're
going to add a route handler. So this is
just next.js uh configuration for adding
an API route at slash chat/ ID/ stream
and we're going to
auto complete with AI.
Um what we're essentially doing is uh we
get the ID from the params and then all
we're going to do is call get run in the
workflow API which gets a uh the run
instance and then we can
return the same stream
that we return in the other endpoint
just without calling the actual agent um
only only doing the stream and
>> this whole project
>> I think that should be good. Um, we're
also taking our start index which is
very helpful from the AI. We can get a
readable stream um, from a certain start
point. I think this is why it's auto
computed. Um, so if you're trying to
resume a stream like midway, you can
pass a, you know, which chunk you were
on when you initially left off. So now
that this is done, I'm going to comment
out these things we don't currently
need.
um we need the UI to support
this uh conditional of whether to resume
or whether to start a new chat. So I'm
going to go to our chat front end and
I'm going to go pull in some code from a
different branch um for simplicity which
is the it's on the four-streams branch
which I'm going to
just show for
completion. um we do a use chat call
already in the UI to consume the stream
and we all we added now is a transport
layer which is this big block here that
has some middleware
for the stream that says that if I'm
trying to start this call uh I'm going
to check first whether we have an
existing run ID and if so I'm instead
going to do a reconnect by calling this
different API endpoint instead
I'm sort of handwaving over this a
little bit because it's client side
handling for for traditionals. Um, if
there's more questions about this,
please feel free.
All right. So, that gives us resumable
streams. Um, and I'm also going to demo
uh what if we wanted to deploy this and
see it in production.
Uh, so I'm going to call this and then
we can check out a production preview
example.
In the meantime, uh the next we're going
to do is we talk about
events and resumability.
The workflows because they run the way
it runs is that every step runs on its
own serless instance in production. The
actual work workflow orchestration layer
is only called very briefly to
facilitate a step runs. What this allows
us to do is to have a workflow to spend
for any amount of time. a workflow could
wait for a week and not consume any
resources. Uh this is built into the
workflow development kit um
in a way where we can in inside a
workflow anything tag with use workflow
we can simply call sleep
three days for example
um and that would also wake us uh that
will pause the workflow for three days
and then resume where we left off. If
someone was trying to reconnect to a
stream for example, right? This was
sleep an hour, the stream would just
reconnect again to the same endpoint and
things would resume from there. So we
don't lose anything by uh losing the
instance that runs the code because we
can always restart it, resume from where
we left off.
Um and this is useful for AI agents
because we can to a tool call. uh we can
have the UI as the AI agent have a call
that says sleep any amount of time and
then use it to make an agent that that
essentially uses a crown job where it
says every day read my emails and do
this thing right so that would be sleep
one day yes
>> when the when the kind of agent goes
down that means all the state goes with
it down
>> yes so when it when it sleeps no when it
sleeps for three days
>> no then it kind of paused but when that
would be killed output is for some
reason where does the state go of that?
>> So the the way it works is that any step
call um is cached. So when you when an
input goes to a step call, we register
that as an event and we run the step and
if the step completes, we cach the
output and say this step has been run um
to completion. Right? So if it was if it
was something like this where we run the
agent first, right? Let's say we run the
agent and we run a bunch of steps. um
the state of the workflow function at
this point in time would be saved and
all of the outputs from all of the stat
calls would be saved and at the time
where we restart the workflow from this
specific line of code it'll rehydrate
the entire state and it'll just go from
here.
Um and this happens so that again we
don't have to replay any of the code of
it uh in a way that that does any actual
resource consumption.
Um
yeah, so
we can use this to make an agent that
has it's essentially a crown job again.
Um and we can use it to make agents that
run for weeks or interact with any of
your um sort of like information over
over a very long time horizon.
And
while I've been talking, we have
deployed uh our current app to the cell.
So I can check out this preview branch
for example and you can see the app is
now live online um and working just as
it usually does. And
yes it works perfectly. And if I then
again I can do
uh I can use the UI to inspect this at
any point. If I call
workflow inspect web or just workflow
web with the dash backend for cell and
dash and preview parameters for example
that'll just let us let it know where
our deployment is to be found and then
that'll spawn up the same UI and now we
can check on this run run run that's
running in production and you can see
we're getting the same kind of
information here. Um,
yeah. So, this is sort of Oh, I'm not
going to cancel the run. I could cancel
the run. Let's cancel it. Um,
this is to show that the way it works in
local locally is the exact same way that
it works in production from a conceptual
standpoint. Um, which is the UX we are
aiming for.
All right. Um, I talked a little bit
about sleep and suspend. Let us go and
write this
sleep tool call. It's going to be very
simple. Uh I'm going to go and copy the
I mean I already here but I'm going to
copy this and write it from scratch.
We're going to write a sleep
uh pool call.
I'm just going to call it sleep.ts.
And uh we're going to turn down the
input schema to be something like time
out milliseconds
and the actual run command to be
none of this and instead just call
sleep.
Um because sleep is already a step um
that we export from workflow in workflow
library. We don't need to call uh we
don't need to mark this function as use
step
but this will now uh let's see if this
is oh this should be a number. There you
go.
>> Can you see that again? Why don't you
need the use step?
>> Oh uh so this is already a step um that
we export from workflow. It's going to
be the observability will also show it
as a step which we'll see in a second.
And
um this should just work assuming the
prompt is good which we're going to
modify to be say something like
see
of this.
Um
yeah, do this. Um only use this tool if
the user directs you to do so.
All right. And get a double quote here.
There we go. And so now that this sleep
call is set up, um that should be all
that we need to do.
We'll call it run sleep command and
sleep tool. And we're going to add this
to our tools list.
And
I think I confused our compiler a little
bit or at least TypeScript.
This seems to work great. Okay, now we
have the tool. Um, and we also want the
UI to sort of display when it's
sleeping. Um, so I'm going to add I'm
going to add a another not a function to
log sleep. Uh,
this is the reason we're doing this is
we cannot write to a stream directly
from a workflow because then it wouldn't
be uh deterministic anymore because
every run of the workflow would write to
the stream again. Yeah. So I'm trying to
run the project. Um I had to create a
versel API key for the AI gateway. Did
that did that getting error that says
header is missing from the request. Do
you have the YC option enabled in the
project settings?
>> You skipped this in the beginning but
>> oh yes.
>> Yes. Our uh because this code uses uh
sandbox uh you would need to log into
this. Um my mistake uh this should be
running locally. Um if you don't use
this sandbox which uh I will uh we'll
have a branch that doesn't use this
sandbox um for after the talk.
>> For now you might
>> um at this point I'll just do it
afterwards. It's fine. So here I'm just
going to add another call to writable
and we're going to call uh we're gonna
let's see we're going to need
local ID and so now this is just going
to writes to the stream and that should
allow us to
show it in the UI correctly. Um, let me
see if I figured
the UI to correctly interpret this
packet.
Um,
there is no data sleep type which I
think might wait. Yes.
All right. So, now that I have this, um,
I can go start our app again
and
And so it loads. We can try out the
second prompt here which is sleep for 30
seconds and then return a
uh just to show that it's going to
correctly interpret the sleep call and
then
sleep. Um, it's not showing the data
packet here sadly, but we can go to the
web UI
and we can show it
has been it's engaging in the sleep call
and this is going to return after 30
seconds.
All right, so that's sleep and there's
one final thing um one final feature
that I want to show you u which is web
hooks and the ability to resume from web
hooks easily. uh implementing web host
is usually quite difficult or a headache
and in our case uh I'm going to check
out the conf /5-hooks branch and show
you that we can in the same fashion as
we do sleep we can add a new tool that
I'll just I'll just show you where the
actual tool call is um just a a log call
and then we create a web hook which is a
function we export from the workflow Uh
and we can then log the web hook URL
to the client or anywhere else and await
web hook and this will suspend for as
long as necessary to uh someone to click
on this URL and then
let's see if we can the server is
running and I can show you this uh
running hopefully
reload this and Um,
wait for wait for human approval
before starting
and call
Pokemon index.
Let's see if it happen this correctly.
Been changing branches, so I might need
to restart my server.
Um, and the way this works under the
hood is that again we'd be creating a a
URL and we're going to sleep the um the
workflow until a call comes into that
endpoint. And this comes with I'm going
to run this query. This comes with a lot
of extra features like I could also do
respond with if I wanted to. Uh this is
a full API API request handlaw. I could
respond with a request object. Uh I can
treat this as a uh again API endpoint. I
could also check the body against the
result schema for example and then only
uh resume once that matches.
So this gives you full control. Um, but
the nice thing is it does hook up the
URL internally and you can see that it's
paused waiting for a human to click on
this link and if you're running in local
host it's a local host link running in
production it will be whatever your
deployment uh URL is. Um yes about both
sleep and human approval those are like
a workflow is is purely steps and steps
always run to completion right so so
sleep is a step it's not like the
suspension of you know like some sort of
like it's not a suspension of the the
execution it's like it's it's a step
>> no it is so we model is the step in
terms for the observability and for the
for how you call it but it is an
internal feature that completely
suspends the workflow and all steps
nothing is running while to sleep. Um
you can also do sleep and another step
and you can promise them if you want. Um
it works as a step call in that sense
that it's a execution that takes a
certain amount of time. Um and you can
use promise await syntax uh to model
that but again it completely suspends
unless there is anything else running at
a time and the same for the web hook.
it's modeled as a step um for the
observability
um but it completely suspends unless you
have auto code running at the time.
>> So just from my understanding if you
have an agent running uh with a workflow
it keeps running.
>> Yeah.
>> You connect to it again let's say
through another session and you would
call sleep in this session does that
like the previous one just like whatever
it was doing just goes down. So if you
have two sessions
um so let's say we we have a coding
session right and it already built an
app and then it's sleeping for a week
right um and then we reconnect to the
stream is that the
>> no the thing is uh let's say I kick off
a work uh workflow and it's calculating
like the numbers of pi just keeps on
right but I connect to the same sandbox
and then I call sleep will it stop
calculating pi
>> um so the way you would do this in a
workflow is again let's let's see how we
would code this
>> you have a sandbox there sleep in the
sandbox
>> well you can connect to this sandbox you
connect again to the sandbox and some
thread call sleep does the whole sandbox
go
>> so the the sandbox is uh it's basel
sandbox which is a sort of just imagine
it as an EC2 instance um so this is just
a a helper for us to spin up an instance
to run this coding agent like run the
code in order to store the files
Um if you met this differently you
wouldn't have to use sandbox um and the
sleep call doesn't happen as a as a bash
call for example then two different
>> right
>> like an orchestration thing and then
when you're actually in this box you you
call sleep in a sandbox you're
>> okay so there are two different
>> right so so there is sleep that you
could call from a terminal um in the
sandbox as a as a as a terminal command
or there sleep from the workflow which
suspends the workflow
Uh yeah so we have we have these
features for for web hooks right and we
can see that after I clicked on the URL
it resumed and then coded me a Pokédex
um that is all of the features we're
going to in the session and I think we
have ample time for Q&A about 20 minutes
at least
please go for
>> how would I spin up claude code session
with this
>> a cloud co session
remotely or are you
>> no kind of run and kick it off as an
agent doing certain stuff um is that
possible and then kind of orchestrate
that as agents
>> that is possible so cloud code uh is um
if you're talking about the app like a
tonal app right cloud code then that
doesn't use a lot of the workflow
features internally um so it's hard to
isolate that or know where the oxidation
There is you could write your own
version of uh cloud code or take the
plot code source code and add workflow
and step um for the calls and that would
then run as as a workflow in the cloud.
There's no way to say like okay I have
my steps you know spin up claw work uh
kind of code type this command and wait
for anything that would be a versel
workflow but how would I actually boot
drop it like code it
>> is one command told right so you know
what you're asking
>> if you so if you're calling cloud code
uh in a um so made as a confusion of
like where this is running right for a
coding agent here if the coding agent
runs make the right for like creating
creating a folder that make the command
runs in a step but it runs against a
like in a sandbox there sandbox being a
VM and so this VM state is not managed
by the workflow itself um so if you call
cloud code on the VM that's essentially
treated like an SSH session but if you
run any any agents or steps within the
workflow right those steps are going to
be resumable um and observable through
the workflow pattern
Um, another question, how do I control
um what my agent has access to from
going out to the internet doing stuff?
>> This would be uh whatever you're
whatever you're already doing for the
agent, right? If you if you in the end
you're going you're going going to be
doing tool calls and stream calls to the
LM provider, right?
um that is that is in your code
presumably already and whatever you're
already using to control permissions
there like your tool calls for example
right if your tool call uh allows you to
delete a resource in S3 for example then
you as
call uh can write whatever code you want
uh in the usual way that
>> it's my job to implement it but it's not
that it has some wrappers by the end
Yeah, all in the sandboxes.
>> Workflows is a general orchestration
layer for durable execution um and
doesn't necessarily provide a sandbox
for running code or um like running
third party code or running agent code
or making files. Uh that's something
that the sandbox is good for because
every sandbox instantiation is a new VM
um that only lasts for as long as your
session lasts.
>> Yes.
>> Yeah. So uh if I'm running workflows uh
and I'm like creating a lot of agent uh
workflows through my brother uh how does
that do does that get queued up on your
system? How does that get run? Is there
rate domain or currency and controls
that we can uh use?
>> Yes. So this is this is uh this goes
into sort of uh some of the patterns
that all of this is going to be
supported um and for the most part is
supported right now which is that if
you're deploying for example to go right
and as usual if you do nextjs every
deploy is a separate uh like live URL
right that if you call it spawns up a
serverless instance and so your
workflows are bound to the deployment.
So if you have something that something
very nice that you get here is if you an
agent and it runs for a week but you
deploy five times in during this week
those new deploys are going to be
isolated from the original workflow and
the original workflow is going to run to
completion and then any new workflow
will run on the new deployments and
we'll also allow upgrading between
those. So if you have a a workflow that
runs for a year, right? Because it's
like every month give me a summary of so
and so, right? But you have new code and
you want the workflow to uh you know
take its current state and use the new
code for the workflow. Um there's going
to be an upgrade button in the UI that
checks for compatibility between the old
workflow and the new workflow by
checking all of the step signatures and
all of the existing events and then you
can upgrade the workflow. Um or you can
currently already cancel and rerun with
the with the new workflow.
>> Um is there a timeout for those workflow
steps?
>> Oh
>> yes. So uh if you're doing serless right
and whatever platform you're on whether
it be like lambda or something else or
or uh your serless functions are going
to have timeouts. The nice thing is that
every step runs in its own serless
function. So the timeouts only apply to
the stats. So if one of individual step
you have runs the risk of running more
than five minutes maybe 15 minutes
depending on platform um then you can
split into two steps um or if it's if it
runs the timeout right it'll fail it'll
retry maybe the will be faster um and
you'll see in the UI that oh this step
is being retrieded after 15 minutes a
bunch of times right presumably because
it's failing and then you can go and uh
split it into two steps upgrade the
workflow and it'll just continue from
And uh yeah the other point was uh
around queuing workflows like I trigger
the agent a bunch of times.
>> Yeah.
>> Does it get cued? Like how does that
process?
>> Right. You can model this in in
different ways. Uh right now again we're
doing this from like a API route where
every call to this API route will create
a new workflow. Um that is mostly again
the only the only the only interactable
output you have is a stream in this
case. Um so it'll do things it'll write
to the stream. Nobody looks at the
stream. We don't know the work before is
running. Uh you can kick off 10 of
these, right? Um and they're going to be
running in the background. Um there is
essentially no limit to how many you can
create because they all run in serless
functions. So you can scale for as much
compute as there is in your provider. um
which is a lot of cute and um you can
also list active runs right there's an
API here for doing C interfacing with
your runs look at all of the runs that
are running look at which version
they're on uh what step they're on um
cancel them I hope that answers your
question oh concurrency yes um you can
also so right now it's infinite
concurrency but uh very soon we'll add
per step or per workflow concurrency
where you can say This workflow is only
supposed to run at most 10 times at the
same time and any extra Q addition gets
like any extra start gets cued so that
it will wait for those 10 to uh reduce
and then slide in. You can also use that
to have a free tier for example on your
product where there's 10 instances
running for your free tier at any one
point and some people that come in later
will wait for the queue but your pro
tier has infinite concurrency.
>> Yeah.
>> Can I roll back steps in a way that
let's say I have 10 steps but in step
seven I think like okay let's go back to
step three. Would that be possible to
like reset the state of the workflow or
>> you can technically do this do this? We
current we don't currently support it
but it would be very easy to implement
because uh you have every step again the
inputs and outputs are cached and we can
enter the workflow at any point and sort
of play from there. So we'd need to
expose this in the in the UI to as a
function to resume from step so and so.
But yes, that would be possible. more
more likely what you want to do because
you control the workflow.
So you wanted to log there and use this
JavaScript
and might have to
step into state or do something just
keep growing.
Maybe my second question. So if you go
through the steps you said, okay, you're
passing out input and outputs kind of
across and that's kind of what get
cached. Is there like a way to attach
metadata or does it always have to be in
kind of the input outputs of the
function?
>> You can also attach metadata. uh we'll
have a tagging API soon where you can
add arbitary tags to the workflow at any
point in the workflow run and you can
use those tags also to maybe decide
whether to early or dd duplicate your
runs. Um yeah.
>> Yes.
>> About the deployment are we tied to
versel or is it possible to like
>> as I mentioned before uh so there
there's two aspects to this. There's the
the front end side of the framework uh
the docs are on use workflow.dev. Uh you
can see for the front end sides um which
is also sort of the the uh API layer it
might work with. Uh we currently support
all of these platforms.
um and more coming soon. And then
there's separately the deployment target
right next.js JS you can deploy to
anything right now right this would work
with anything you can deploy XJS2 for
example or any of these other frameworks
um and we have implementations first
party implementation for a Postgres
example that uses Postgres as the
dability layer um and as we'll be
building this out and community comes in
we'll have support for essentially any
back end um because underneath the
TypeScript framework connects to any
storage or Q layer so anything that
provides a storage a database uh or AQ
can be used the back end for for this
>> related question for the observability
we also like providers to data dog stuff
>> yeah so uh we we have a uh multiple
things we have an an API that you can
use to to uh access data directly um and
we also have open source UI components
that you can use to display it and then
you can export this to data Um if you
want. Yeah.
>> You talked about screen a little bit and
talked about how it essentially like
job. Uh do is there more scheduling and
chron controls within workflow? So uh
because it's just typescript uh if
you're in a workflow um you can do
something like let's say we call sleep
for example right this this would just
be resume in a sorry resume in one day
but what you can also do is uh this is
just a promise or you can treat it as a
promise so you can do
while true sleep one day and then uh you
know do your code and it'll run once a
If you wanted to run once a day at 2
a.m. um you could you could say you know
how much time
to you know 1:00 a.m. tomorrow. Thank
you AI. And then you know done. Um and
you could also
wake up every hour do some checks
whether you actually want to run the
rest of the code. If not go back to
sleep. Um anything you can do with con
to do here. And if you want again
concurrency controls something um or any
kind of other deterministic controls you
have control flow in Typescript here.
You can check check external um APIs.
for example, um which you have to wrap
in a step, but you can make fetch calls
if you want to actually check data and
then determine from there.
>> So if you if you wanted to do a uh agent
that runs every once in a while every
day, you could have a scheduling wrapper
scheduling workflow that launches
another agent workflow
>> also. Yeah, you can you can you can
start workflows from workflows or you
could do this right where you uh sleep a
day and then call your agent and then
depending on the the on the stream you
want to right this is all right in the
same stream presumably you don't want
that presum maybe you can also uh
thatable
allows you to do namespace right uh one
um and you can get a new writable here
and then every time it runs you can have
a new stream that has a deterministic uh
name and you can choose which stream to
connect to.
>> Yeah.
>> Is there cancellation logic? Like say I
have something waiting for a long time
and then I decide to not have that be a
thing. How can I just like stop an
existing sleep from waking,
>> right? So you can cancel your workflows
from the observability UI or from the
from the API or the CLI. um all of those
avenues uh have you can call cancel or
you can also say well I don't even know
if I want to sleep on the end of the
zoom what you can do is do a uh let me
remove this part here you can do
something like
you know await promise grace and you can
do the sleep one day and you can do some
other actually human approval maybe wake
up earlier if a human clicks a button
than the one Okay. Um, there you go.
>> Yes.
>> Um, if you have multiple agents running,
uh, what would be your advised way of
having them communicate with each other?
>> Um,
if if you're
sort of depends on what kind of
communication you're looking for.
>> Firing things off and they're working,
but I wouldn't sure there was. So in
steps um you have access to
all code APIs or
NodeJS API fetch etc. You can have a
database, right? If you want to automate
over your own data source, you can have
a database. Um, if you want to have
multiple agents, um, you can, uh, use
one, you can use some of the same
streams to write to and share a stream.
Um
yeah,
I guess it's up to us ultimately with
our steps that they're like I demp it in
and if they have side effects when they
fail halfway that it's well behaved like
that's that's not at your orchestration
layer like that's up to us,
>> right? for the workflow layer, we
guarantee that there's no side effects
because if you try to import some code
that does side effect, I think it'll
just it'll just say like can't compile,
doesn't you know, don't do it. Um,
>> that was true for workflows, but for
steps
>> for steps, it can have side effects.
That's sort of the point.
>> So, it's up to us like if it fails, we
need to make sure that transactional and
it's rerunnable and
>> identity. There's some there's some uh
there's some error controls you can add
here where if a step fails, it'll
usually fail uh with a an error that
tells the workflow station layout that
you can retry it. You can also catch
this error and say, well, if it's a you
know this kind of error, don't retry it.
Instead, signal to the human to do
something or try this other avenue.
Yeah.
See there's something else.
>> Do you have one of the branches that has
like the complete code for what you just
did?
>> Yes. So, uh they all built on top of
each other. So, the conflooks
branch has the human approval tool
called the sleep tool call. resumable
streams um and using web flow.
>> Uh I will
see how I can post one general access
>> just tweet it out.
>> Yes, we'll do that.
>> Uh the workflows are in beta and so
>> Yes. Yeah. Um
>> okay. Yeah. Uh yes, I forgot to mention
this important uh workflow devel
I believe and we have a a GitHub
using production especially durable
agent stuff
>> internally we have I think more than 1
million workflows have been run on on
>> a day. Yeah,
>> it's mostly just like getting
the API to be stable and a bunch of
issues. But one of the things I love is
that we actually have more than issues.
But uh
>> yeah,
>> if there's any feature that you that you
need or that you really want to see, uh
we have an RFC section on GitHub uh
discussions for upcoming features,
things that we'll ship by GA or shortly
afterwards. And then open issues, right?
Um where you can add any issue and
presumably we'll be able to it soon or
someone from the community. Again, this
is uh all of the adapters that help
workflow develop run on any kind of
cloud back end or your homebrew back
end. All of those adapters are also open
source. So, you can see exactly what's
happening and you can connect it to your
own back end and only the source um just
looking at that code and we'll be happy
to help you.
Can you talk about uh
>> uh yeah um what would you like to know
>> the road map for like
>> right so for versioning um I talked a
little bit about about uh the ability to
upgrade runs across versions right uh
versioning is going to be very simple
where we have a crowd interface for all
of the versions that you have created
which for most people will be a
deployment right if you deploy your
um you know CI deploys your code to a
preview environment or production uh
every deployment will be one version um
and you can list those versions at any
point uh using the the workflow API and
the run will know which version it's
running on and you can call run.upgrade
upgrade to see if it's compatible with a
new version to upgrade it to that
version and I know any any more things
>> version
>> no yeah so so every every deployment uh
gets its own URL and not just in basel
but presumably in your if you go to AWS
lender for example right uh every
deployment has its own URLs so the web
hooks would apply to its own URLs um
which means that you don't need worry
about versioning except for tagging a
version when you first create the
deploy. Um and then whatever you think
is you want to be your main version is
the one you route to via your public
API.
>> Yeah, I think um sorry
obviously I used to work at my
experience in this stuff. I think a lot
of people unfortunately it's like
isolation of but sometimes you want to
sort of fix in place things that have
been a while.
>> Yeah. Migrations almost like agent
migrations to new version.
>> Yeah. So this is the same as as
upgrading in that sense, right? But if
you have a bunch of runs that are all on
a certain version and you have ship new
code and you want all those runs to be
upgraded to the new version or migrated,
right? Um, in the UI you'll be able to
select however many runs you want or for
the CLI you want to be able to get a
list and then say for these 20 IDs I
want to upgrade the run to this version.
Uh, will it'll do an internal check of
of can I resume these uh workflows from
a certain point? um like can I migrate
them in place sort of because the step
signatures overlap or if not it'll offer
you the option to cancel all of the
existing runs and rerun them on a new
version of the same input. Um if you
write your code in a way that's
compatible again um there's there's
going to be different options for for in
place migrations.
>> How would it detect that just by code
parts not being changed? So because we
have because we're essentially a
compiler plugin uh we can get full a uh
compatibility and and we are saving this
a uh
the inputs and outputs signatures um to
a manifest that we're uploading for the
versions and so for every version we can
tell what are the signatures for every
uh step and for the workflow itself and
all the other things that are happening
in between.
>> Another thing here is the workflow
function itself.
So yes, we played a whole bunch of times
during execution do anyway.
>> So when you want to upgrade
your event,
>> it's kind
of the code that you've got on the event
against it.
>> Sure.
There's a lot of variations between kind
of I do a step all the previous steps
stayed the same or you know this one got
changed. So it's like you like if
everything's done automatically it feels
like okay I could go down immediately
with all my agents or up
>> there's two ways you could there's two
ways you could be versioning
and I think the thing with
is you build for a platform where you
assume that the code your code is always
going to evolve in the same place. So
what we've seen is you end up with as
you start your first version of your
workload that you ship but as you start
making updates to you starting new
version your code now has all the stuff
in there that has
you have no guarantees of what version
running on the actual code that you're
running. The default assumption is that
my code could be running an event log
anyway and you end up with starts great
and then you have to do model
>> but it was the same with like killing
and sustaining
already had
forever. there's a natural step to go
say cool we're just gonna assume that
you you push a new version of the
workflow you pin everything
and so you don't have to worry about
that mental model that
code but instead it's time to go up push
button
I can go in
or even choose like you know
theoretically choose exactly how much of
that button get
there's a lot of stuff that you can do
on top since you have But what's nice is
that's that's a hard US and you know for
us to build when done well
hopefully very
>> I don't know we're close to done
>> I think we're close to done
>> uh we'll be sticking around for more
questions so uh
>> I guess okay so let's say I'm a third
party like But I think the other part is
observability.
Um I don't I I like poked around in I
don't see like much of a dashboard. I
expect that obviously you're going to
build one, right? Uh and then I also
want to import it into my data dog. See
there not a data dog but hey what's this
supposed
>> uh open telemetry spans uh which we'll
you know be able to emit um we'll add
some context to the spans by default
presumably. Uh so if you if you just
pipe your spans through data dog it'll
already have a lot of information on the
steps and event log. Um and you can also
submit your own uh telemetry obviously.
>> So is that the plan or is it you have
the first party?
>> The plan is that we will we will first
party support adding some of the like
all of the sort of step and event log
related context. Um will uh presumably
export a helper to add some of these
information to the spans. Um and then
every all information you want to tag in
there is up to you.
>> Can I uh attach like secrets to workflow
in a way that when I need to update them
they kind like you know
>> Yeah. So uh for one like right now you
can you can inspect all of the input and
output data right and it's obviously uh
for you as a someone with access to the
API uh which someone consuming the
workflow or starting the workflow
through web API wouldn't usually have
>> no
steps in steps
>> yeah so the the workflows run in the
same deployment as as it would usually
do and has access to the process uh
environment right so you can inject
environment levels the way you would
usually do um and as as long as long as
you don't log them which again
presumably you wouldn't do any anyway um
it's the same way as an API endpoint and
then if you want your data to be secret
right um right right now we expose it in
observability um if you have access but
we also will allow in the future to do
end to end encryption for any data store
>> right then we'll uh close the session
but we'll be around a little bit more
for questions if you want to you know
look over
She lost
heat.