Yesterday morning I wrote a Slack agent in Val Town using Vercel's AI SDK, and yesterday afternoon it became obsolete.
Just after I'd written a docs guide and recorded a demo video, I saw the announcement: "Today, we're open sourcing the new Chat SDK in public beta." By this morning, I learned that the Chat SDK, which paves Vercel's new Slack bot happy path, has already been renamed to "Chatbot." What will happen tomorrow? Or next week? Heaven forbid you go on a family vacation.
I'd written my Val Town agent—named duck, as in rubber duck debugging—and accompanying guide based on Vercel's now-stale Slackbot Agent Guide. That guide and its companion repo—last commit 8 months ago, an eternity in AI Land—uses the AI SDK v4. But they're already on v6. If even they were two versions behind on their own framework, imagine where that leaves the rest of us.
Just about every software vendor you use has their own AI agent with a punny, on-theme name.1 (Not to throw stones or anything—at Val Town we have Townie.) All those bespoke agents will always be behind, using yesterday's framework or model. It's ok to be behind ("if it ain't broke..."), but you should control when you are behind and when you want to catch up. You should Bring Your Own Agent.
BYOA—in Val Town or elsewhere
I've found Val Town to be quite a good place to write and run code, including agents. I thought so for two years as a regular user, and I think so now that I've been working here a couple months. It's "a nice place for JavaScript," as one of our users recently put it. But before I tell you why I think it's good, I should say: you may prefer to BYOA elsewhere, which is just as well. I don't know what tools you're familiar with and what you prefer. The important thing is that your agent answers to you—not your vendor.
Val Town is designed to have credible exit, meaning if you ever want to move your code elsewhere, you can do so easily. You can credibly exit. It's anti lock-in. Just like how when you own a domain name, you can transfer it to another registrar, or move your website hosting between providers, or change email clients. Val Town code runs on the Deno runtime and emphasizes Web-standard and mature technologies: JavaScript (or TypeScript), npm packages, SQLite, et cetera. So if you BYOA in Val Town, you can later port it over to Vercel or Netlify or AWS, or wherever.
Now, I like building agents (and many other things, but not everything) in Val Town because it removes the deployment step, such that I don't even think about it. Vals auto-deploy on save in 100ms, and you get a live URL. The feedback loop is very fast. There's no local versus staging versus prod environment (although there is branching for safe code changes). When collaborating with coworkers or sharing code with friends and strangers, there's no local dev setup—instead, they just remix your val or create a new branch. At this point in the paragraph my salesiness barometer is reading too high, and it'll probably only get worse in the next section about Kilo Code's agent val, so I'll transition by saying: it's totally reasonable if you want to BYOA on [insert hosting provider here]. I like Val Town, but YMMV.
Case study: Kilo Code's customer support agent
Last week, Steve (and Townie) from our team and Alex from Kilo Code set aside 8 hours to get a customer support bot agent2 up and running on Val town. But they only needed 89 minutes.
I watched a recording of Alex and Steve's meeting to inform my work on the aforementioned Slack agent. It really was, like, surprisingly easy. Here's some verbatim dialogue from the crux of the meeting, screenplay-style (stage directions added):
The point this scene is supposed to illustrate is that setting up the agent was easy, even fun. But the more important, practical point that you can rehearse and repeat to your boss (or your boss's boss) in the architecture meeting next week is what Alex wrote about in his blog post:
Every SaaS platform you use is shipping an AI agent add-on right now. Your support tool has one. Your CRM has one. Your project management platform probably just announced one last week. They all cost $500–$1,000/month. They’re all black boxes. And if your experience is anything like ours, they mostly don’t work.
And these black box SaaS agents won't obviously be a hot mess, not at first. They'll boil you slowly, like a frog. Of the customer support agent that Kilo Code tried for a month before BYOA'ing, Alex wrote:
It wasn’t bad enough to reject on day one — it was bad in the slow, corrosive way that wastes your time: almost good enough, but never quite right, and no levers to pull to fix it.
So Kilo Code rolled their own agent with Val Town and the Kilo Code AI Gateway. Tomorrow or next week or next month, when a new model or better tools come out, they'll be in control.
BYOA
"Bring Your Own Agent" (not a new term, btw) feels like the right pattern for this build-don't-buy moment, and Val Town might be the right place to do it. But again, I don't want to oversell. We are pickling compute, and BYOA is the new flavor. Chances are your company is already (or will soon be) hiring agents to work alongside you: for customer support; for data analytics; for fraud detection; for code review; for lots of things. Maybe you'll build them on Val Town.
(1) As far as punny AI agent names go, I think Gusto's Gus is pretty damn good. I like Townie, too. But my favorite robot name, hands down, is Kroger's inventory-taking robot, Tally.
(2) Here, and everywhere in this post, I mean "agent" as in Simon Willison's definition: an LLM running in a loop with tools—definitely not agent-as-human-replacement.