Agent Harness Framework launches with Daytona default sandbox

• FredKSchott's launch post introduced Flue as a TypeScript "agent harness framework" that packages headless, programmable agents around skills, context, and AGENTS.md, with the official GitHub repo positioning it as a framework rather than another SDK.
• The launch pitch is a familiar coding-agent stack without the operator UI: according to Schott's overview, Flue aims to feel like Claude Code while running as plain TypeScript, and the Flue homepage shows the same pattern in a triage.ts example.
• Sandbox choice is the most concrete technical detail: daytonaio's repost pushed Daytona as the default integration, while the repo README says Flue defaults to a built-in virtual sandbox powered by just-bash unless you opt into a full container.
• Early traction was fast but still obviously early stage, with FredKSchott's follow-up reporting 35 pull requests in the first day and his reply about Astro repo experiments framing Flue as a testbed for new contribution workflows.

You can browse the source, skim the Cloudflare deploy guide, and inspect the session implementation, which imports @mariozechner/pi-agent-core. The launch also landed in the middle of a broader "agent harness" moment, with Deep Agents deploy shipping its own packaging story and Zach Mueller's stream plan turning harness design, security, and testing into a live coding topic.

Flue's core claim is simple: an agent is model plus harness, as Vtrivedy10's reply put it, and the harness is where session state, tool use, skills, and guardrails live. The official launch site and repo both show the same pattern: initialize an agent, open a session, call session.skill() for structured workflows, then use session.prompt() and shell commands for the rest.

The examples in Schott's launch screenshot keep most of the orchestration logic in Markdown files and config, not in long TypeScript control flow. That is the part agent-framework builders will recognize immediately.

The sandbox story is where the launch gets more specific, and slightly messier. Daytona celebrated being "already integrated as the default sandbox" in daytonaio's repost, but the official README says Flue defaults to a virtual sandbox powered by just-bash, with Daytona used when you opt into a full container sandbox.

That split shows up directly in the examples:

• The quickstart in the repo uses the built-in virtual sandbox by default.
• The Cloudflare path uses a virtual filesystem-backed sandbox for fast stateless agents in the deploy guide.
• The coding-agent example switches to Daytona for a real Linux container with persistent filesystem and shell access in the README.

Flue is shipping into a market that is suddenly full of harnesses trying to become deployment products. hwchase17's DeepAgents deploy thread described a deepagents.toml config with agent, sandbox, auth, and frontend sections, while the official Deep Agents docs pitch 30-plus endpoints, open protocols, and pluggable sandboxes including Daytona.

Against that backdrop, Flue's differentiator is less "agents can use tools" and more "headless coding-agent ergonomics as a framework." That is also the question jakemor's reply immediately pushed on, asking whether the real innovation is seamless sandbox execution.

One extra reveal sits below the marketing layer. The linked session.ts file imports Agent and related types from @mariozechner/pi-agent-core, which is why badlogicgames' reaction clocked that Flue is built on pi.

That means Flue is not only borrowing the UX shape of tools like Claude Code. Part of the runtime stack is also compositing on top of an existing agent core, which makes the launch feel a bit more like Astro-for-agents by way of pi modules than a greenfield runtime rewrite.