Why Flue
Purpose and Scope
Flue exists for teams that need autonomous AI systems to do work, not just generate one response at a time. The Why Flue documentation frames the project as a TypeScript framework for autonomous AI agents and the workflows around them. The central problem is that many applications start with direct model calls, then quickly need continuity, controlled actions, files, routing, sandboxing, and deployment. Flue answers that need with a programmable harness: the environment, context, tools, and runtime boundaries that let a model operate safely inside software you own.
Sources: apps/docs/src/content/docs/introduction/why-flue.md
This page explains the motivation behind Flue rather than giving an API tutorial. It is intended for readers choosing between a generic LLM SDK, a workflow engine, a hosted agent platform, or Flue. The key distinction is that Flue is not positioned as a thin wrapper around model providers. It is a complete framework for agentic software, with agents, workflows, sandboxes, CLI support, tools, skills, MCP server connections, observability, and channels presented as built-in parts of the system.
Sources: apps/docs/src/content/docs/introduction/why-flue.md
Relevant Source Files
apps/docs/src/content/docs/introduction/why-flue.md— First-party motivation page that defines Flue as a TypeScript framework for autonomous agents, lists the main feature areas, and states the design principles: harness-first, open by default, and AI-first.
The Harness-First Motivation
The most important term in the Why Flue page is harness. A harness is the programmable environment you give to an agent: instructions, tools, skills, sessions, files, resources, MCP server connections, filesystem access, and sandbox execution. Instead of writing a rigid script that enumerates every step, you supply context and capabilities, then point a model at that environment. The documentation describes this as the architecture used by Claude Code and other coding agents, where the agent receives a task and uses the available context to solve it.
Sources: apps/docs/src/content/docs/introduction/why-flue.md
That difference is why Flue describes itself as “not another SDK.” A generic SDK usually helps an application call a model, pass messages, and receive output. That can work for chatbots or scripted tasks, but it leaves the model confined to the exact API calls and control flow the application author already wrote. Flue’s argument is that an autonomous agent needs more room than that. It needs a durable session, a set of typed ways to act, reusable knowledge, and an isolated place to inspect or change files.
Sources: apps/docs/src/content/docs/introduction/why-flue.md
How Flue Differs from a Generic SDK
A generic LLM SDK is often model-first: choose a provider, format a prompt, call an endpoint, parse a response. Flue is harness-first: define the environment in which a model can work. That includes agents that keep context across conversations and events, workflows for finite automations, sandboxes for safe execution, tools for typed API calls and data changes, and skills for reusable expertise. In this model, the provider is important but not the whole product architecture. The agent’s capabilities are shaped by your TypeScript harness.
Sources: apps/docs/src/content/docs/introduction/why-flue.md
Flue also differs by treating surrounding infrastructure as part of the framework. The documentation lists the CLI for local development, running jobs, and building deployments. It calls out observability integrations so teams can export telemetry through OpenTelemetry, Braintrust, Sentry, or their own observer. It includes channels for verified provider events and MCP servers for connecting tools and services through the open Model Context Protocol ecosystem. These pieces matter because production agents usually need ingress, auditability, external services, and deployment paths, not just prompt orchestration.
Sources: apps/docs/src/content/docs/introduction/why-flue.md
Design Principles
The Why Flue documentation names three design principles: harness-first, open by default, and AI-first. Harness-first means a model is pointed at a rich execution context rather than a prescriptive script. Open by default means Flue is designed around open choices for models, sandboxes, and deployment targets. AI-first means the framework is intended to be comfortable in workflows where developers use coding agents to build, inspect, and evolve the system. These principles explain both the product shape and the documentation spine.
Sources: apps/docs/src/content/docs/introduction/why-flue.md
“Open by default” is especially important for architectural evaluation. The docs explicitly contrast Flue with frameworks or SDKs that are closed in one direction: tied to their own models, their own sandbox, or their own cloud. Flue instead emphasizes open models, open sandboxes, and open deploys. The practical result is that a team can choose a supported LLM provider, connect a remote sandbox provider or use a built-in virtual sandbox, and build for targets such as Node.js, Cloudflare, GitHub, or GitLab.
Sources: apps/docs/src/content/docs/introduction/why-flue.md
Capability Map
| Capability | Why it matters in Flue |
|---|---|
| Agents | Keep context across conversations and events while working toward goals. |
| Workflows | Run structured automations from a defined input to a finished result. |
| Sandboxes | Give agents a secure environment for acting, running code, and using files. |
| Tools | Expose typed actions for APIs, queries, and controlled changes. |
| Skills | Package reusable expertise that agents can load when a task needs it. |
| Subagents | Delegate specialized work to the right expert role. |
| MCP Servers | Connect external tools and services through the open MCP ecosystem. |
| Channels | Receive verified provider events and route them to agents or application code. |
| Observability | Export telemetry through supported backends or a custom observer. |
Choosing Flue
Choose Flue when the system you are building needs autonomous work inside an application-defined environment. Good fits include coding-style agents, support or operations agents with verified channel ingress, background workflows with clear inputs and outputs, and systems that must combine model reasoning with tool calls, file access, sandboxed execution, and durable sessions. In these cases, the harness is not incidental infrastructure. It is the product boundary that determines what the agent can know, where it can act, and how safely it can recover from long-running work.
Sources: apps/docs/src/content/docs/introduction/why-flue.md
If all you need is a single request and response from one model provider, a generic SDK may be enough. If you need an agent that receives tasks over time, uses tools, loads skills, works in a sandbox, connects to MCP tools, responds to channel events, and runs across local development and deployment targets, Flue’s framework shape is the reason to use it. Next, read the overview for package orientation, the agents concept page for harness terminology, and the quickstart when you are ready to create a first project.