Flue launches headless TypeScript agent harness with 43-line starter runtime

• Flue shipped as a TypeScript framework for autonomous agents that FredKSchott's launch post describes as Claude Code-like, but fully headless and programmable.
• The core pitch, on both the launch thread and the Flue homepage, is that most agent behavior lives in Markdown files such as skills, context, and AGENTS.md, not in a large application wrapper.
• A follow-up demo from FredKSchott's 43-line starter post points to a minimal vibecoding-style runtime, while the GitHub repo frames Flue as a framework rather than "another AI SDK."
• Official docs say the same agent can target Node, Cloudflare Workers, GitHub Actions, and GitLab CI/CD, and the Cloudflare deployment guide adds automatic HTTP routes, typed outputs, and a default virtual sandbox.

You can browse the source, read the Cloudflare deploy guide, and the official site even lays out Flue's stack as model, harness, sandbox, and filesystem on one page. Fred Schott also points straight at the framework's intellectual lineage: Addy Osmani's writing on harness engineering, plus a public nod to pi-agent-core as an implementation dependency.

Flue's cleanest idea is to treat the harness as the product. Schott says the framework is built around a first-class agent harness, and later agreed with his reply on harnesses as the defining line that this layer is what separates an agent from a chatbot or script.

The official site turns that into a concrete stack:

1. Model: tokens, tools, prompts.
2. Harness: skills, memory, sessions.
3. Sandbox: bash, security, network.
4. Filesystem: read, write, grep, glob.

That breakdown matches the way Flue examples are written in both the homepage code samples and the repo README. A handler initializes an agent, opens a session, calls session.skill() or session.prompt(), and leaves most reusable behavior in Markdown-defined skills and AGENTS.md.

The official materials keep repeating one operational claim: write once, deploy anywhere. The homepage lists Node, Cloudflare, GitHub Actions, and GitLab CI/CD, and the README adds examples for local CI runs, HTTP-triggered agents, Cloudflare-backed support bots, and containerized coding agents.

The Cloudflare guide is the most concrete piece of documentation:

• triggers = { webhook: true } exposes an HTTP route automatically.
• init() without a sandbox argument defaults to a virtual sandbox powered by just-bash.
• Result schemas use Valibot so agent outputs come back typed.
• npx flue build --target cloudflare produces a Workers target for deployment.

The repo positions that virtual sandbox as a default, not a fallback. In the README, the project says avoiding full containers makes agents faster, cheaper, and easier to scale for high-traffic workloads, while container connectors stay available for heavier coding-agent setups.

One of the more interesting side notes in the launch-day replies is that Flue is not built from scratch end to end. After badlogicgames linked the session implementation, Schott replied that he "genuinely couldn't have done it without pi-agent-core" in his thank-you reply.

That exchange also turned into a light public cross-pollination moment. badlogicgames asked whether pi-coding-agent could borrow some of Flue's abstractions, and Schott answered that he was "not mad at all."

For a low-key launch, that is a useful tell. Flue is arriving as a framework layer on top of an existing agent runtime ecosystem, not as a sealed product with a custom interface bolted on later.