Daniel Lee

Oh my god it can sing in Korean too

Self-hosting Cursor Agent SDK on Agent Substrate! On the surface, Cursor's new Agent SDK looks a lot like Vercel's eve: file-based routing that helps developing custom agent intuitive. Architecturally though, the way these agents runs and scales are totally different! Unlike eve, which runs the agent loop (the "brain") on your machine, Cursor's Agent SDK runs the loop on Cursor's servers. Even when you "self-host" a Cursor agent with this SDK, you are really hosting the environment (the "hands") and the session storage that the "brain" on Cursor's server reach out as a tool! It's an interesting split. In this setup, I end up worrying a lot less about system prompts, the loop, durability, and how to roll the versioned agent forward. Instead, I just focus on the environment and tools to give Cursor, while it runs the brain on the same harness I already use and trust from Cursor. It ends up feeling more like Managed Agent APIs from Claude/OpenAI/Deepmind than building a custom agent from scratch! Running the Agent SDK program as an "actor" on Agent Substrate still makes it easy to suspend, resume, and fork sessions from a snapshot, which makes managing a fleet of Cursor agent sessions clean and predictable.

A follow-up to my Drive-as-Durable-Objects thread. I tried the model on a fx0's fork as its backend. Each chat gets its own Drive and Sandbox. I write the program for one "actor". The resulting programming model and the simplification of the system design is really nice! It got rid of Redis, Postgres, Vercel Queues and Blob. The code that runs a chat was simple to write, though my fork also removed some requirements quite a bit not apples to apples here. Everything is a tradeoff! Compared to the original, opening a dormant chat boots a sandbox VM (1.5–3 s), listing chats across users needs a database again, and a turn cut off by a crash gets stuck sometimes. Building multitenant service on functions is a better way to get the most bang for your bucks.... But still bullish that this might be the way we write and scale our agents!

@LukePS @vercel

Been playing with Vercel Drive this week and I keep wondering... did Vercel just ship Durable Objects? Hear me out - Create a named drive, attach a sandbox, and you’re guaranteed only one active instance is ever touching that state. Write a program around that and you start tapping into the exact programming model that makes Durable Objects so good. It's a fun inversion of roles. You stop thinking of a drive as something you attach to a sandbox. Make the drive the main character, and attach a sandbox to bring its state to life. I tried replicating an agent substrate demo I had built before using Vercel Drive, and really like how it feels. e.g. take Pi Durable. Pi checkpoints each step to a SQLite file on the drive. When the sandbox stops, even mid-turn, state in the drive is durably stashed away, and you can later attach a new sandbox to pick up the conversation right where it left off. Reminds me of when I first learned about Durable Objects and how it warped my mind a bit. Can't wait to play around with this more.

Great release from fx. Between this and Pi Durable few weeks ago, feels like we are getting a glimpse of what agent SDKs and infra are converging towards. Running fx on Agent Substrate was super smooth. Event streaming in fx in particular was really cool. Excited to see what's coming next.

@vercel ship

> Ryan and Bert will be leading a new effort to make workerd self-hosting a first-class supported way to build and run apps using the Workers programming model. This will involve merging code and ideas from celld back into workerd. Celld was a fantastic project. Happy for the Deno team.

Just got Pi Durable working on top of Agent Substrate, and they fit together so naturally. Pi generates session checkpoints to SQLite. Agent Substrate takes care of saving and loading snapshots, graceful suspend/awake. Even forking a pi session all just work out of the box. Beautiful abstractions working together 😍