Community Session: Vercel Workflow

So, I want to stop here and kind of just jump into questions. I think there's a lot that we can go over. Um, I also want to point you to the workflow docs where there's a lot more on workflows and how each of these different bits work along with um the blog post that I'm happy to go over as u as it makes sense for questions. But yeah, think of this as the basic just getting started guide on the three basic primitives we think about with workflow which is you have steps, you have use workflow and steps that can suspend and resume. You have hooks that allow you to wait for any external arbitrary event and you have sleeps that allow you to wait for arbitrary amounts of time, anything from a couple of seconds to a couple of days or even a couple of months. Um, and with that you can kind of model a ton of background pipelines. agents being a natural extension of this as well. I haven't gone into this and I'll I'll just point you to this in the docs before we jump into questions, but um agents tend to be a very natural representation of basically just a long running task because you're looping making an L making an LM call and then running one or more tool calls maybe like writing to memory using a sandbox uh using a file system whatever and then just doing that over and over again on a loop. So you're streaming tokens, making a tool call, streaming tokens, making a making a tool call. And doing that with workflows is both extremely powerful and extremely tricky if you're trying to wire this all up yourself. So we have a class called durable agent that basically does a lot of this orchestration for you and just works natively inside workflows. Um I'll stop there for now, but excited to hear uh what questions we have. Hey, uh I just want to say we we started using workflows for some of the the tools that we use to manage community notifications because we have so many places where it's coming in. Um agents have made managing those notifications great and workflows has been great for handling some of those kinds of tasks as well. Um, so it's it's been really uh big shift forward uh in in the way that we build things. Um, but the first question that I have because I see so many skeptical people who ask every time we release some new open source thing. Um, you know, we've got workflow SDK which is open source and then we got Versell workflows. So how open is it really with the versel workflows? Does that mean workflow SDK is only going to work on Verscell or how easy is it to use other places? Yeah. Yeah, that's a that's a good question we get all the time on workflows and it's um essentially workflow SDK is the open-source framework and we and we name it as such uh too where we ship this thing called worlds from day one. It's basically analogous to adapters and Nex.js JS also launched adapters around the same time. But the idea is that workflows themselves with workflow SDK are just a way you represent longunning code, right? So you can write use workflow and steps and you can have sleeps and timers and weights and hooks and and whatever. And the best analogy I like to think of is something like Docker where this is a Docker file syntax for how you write um write a long running workflow. By default, we've been we've shipped and maintained three different worlds which is the local world. So when you run workflows locally, it stores everything in a file system that you can inspect. You get the same observability locally that just inspects the file system. You get uh the queue is in memory and so you have an entire from day one, we've always had an entire great local dev experience that pretty much mocks what we're doing on Verscell. We also ship the Verscell world of course. So when you deploy on Versell, there's a lot of stuff that you get out of the box. We encrypt everything end to end. Um we've done a lot of work on the compute layer to make this fast, keep networking private. Um and then we also ship this Postgress adapter from day one which means that you could already take workflows and we have customers that do this in production where they run their workflows the same code uh and they can easily migrate them from versell over to Postgress or or likewise. But essentially you can just run a Postgress backend yourself and then start workflow with an environment variable that points to the Postgress uh instance and uh the world adapter will will boot it up basically or sorry set it up with all the tables that we need and then use it as the persistence layer and use it reliably. We have more worlds coming as well. So we're working with the community and stuff like we have a Cloudflare world in the works. We have an AWS world in the works. um it's been built to be something that can be run anywhere. Um we've done a little bit of the work like I said with those three first party maintained ones and there's a lot more coming there both from our team and from the community right now. We've got some love again in the comments. Uh someone who says they are actually using Versell workflows right now. Um another who thinks workflows is a great addition to Verscell. Um, another question that I see come up uh with this kind of thing is there's code snippets in the docs. Um, but are there any like full apps or other more complex examples, scenarios that can help people get started with real work and not just the theoretical easy path beginner stuff? Yeah. Uh, I would actually love to share my screen if that's okay. Oh yeah, sure. You can share that. I was going to Okay. Chrome always makes you hit four buttons to do this, but okay, there we go. So, two things I wanted to point to is one is workflow examples. It's a repo that we maintain and we use this for a lot of our demos, including the birthday card generator that I just showed. Um, we also have a flight booking app that uses durable agent like I was talking about. We show we show you how to run this on Postgress and there's also I have a PR to show you how you deploy this off of Verscell um as well. So we have a lot of examples here and the other thing that we're spending a lot of time on right now is the cookbook. So we'll be there's a lot more work coming onto this page with not just showing you like currently we we use this to show you a lot of common patterns within workflow. There's some there's some stuff that gets really interesting and exciting for the ways that we even use workflow at Versell. U for example, I just wrote this guide on using a distributed abort controller. So if you look at those primitives of hook and sleep and um steps, we think of those as primitives and then there's all of this fun stuff you can build on top. Um for example, Vzero uses distributed board controller as their mechanism of having um like the stop button work. So when you when you use a Vzero chat and you hit the stop button, we basically use a workflow with a support controller to stop all the ongoing processes in the background. Um, so we'll be adding even more stuff to this, but I think these are two good places to look at for examples of not just the basic simple code snippets, but where where you sort of go from where you go from there. Nice. And it is like fairly real examples. It's things that we've done at Versel and and some ideas that we've seen customers working with. So, I like that. Um, yeah, at this point, everyone is pretty much using AI coding agents. So, all of that's great for people to explore, but what about supporting coding agents? um like how easy is it for them to pick up this new workflow kind of way of working? Yeah. Um I kind of mentioned this earlier, but there's been two two great things that we've seen. One that um I mean agents have kind of picked up how to code the way that humans have been coding for a long time, right? All of this is trained from from the way that we like that we like programming. Um, so we found really early on when because there's a lot of ways that we could have taken the DX with workflows and we chose to do this thing that's extremely lightweight on the SDK that's mostly just JavaScript that's mostly just directives. Um, agents understand that well and it's very easy for an agent to model doing things in parallel at scale. Let me just promise all of them. If you if you want to do a step but you want to time it out, the pattern and workflow is you basically just do a promise.ra and you race your step with asleep. It's a very natural way to think about code and solve problems when you if you already know the fundamentals of JavaScript and agents seem to have captured that really well. Um and because they already know how to do the hard stuff, right? Um they know how to do to write extremely complex framework code like we use we use this we use it on next.js. We we use LMS with Nex.js all the time. um they have a great understanding of of uh infrastructure code or sorry of framework code that transfers really well into workflow when there isn't a lot of um when you aren't adding a lot of weight to the SDK in comparison it's also easy to have had an SDK with a ton of options with a ton of complexity right which makes it not just complicated for a human because then you have um tons of docs to read and this is kind of a problem that I had with the competition before starting on workflow was it often just felt like the DX of using a workflow system was it was great in theory but really hard to actually run in practice or I had to read this giant instruction booklet. agents also struggle with that because they either need to have the entire thing in context or if they do learn that you'd even see this in in certain other examples. Um they start to it gets really hard to change the SDK in the future but as you change things as you change versions old old models are still set in their ways and what they've learned. Yeah. Um so yeah one is just that we found agents to be so that's a long answer. We found agents to be really good at workflow and then of course we shipped a skill as well for workflow. So you can do npx skills add versell workflow. Um if you look at the skill which I think is is fun point to prove what I was just saying the the workflow skill basically just tells it to shows it a couple of very basic code examples of of how you can do stuff like race and then just points it to read the docs which we ship along with uh our npm package. Um, so the workflow agents essentially just look at the source code and end up being really good at writing workflows as well. Nice. And then that skill with the docs keeps it up to date on all the latest, which is nice. Right. Exactly. Keeps it up to date, keeps it pointing to the right version because you ship the docs along with your package. So if we change the SDK as well, but you're on an older version of the client, the few options that we do have, um, your LLM just has access to those locally. Nice. Uh we had another question come in the chat. This one is do we have scale numbers on how many workflows and subworkflows and steps we can have on a single run? Oh yeah that's yeah that's a that's a great question. So there your concurrency on workflows when deploying I'm assuming you're talking about versel when you deploy to versel the concurrency on steps and workflows are just limited by your versel function concurrency which I believe is something like 10,000 or 100,000 it's based on your uh tier but basically workflow itself doesn't add a limit in concurrency that said the runtime being able to run um like the way that suspension resumption basically works with workflow is that we keep we have this event log that we keep tracking all of the inputs and outputs of steps. So as your event log gets really large right as you either have a thousand steps one after the other or you have a thousand steps in parallel whatever it is you start to build up this event log and we have to keep loading the entire event log for replays as the workflow runs for longer. Um if if you're coming from the temporal world, I think this limit is 50,000 events or 50 megabytes in your total storage. We just published this on workflow. We have our own limits as well. Um I think it's on our it's on the basel docs which I can I can maybe like send you a link after. Um I have to find it. There is um I think our limits for this are you can run you can run a lot more workflows in parallel. You can start a lot of child workflows. None of those affect the event log. The thing that does affect the event log is doing a ton of steps in parallel. So when you have something like a th00and to 10,000 steps in parallel. You could start to hit timeout issues. You could start to have workflows just run for longer. Um, we've seen workflows that are we've seen agents that are doing 5,000 steps be just fine. They start to have like the last couple of steps start to hit 15 to 20 second long latencies between steps. So, based off of what your use case is, that could be really long or if it's a background task that needs to run for 5,000 steps. For some customers, that's fine. Uh, at the same time, this is a big focus on what we're doing on um workflow SDK 5. So a lot of what a lot of what we're doing with SDK 5 which is in beta right now is um we have now that we have the DX right we're trying to solve this replay problem entirely. So when you use something like temporal for example you eventually hit this limit and the solution has always been when you get to 5,000 events you should just kill your workflow and continue as a new workflow. You can already do that today with workflows. You can just start a new workflow if you wanted to. But the correct solution I think is being able to improve the runtime and have suspension and resumption be o of one instead of being tied to the length of the the event log. There is some work we're doing right now with a vasm snapshot based runtime that we're exploring to see if we can completely kill that replay at which point you could have arbitrarily high concurrency and arbitrarily long workflows runs. All right, we are getting very close to time. I want to be sensitive to that. So, one last question. Um, and you kind of started touching on this. What is coming next? What should people be on the lookout for? Yeah. Um, as we went G with workflow 4, like I mentioned, workflow 5 is currently in beta. Um, no timelines yet on when we plan to GA that. But the main focus with workflow 5 has been on performance like limits like I talked about with limits trying to make it so that you don't have to worry about continuing as new at some point. Um, also native concurrency controls. So in RFC we've had a lot of we've had on day one with workflow which is just like those primitives of step hook and time and weight and sleep. Uh we're adding a new primitive called lock which essentially just lets your workflow um wait for a lock wait for concurrency slot. So you could have 20 workflows that all run in parallel but you only have a concurrency of one per minute. They can all await a lock that just gets resumed as those locks open up. Um it's a really like nice native way to have concurrency at at scale and improving the agent streaming experience. It's one of the big use cases with workflows like I said is you could either use it for these traditional you know birthday card style workflows or you could use it for AI agents where we have a lot of opinions on that SDK and how it works with streaming and how it works with sandboxes. Um there's a lot more to come there with just improving the performance and improving the DX of the agent use case. Awesome. Lots to look forward to. We did get a couple more questions. We will answer those async in the chat. Thank you so much for being here to talk to everyone, Bnee. Yeah, thanks so much, Amy. This was fun. All right, and thank you all for watching. We have another session with some folks from next on Thursday. So, uh, come back Thursday. We'll see you then.