Workflow Examples is a catalogue of working DevKit projects, not a library

A directory of projects rather than a package you depend on

The README describes the repository in one line: a directory containing different examples of how to use the Workflow DevKit. That wording sets the expectation, and it is worth being precise about it because the repository is easy to mistake for a library. There is no published package here, no import to add to a dependency list, and no version to pin. The top-level entries are the example projects themselves, each in its own directory, alongside a README, a LICENSE and a .gitignore.

The primary language of the repository is TypeScript, the licence is MIT, and there are no GitHub releases, so the history of the examples is the git history. The last push was on 2026-10-01 and the repository is not archived. The project website is workflowsdk.dev, which is where the documentation about the DevKit itself lives, since the repository documents usage by example rather than by reference.

What that gives you is a working reference for each pattern, in a form you can read end to end. What it does not give you is a supported API surface, and the absence of install instructions in the README is a fair signal that these are meant to be cloned and run rather than consumed.

Eight frameworks, which tells you where the DevKit attaches

The framework integration list is the most informative part of the README for anyone deciding whether the DevKit fits their stack. There are eight entries: Astro, Hono, Next.js, Nitro, Nuxt, SvelteKit, TanStack Start and Vite. Each has its own top-level directory in the repository, and each directory is a complete project rather than a fragment.

The spread is instructive. The list covers a full framework with server rendering, a runtime-agnostic web framework, several meta-frameworks, a server engine, and a bare build tool, which suggests the DevKit is not tied to one deployment model but attaches at a level below the routing layer. It also means the examples are not interchangeable: a workflow in the Hono example and a workflow in the Next.js example sit in different places in the request lifecycle, and the surrounding conventions differ.

For a reader, the practical consequence is that the framework example closest to your own stack is the one worth reading first, and the others are worth reading later for the pattern rather than the plumbing. The README does not describe a shared setup command across the eight, so each directory is its own starting point.

The custom adapter example is the one that shows the seams

Most examples demonstrate a workflow on a framework the DevKit already supports. The custom adapter example does something different, and it is the most instructive directory in the repository. The README describes it as an example of building a custom adapter to run workflows on other frameworks and runtimes, and it names Bun as a case.

That single line tells you the architecture. The DevKit does not own every runtime it can run on; there is an adapter layer, and an adapter is something you can write. The built-in framework examples are therefore instances of the same contract, and the custom adapter example is the case where you author one yourself.

This matters for a reader who wants to understand the DevKit rather than just use it, because the adapter is where the assumptions live. Runtime, request handling, streaming and the way a workflow is scheduled all have to be expressed through it, and an example that shows the authoring of one exposes those assumptions directly. If you are running on Bun, or on any runtime not in the framework list, that example is the one to read before anything else.

Kitchen Sink is the reference implementation of the core patterns

The kitchen-sink directory is described as a comprehensive reference implementation of all core workflow patterns, and the list is the whole feature surface in one line: steps, control flow, streaming, AI integration, hooks, and batching.

Read as a learning order, that list is a sensible sequence. Steps are the unit of work, control flow is how steps are composed, streaming is how results are delivered while work is in flight, AI integration is how a model is called inside a step, hooks are how behaviour is attached to a workflow's lifecycle, and batching is how many items are handled together. A reference project that contains all of them, in one place, saves you from assembling that picture from eight separate examples.

There is a caveat about what a reference implementation is. It is optimised to demonstrate features, so it is rarely the shape you would ship, and it will carry patterns you do not need. The value is in reading the wiring rather than copying the file, and the fact that the README calls it a reference implementation rather than a starter is the signal. For a new user, this directory is the map of the DevKit's capabilities.

Two AI SDK examples, one about patterns and one about agents

The AI SDK appears in two separate directories, and the README positions them differently. The ai-sdk-workflow-patterns directory is an example of how to use the AI SDK to implement common workflow patterns with the DevKit, which reads as a catalogue of shapes for AI work: how a call is placed inside a step, how several of them compose, how results are streamed back.

The rag-agent directory is described more simply, as an example of using the AI SDK with the Workflow DevKit, and the name tells you the shape of the thing being built, a retrieval augmented agent. The two examples together cover the range from pattern to application, and the difference in framing is informative, because the pattern directory is the reusable part and the agent is the specific instance.

For a reader, the pairing is a good way to approach the DevKit if your use case involves models. Start with the pattern example to see how a model call is wrapped, then read the agent example to see the same machinery carrying a multi-step application. The kitchen sink also lists AI integration among its patterns, so a third read is available for the mechanics in the reference implementation.

Application shaped examples: cards, flights and FFmpeg

Three examples are whole applications rather than pattern catalogues, and each one tells you something about what the DevKit is for.

The birthday-card-generator is the smallest: an example of using the DevKit to build a birthday card generator. The flight-booking-app is the same kind of thing with more domain logic, an example of building a flight booking app. Both are the shape of a request that fans out into several pieces of work, which is the situation a workflow runtime addresses and where a single long request handler is awkward.

The ffmpeg-processing example is different in kind. The README describes it as an Express plus Workflow DevKit example for building FFmpeg-based media processing workflows, so the interesting part is that the work is CPU heavy media work rather than model calls, and the Express integration puts it on a plain Node server rather than a framework with its own conventions. Media processing is where the value of a durable workflow shows, since a transcode that takes minutes is exactly the kind of job that should survive a restart.

Together these three give a range of scales, from a small generator to a server with a media pipeline.

Two directories the README never mentions

The top-level listing contains directories that the README does not describe. Alongside the eight framework directories and the named examples there are an actors directory and a postgres directory, and neither appears in the example list or the framework list in the README text.

That is worth noticing rather than glossing over. It means the README is a curated index rather than a complete inventory, so the repository is likely to contain more than the eight examples it advertises, and anyone surveying what is available should look at the directory listing rather than at the summary. The two names suggest a project around concurrency primitives and one around a database, and either could be a standalone example or a shared dependency of another one.

The lesson generalises to the repository as a whole. A README that indexes its contents selectively is normal for a collection like this, where examples are added as they are written, and the practical approach is to browse the tree. The site at workflowsdk.dev is where the DevKit documentation proper lives, and the repository is where the code to read is.

Editorial conclusion

Workflow Examples fits an engineer who wants to see the Workflow DevKit used in a real project before writing one, and the kitchen sink directory is the place to start because it is the reference implementation of the core patterns. It does not fit as a dependency you install, since the repository holds example projects rather than a published package, and it does not document its own setup steps. Before you copy anything, check three things: that the example you plan to copy uses a framework you already run, that the example closest to your use case is the one whose runtime assumptions you share, since the custom adapter example exists precisely because the built-in ones do not cover every runtime, and that the framework list in the README, Astro, Hono, Next.js, Nitro, Nuxt, SvelteKit, TanStack Start and Vite, still matches the framework you use today. The licence is MIT, there are no GitHub releases, and the last push was on 2026-10-01.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vercel/workflow-examples on GitHub