eersnington

Context

• Optimize for: correct, performance, and maintainable changes
• Do not use submit_plan() unless the user asks to "submit a plan"
• Compose plans in mainly in call graphs and code that are easy to understand and follow
• Never create commits, PRs, or push unless explicitly requested and ask what should the commit message be
• Never add AI/Agent attribution or contributor status in commits,
• ALWAYS check for .jj/ before ANY VCS command; if present, prefer jj
• In colocated repos, use jj for normal workflow unless the task specifically requires git
• gh CLI available for GitHub operations (PRs, issues, etc.)

eersnington

This is a more structured draft on a way to cancel Workflow steps that I would like to see after I made an attempt at improving parallel execution of steps within Cloudflare Workflows with cf-forklift.

Some details may need a refresh and more thinking, but I wanted to post this to get thoughts and see if/where it breaks in the real world. Please do comment on how well/poorly this would work for different usecases as I think this can be iterated on and be shipped as a first class runtime API

I came across @wishee0's tweet about wanting feedback for cloudflare workflows, and saw that @ksw_arman from @thecontextco mentioned that wrapping parallel steps in promise.all() and promise.allSettled() isn't a great experience.

I've looked through the docs, fiddled around with the API and shipped a workflow app. And I do think that there's an opportunity here to improve this drastically.

// A deceptively simple example of parallel workflow step execution

eersnington

DurableAgent Feature Completion Specification

1. Objective

Bring @workflow/ai's DurableAgent to feature parity with Vercel AI SDK's ToolLoopAgent. This involves adding configuration for generation parameters, provider-specific options, observability hooks, and implementing the missing generate() method.

2. Reference Architecture

We are modeling this after ToolLoopAgent from ai. Reference Key Features:

• Generation Control: temperature, maxOutputTokens, topP, topK, seed, etc.
• Tool Control: toolChoice, activeTools, maxRetries.

eersnington

This PR completes the "Client Bundle" feature (client.js) in the Workflow DevKit builder. It transforms the client bundle from a one-off build artifact into a live, fully typed, and debuggable library suitable for development and production use. It also leverages this new capability to significantly simplify the developer experience for the workflow-express integration.

Key Features Added

1. Automatic Type Definitions (client.d.ts): Generates a TypeScript declaration file alongside the bundle, re-exporting original types.
2. Node16/ESM Compatibility: Automatically appends .js extensions to relative imports in .d.ts files, ensuring compatibility with moduleResolution: "Node16" or "NodeNext".
3. Watch Mode Support: Refactored to use esbuild.context to support incremental rebuilds. When workflow dev is running (or the builder is invoked in watch mode), changes to workflow code are instantly reflected in the client bundle.
4. Source Maps: Enabled source maps (inline for

eersnington

RFC For Deterministic pollUntil() function

Allow me a moment for my pessimistic side to take control of this gist to say that this RFC might be more of a Reasonably Futile Concept rather than being a Request For Comments. But I've been looking into the what, hows, and whys of this amalgamation of thinking tokens for quite a while with the current mental model of WDK, and maybe what can be done about it.

Ground Zero

Polling isn't ideal (side-note: I think WDK has the potential to cheat it), but I keep seeing this pattern of WDK code (and even my best friend when I showed WDK primitives) which made me go down this rabbit hole. I wrote this gist to spell out why is "call status -> sleep -> repeat" loop feels natural, how it actually plays with determinism, and what a first-class helper could do to make it easier for everyone.

1. The useReflex: I'll just loop and slap in an await sleep("15s")