Most agent toolkits assume a human operator, a UI, or tightly coupled runtime constraints. Flue flips that assumption: treat an agent as a first-class, deployable runtime artifact backed by an agent "harness". That harness bundles sandboxing, tools, session state, and provider configuration so agents can run headless as services, CI tasks, or edge workers with orchestration expressed mainly in TypeScript and Markdown.
What Sets It Apart
- Harness-first architecture: harnesses group sandbox, tools, and session state so the same agent code can run unchanged across Node, Cloudflare, CI, or container sandboxes — which reduces per-host glue. (So what: you write one agent and deploy it in multiple runtime shapes.)
- Lightweight default sandbox with opt-in containers: a virtual just-bash sandbox is the default for speed and cost; Daytona connector and full container sandboxes are available when you need a real Linux environment. (So what: fast, cheap iteration for high-scale traffic and an upgrade path for full coding agents.)
- Runtime-agnostic provider and connector model: provider settings let you route model traffic or apply gateway credentials without changing prompts; connectors (Daytona, MCP, etc.) expose runtime tools consistently. (So what: enterprise routing, audit hooks, and secret management live in config, not in prompt text.)
- Session/task primitives and skill discovery: sessions, tasks, and a simple skill/AGENTS.md discovery model let agents orchestrate sub-tasks, persist state, and delegate work to child sessions. (So what: easier composition and long-running conversations with preserved context.)
Who It's For and Tradeoffs
Great fit if you need to ship autonomous agents as deployable services or CI-native workflows, want a TypeScript-first developer DX, and value a consistent runtime that separates orchestration from provider-specific plumbing. It matches teams that prefer keeping orchestration logic in code/Markdown rather than opaque UI tooling.
Look elsewhere if you need a GUI-driven authoring environment, are building purely research-only agent prototypes without deployment concerns, or require an ecosystem already centered on a specific provider's SDK with deep proprietary integrations. Flue favors runnable, production-shaped agents over visual tooling or notebook-style experimentation.
Where It Fits
Compared with general-purpose agent libraries, Flue emphasizes runtime ergonomics (harness, sandbox types, session/task model) and deployability. It competes more with frameworks that target production agent workloads than with quick prototyping notebooks or model-training toolkits.
