Flue is an open-source, deploy-anywhere agent framework from the team behind Astro. It hit 1.0 Beta in June 2026 and has since shipped 2.0, its first stable release. Here's what it does, how it differs from Vercel's eve, and what it means for anyone scoping an agent project right now.
June 2026 was the month agent frameworks grew up. Vercel shipped eve. Cloudflare opened up its Agents SDK. And Flue — an open agent framework from the team behind Astro, the popular web framework — reached 1.0 Beta the same week, after months of public iteration. It has since shipped Flue 2.0, its first stable release. The positioning is pointed: write once, deploy anywhere, use any LLM.
If eve is "Next.js for agents," Flue is making the Astro play: open, vendor-neutral, and built to run on whatever infrastructure you already use. Here's what that means without the jargon.
First, a word you'll keep seeing: "harness"
Flue's documentation is built around one clarifying idea. An AI agent is an LLM running inside a harness. The model provides the reasoning; the harness provides everything else — the tools it can call, the memory it keeps, the environment it works in, and the loop that keeps it going until the task is done. Without a harness, a language model is just a chatbot answering one message at a time.
Flue doesn't build its harness from scratch. It runs on Pi, a minimal open-source agent harness (the same one that powers OpenClaw) that has become something of a shared engine in the TypeScript agent world. Flue is the framework layer wrapped around it: project structure, conventions, integrations, and a CLI.
This layering matters more than it sounds. When Cloudflare opened its Agents SDK to outside frameworks in June, Flue was the first officially supported one — precisely because the framework, harness, and runtime are cleanly separated. You can swap the bottom layer without rewriting your agent.
Agents as functions
Flue's signature design choice — introduced with Flue 2.0, which rebuilt the framework around a new Agent Hooks API — is that an agent is a TypeScript function. If you've ever seen React code, the style will look eerily familiar: a minimal Flue agent uses hooks like usePersistentState to remember things across sessions, useModel to pick which LLM it runs on, and returns its instructions as plain text. The idea is agents that can evolve their own capabilities as their state changes, rather than being defined once and fixed.
The deeper philosophy, in Cloudflare's words when describing Flue: you don't script what your agent does, you describe what it knows. You define the context — model, skills, sandbox, instructions — and the harness figures out how to complete whatever task arrives. There's no orchestration loop to write. Much of an agent's actual expertise lives in Markdown files (skills) rather than code, which means the parts that define behavior are readable by anyone, not just developers.
What ships in the box
Flue covers the same production checklist that every serious framework has now converged on — a convergence worth paying attention to, and we'll come back to it:
Durable execution. Every session is recorded to a durable stream. If the server crashes or a deploy interrupts a task, the agent resumes where it stopped instead of starting over. Accepted work is never lost.
Sandboxes. Agents get a secure environment to run commands and edit files, with pluggable backends (Daytona, E2B, Vercel Sandbox, or a local option) — so agent-written code can't touch your real systems.
Tools, skills, and subagents. Tools are code the agent can call. Skills are packaged expertise loaded when a task needs it. Subagents are specialist roles the main agent delegates to. Plus MCP support for connecting to thousands of external tools.
Channels. The same agent can live in Slack, Teams, Discord, GitHub, WhatsApp, Telegram, or respond to Stripe and Shopify events — each channel is an integration, not a rebuild.
Deploy anywhere. This is Flue's sharpest edge. It runs on Node.js, Cloudflare Workers, Docker, AWS, Railway, Fly, Render — the ecosystem page reads like a menu, not a mandate. It's headless by design: agents can be triggered by API calls, webhooks, or cron jobs with no human in the room.
One more telling detail: the very first call-to-action on Flue's homepage is a prompt you paste into your coding agent, which then reads the docs and builds your first Flue agent for you. The framework assumes AI is doing the assembly.
Flue vs. eve: the real difference
If you read our eve breakdown, you'll notice the feature lists are nearly identical: durability, sandboxes, tools, skills, subagents, channels, observability. The genuine differences are philosophical:
Lock-in. eve deploys to Vercel at launch, with the platform's infrastructure (Workflows, Sandbox, AI Gateway) doing the heavy lifting. Flue is aggressively runtime-agnostic — any LLM, any cloud, any sandbox. If vendor independence matters to your business, that's a real distinction, not a marketing one.
Style. eve is filesystem-first: an agent is a directory, and files in conventional locations define what it is. Flue is code-first: an agent is a function, composed with hooks. Directories versus functions is genuinely a matter of team taste.
Origin. eve is how Vercel runs its own hundred-plus internal agents. Flue grew out of the Astro team automating its own GitHub workflows, then generalizing. Both are battle-tested; they were just battle-tested on different problems.
For a non-technical founder, here's the honest takeaway: your developer or agency will have an opinion between these two, and either is a credible choice. What you should notice is what both of them are telling you.
Two frameworks, one anatomy
Within a single month, two independent teams — with different philosophies, different business models, different code styles — shipped frameworks with the same component list. Instructions. Tools. Skills. Subagents. Sandboxes. Channels. Schedules. Approvals. Durability.
That's not coincidence. It's the industry converging on the anatomy of an agent. The vocabulary is settling, which means agent projects are becoming specifiable — you can now describe an agent completely, component by component, before anyone picks a framework at all.
And that's the part no framework decides for you. Flue will happily run whatever agent you define, but which tools it needs, what belongs in its skills, where a human should approve an action, whether the job is one agent or a delegating team — those are design decisions that exist upstream of the code. Get them right first, and a Flue build (or an eve build) becomes translation. Get them wrong, and no amount of durable execution saves the project.
Name every component before you build. The framework is a choice you make second.
Your agent starts with a blueprint. Build yours free →