V3 is here

After 300 thousand lines of rework and code trimming, V3 is here.

How we got here

I have been working on reworking our CLI to remove the runtime overhead for a while. For a long time now you've been able to use the services from our systems by importing the dedicated npm packages and putting the Agentuity secrets in your project.

But the problem still remained, and it's feedback we've been hearing from clients for a while:

"I just want to have my NextJS/Tanstack/Vite/Svelte project and use Agentuity stuff in it."

Well, good news! Now you can!

We now support custom deployments, which bring many frameworks with them out of the box.

Currently in our system we have successfully deployed:

Next.js
Astro
Hono
Nuxt
Qwik
Svelte
SolidJS
Angular
Mastra
Pure HTML

Yes, including plain HTML. If it can run in Node, Bun, or Python, it can run on Agentuity. That list mixes web frameworks (Next.js, Astro, Nuxt, Svelte, etc.) and AI frameworks like Mastra, and AI SDKs like the Vercel AI SDK or LangChain work too — you're just bringing your normal project. Your workflow becomes using the CLI to add our services to your project, then deploying straight from there.

The workflow is simple: build with what you're used to, then just hit agentuity deploy and you're done.

What it took to get here

Now, let's talk a bit about my favorite subject: refactoring.

What it took for us to get to this point, and what really changed from v2 to v3.

Here's what mostly changed.

v2 is a runtime, v3 is CLI + service packages

In v2, we kept the logic we'd been bringing since v0. We made a runtime, full of primitive support for all the things we considered at the time to be essential for the AI future. Things like out-of-the-box support for streams, websockets, evals, vector, database, and storage. A lot of it was well thought out, with the idea in mind that people would treat Agents as their own primitive — that Agents were things that would be part of your infra in a dedicated space and do quite a lot of work for themselves.

In v2, Agents were separate concepts from your routes and from the rest of your app. They were treated as their own thing: they had a dedicated workflow to include them, a specific folder they could go in, and dedicated pages to check how they work in an isolated space (including evals).

project/
└── src/
    ├── web/
    ├── api/
    └── agents/   ← Agents were first-class, sitting alongside web and api

The problem is that nothing was stopping users from ignoring that standard. What usually happened with most AI code harnesses, and with most users who weren't familiar with our system, was that they would just call their AI clients directly from inside the "api" folder (which contained a simple Hono abstraction), completely circumventing the "Agents" structure and its first-class nature. We tried many ways of fixing that behavior with AGENTS.md files, skills, comments, adding CLI commands for adding agents, and so on. But the truth is that we really didn't need that abstraction.

All we needed was to give users all our Service usage that was injected into the Hono context as dedicated or unified packages, and then let them structure their code as they want.

What exactly is an Agent?

So, I've been talking about Agents for a while now. For the people who aren't familiar with what we build, I'll explain what they did in the old system and why, in my view, they ended up being an unnecessary abstraction.

In v1 and v2, Agents were first-class primitives in the metadata and visualization sense — they were shown and integrated separately from the rest of the pipeline. But internally they ran inside the normal application flow: they didn't run in dedicated sandboxes, nor were they anywhere analogous to "serverless functions". They were essentially just JavaScript objects with a lot of utility baked into them, more specifically IO schema validation and context sharing with Hono. At some point we also added evals, which used that isolated, in-code nature of Agents to run directly against them.

My first thought after going through how it all worked was: "What is stopping this from being an async function that just uses everything it needs from Hono itself?" The answer? Nothing. Our abstraction for Agents was done only to facilitate a mental model in which AI calls should be isolated blocks of code — which, in the end, didn't really enforce anything meaningful.

When it came to the whole "AI calls that run isolated" idea, we ended up solving it another way, using sandboxes. So, in the end, we decided to do away with the Agents model in favor of giving users freedom in how to orchestrate their systems.

Problems with the "bakery"

I mentioned in the previous post the issues we ran into trying to build our system on top of Bun. We ended up doing a lot of patching of Bun features on our side, especially their WebSocket upgrade system, which was broken for about a year or so.

I still love the speedup Bun brings to the dev experience, and their test library is pretty good. But in the end, building our system on top of Bun caused more cons than pros. We would need to keep users tied to Bun and keep fixing it whenever a new regression came along. The Bun team has also shown little interest in resolving these issues.

So even though we really liked building on top of it, I decided that it would be better to port back to Node as our primary runtime. That, in itself, was one of the main reasons v3 took way more time than I expected. A lot of our system needed to be redesigned with the assumption that users could now be on any runtime. So some things we did in the Bun world, like our Storage system, had to be abstracted into their own packages.

That's why packages like @agentuity/storage had to come into existence — because the magic we did behind the scenes to make these things work out of the box wouldn't translate very well to a Node-first ecosystem.

Focus on the objective and the mission

We discussed at length what the focus of the company was, but being a small team, we could not tackle everything all at once. So we came up with a simple rule:

Agentuity is an infrastructure company.

No building our own dedicated runtime/framework or AI SDK. That's also what keeps us different from generic deploy platforms — the agent-native pieces (gateway, observability, sandboxes) come built in, not bolted on.

That meant we should give users tools to build with AI — pretty much all the things they'll need when building any kind of system that uses AI Agents to accomplish anything: databases, vectors, sandboxes, and some extra niceties.

None of this meant we actually needed to railroad users into a specific runtime. So we decided to focus on making all our services into dedicated packages, letting users pick what they want, and letting them deploy whatever they want to our system.

The funny thing about all of this is that our backend itself was already ready to accept this deploy-anything structure. Of the 300-thousand-plus line diff that v3 brought, maybe less than 200 lines (two hundred, not two hundred thousand) were backend changes. Almost all of it was SDK/CLI changes. Thanks to Jeff and the backend team for building such a solid and flexible infrastructure.

How about my v2 projects then?

For the customers we have who've been using our system since either v1 or v2, the @agentuity/migrate package should help port the big things. This command will get rid of our abstractions and leave you with a very basic Hono + Vite project that should still deploy and work just fine inside our systems. For anything the tool can't migrate automatically, it will guide you through it.

There's also the option of just porting your apps to whatever you feel comfortable using — I recommend this. If your backend and frontend are interlaced and you just want to have it working, Next.js and TanStack Start are solid options. Your coding agent should be able to port most projects after @agentuity/migrate has run.

We'll also help if you need it — feel free to contact support or email us directly.

Try it

New project: bun create agentuity
Existing v1 or v2 project: bunx @agentuity/migrate
Existing app on any framework: npm i -D @agentuity/cli, then npx agentuity project import or npx agentuity deploy

That's it. Bring your NextJS/Tanstack/Vite/Svelte project, and use Agentuity stuff in it.

And what is in the future?

Currently, I'm completing as much compatibility as possible with other languages and frameworks. In a perfect world, we want to support deployments in any language people are using. For the near future, Python and Go are on the roadmap, with things like Serverless planned further out. You'll hear more about this in a future blog post. We'd also love to hear what you want to deploy on Agentuity — join our Discord and let us know.

The Path to Being Agnostic - The v2 retrospective and the road to v3
Agentuity v1 Is Here - The original v1 announcement
Why AI Agents Need Purpose-Built Infrastructure - The case for agent-native infra
AI Agent Runtime - Understanding the runtime architecture

Resources