Flue turns the agent demo problem into a TypeScript runtime problem
The hard part of using AI agents is no longer getting one to do something impressive in a demo. It is getting many of them to run unattended, remember what they did, use tools safely, and fail in ways a developer can inspect afterward. Flue, a new TypeScript framework from Astro creator Fred Schott, is aimed squarely at that problem.
Schott introduced Flue as "the first agent harness framework" in a post on X on May 1, 2026. In plain English, a harness is the software around an AI agent: the box that gives it tools, limits where it can write files, keeps track of a work session, and lets it run without a person clicking through every step. That is the useful claim. Flue is not another chat wrapper. It is an attempt to make the control layer around coding agents feel like normal application infrastructure.
The project's GitHub README frames Flue as a headless system: "No TUI. No GUI. Just TypeScript." That matters because many coding-agent tools still inherit the assumptions of human-facing developer software. They expect an interactive terminal, a local machine, and a user in the loop. Flue's bet is that agent infrastructure needs the boring shape of normal application infrastructure: packages, adapters, persistent sessions, deploy targets, and a security boundary that can survive outside a laptop.
The code backs up more of that claim than the launch post does. The Flue repo lists three packages — @flue/sdk, @flue/cli, and @flue/connectors — splitting the core SDK, command-line runner, and third-party sandbox integrations. The root package.json says Flue requires Node.js 22 or newer, a small but useful tell that this is aimed at current server-side JavaScript runtimes rather than a browser toy.
Flue also makes a specific sandbox choice. Unless developers opt into a full container sandbox, the framework defaults to a virtual sandbox powered by just-bash from Vercel Labs, which the README describes as faster and cheaper than containers. A sandbox is the box around an agent's commands: where it can write files, what tools it can touch, and how much damage a bad instruction can do. That is not decoration. If agents are going to run unattended in CI systems, cloud workers, or pull-request flows, the sandbox becomes the product surface.
The other serious design choice is portability. Flue says developers can write once and deploy agents to Node.js, Cloudflare Workers, GitHub Actions, and GitLab CI/CD. On Cloudflare, the README says session data is backed by Durable Objects, Cloudflare's stateful coordination primitive for keeping data tied to a running service. In plain English: Flue is trying to make an agent session behave less like a local terminal transcript and more like a deployable web-service session.
There is a catch, and it is an important one. The agent runtime itself is not wholly invented inside Flue. The SDK package depends on @mariozechner/pi-agent-core and @mariozechner/pi-ai, which means Flue is, at least in part, a framework around another agent core. That does not make it fake. Web frameworks routinely wrap lower-level runtimes. But it does make the dependency graph visible, and that is healthier than pretending every new agent SDK sprang fully formed from a README.
The Model Context Protocol, the increasingly common standard for connecting agents to external tools and data sources, is present but not load-bearing. Flue exposes MCP through connectMcpServer(), an opt-in adapter that connects to a remote server from trusted code and passes its tools into the agent. That is the right direction architecturally: MCP is treated as one tool interface, not the religion.
The most direct competitive reference is Mastra, the TypeScript agent framework that already gives developers workflows, memory, tools, and model-provider abstractions. Where Mastra treats agents as application components with deep workflow orchestration, Flue's sharper claim is the harness layer specifically: the part that replaces a human-operated Claude Code-style session with something headless, sandboxed, and deployable. The architectural distinction is real, and it points to a broader question the industry has not answered — whether the agent itself is the product, or whether the harness layer is where the real engineering value concentrates as this market matures.
That is still early. Flue's SDK package is at version 0.3.6, and experimental agent frameworks have a way of discovering their real requirements only after users try to run them somewhere unfriendly. The next test is not whether developers like the launch tweet. It is whether Flue can hold onto its clean harness idea once real projects ask for secrets handling, long-running jobs, flaky tools, multi-agent coordination, and all the other sludge that turns agent demos into infrastructure.