Flue Agent Framework
A programmable TypeScript harness that gives any model the context, tools, and secure sandbox needed for autonomous work.
- Source repo
- withastro/flue
- Stars
- ★ 8.6k
- Last updated
- 19d ago
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 47/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API · Claude API (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Bug-triage teams that want an agent to reproduce an issue, find the root cause, check intent and attempt a fix inside a sandbox
- Not a fit if
- Teams that only need simple chat without tools or sandboxes
- Users who want zero-code setup and won't write TypeScript
- Source review
- 47/100 · Major gaps
What does this agent do, and when should you use it?
Flue is a TypeScript harness framework for autonomous agents, deliberately positioned as more than an SDK. A developer writes one exported function, declares the model with useModel, a sandbox with useSandbox, reusable expertise with useSkill and typed actions with useTool, then returns a plain-language task instruction — the function itself is the agent. The runtime supplies sessions, tools, skills, filesystem access and virtual, local or remote container sandboxes, plus durable recovery for accepted work, subagents, MCP tool connections and verified event channels. It ships as @flue/runtime, @flue/vite, @flue/cli, @flue/sdk, @flue/opentelemetry and @flue/postgres, and deploys to Node.js, Cloudflare Workers, GitHub Actions, GitLab CI/CD, Daytona and Render. Observability can flow to OpenTelemetry, Braintrust, Sentry or a custom observer.
Agent files under agents/ use the 'use agent' directive and call useModel to pick a model, useSandbox to attach an environment such as local() from @flue/runtime/node, useSkill to load SKILL.md skill documents, and useTool to register typed tool functions like openIssue or searchCode; the returned string becomes the agent's operating instruction. At runtime the harness assembles context, loads skills and tools, lets the model read and write files and call tools inside the sandbox, and keeps progressing toward the goal across conversation turns and events, with durable recovery of accepted work after failures or restarts. It connects to MCP Servers for authenticated tools, receives verified events from Slack, Teams, Discord and GitHub through Channels, runs locally with the flue CLI, and is built and served via @flue/vite. Deployed conversations are consumed with @flue/sdk, and @flue/postgres provides persistence.
- Bug-triage teams that want an agent to reproduce an issue, find the root cause, check intent and attempt a fix inside a sandbox
- Platform teams piping verified Slack, Discord or GitHub events into autonomous workflows through Channels
- Engineering teams deploying an agent service on Node.js or Cloudflare Workers and wiring a frontend through @flue/sdk
- Long-running jobs that need durable sessions and recovery, with persistence via @flue/postgres
- Developers structuring complex work as specialized subagents that the main agent delegates to
How do you install or deploy this agent?
The README does not document a full install or scaffolding sequence (no package-manager install or init command is shown). The documented packages are @flue/runtime, @flue/vite, @flue/cli, @flue/sdk, @flue/opentelemetry and @flue/postgres; a Node.js runtime and credentials for your chosen model provider are required. The agent file itself is written as follows:
// agents/triage.ts
'use agent';
import { useModel, useSandbox, useSkill, useTool } from '@flue/runtime';
import { local } from '@flue/runtime/node';
import triage from '../skills/triage/SKILL.md';
import verify from '../skills/verify/SKILL.md';
import { openIssue, searchCode } from '../tools/github.ts';
export function Triage() {
useModel('anthropic/claude-sonnet-4-6');
useSandbox(local());
useSkill(triage);
useSkill(verify);
useTool(openIssue);
useTool(searchCode);
return `Triage a bug report end-to-end: reproduce the bug,
diagnose the root cause, verify whether the behavior is
intentional, and attempt a fix.`;
}How do you use this agent?
After composing the agent function, run it locally with the flue CLI or serve and build it with the @flue/vite plugin:
vite devvite buildThe flue binary provides local runs, blueprints and offline docs:
flueFor deployment, the README lists Node.js, Cloudflare Workers, GitHub Actions, GitLab CI/CD, Daytona and Render. Consume deployed conversations with @flue/sdk and export traces with @flue/opentelemetry.
What are this agent's strengths and limitations?
- One TypeScript function declares the whole harness — model, sandbox, skills and tools — in a readable, composable shape
- Offers virtual, local and remote container sandbox paths so agents can act on files and tools within a controlled environment
- Durable recovery plus a @flue/postgres adapter keeps accepted work moving through failures and restarts
- Connects to MCP Servers and verified Slack, Teams, Discord and GitHub events, and exports telemetry to OpenTelemetry, Braintrust or Sentry
- Concrete deploy targets: Node.js, Cloudflare Workers, GitHub Actions, GitLab CI/CD, Daytona and Render
- The README omits full install, scaffolding and configuration steps, so you must assemble the project layout and dependency versions yourself
- Tied to TypeScript and the 'use agent' function style, adding a learning curve for non-TypeScript teams
- Production use requires your own model-provider credentials and per-use billing
- Persistence, subagents and observability span several packages and external services, so a complete setup takes real configuration
How does this agent compare with similar options?
The README contrasts Flue with raw LLM API calls, which it says suit simple chatbots and scripted tasks, and with autonomous agents like Claude Code and Codex. Flue positions itself as a programmable, deployable harness that brings that same autonomous capability to your own agents.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Flue Agent Framework This agent | 47 · Major gaps | FrameworkFree + model costs | ★ 8.6k | 19d ago | TypeScript | — |
| Jev Review | 81 · Good | Agent plugin / skillFree + model costs | ★ 248 | 1mo ago | TypeScript | Codex · Claude Code |
| Open-Inspect Background Agents | 77 · Good | Self-hosted serviceFree + model costs | ★ 3.5k | today | TypeScript | OpenAI API · Claude API |
| Jevbridge Decision Sidecar | 62 · Some gaps | CLIFree + model costs | ★ 48 | 1mo ago | TypeScript | Codex · OpenAI API · Claude API |
How does FollowAgents rate this agent?
Why each dimension lost points
Workflow-level least-privilege is visible: approve-contributor and pr-redirect both set permissions:{} and grant per-job minimal scopes; pr-redirect explicitly avoids checking out PR heads, never executes fork code, and separates a privileged write token from the sandbox read-only token (least_privilege=2). However the framework claims a 'secure sandbox' without any visible file explaining isolation, permission boundaries, or confirmation flow; the README example grants write tools like openIssue with no user confirmation step (user_confirmation=1). Data-flow and sensitive-data handling are only implied via workflow comments, not framework-level docs (data_flow_transparency=1, sensitive_data_handling=2). Dependency security shows only version ranges in package.json, no lockfile audit or vulnerability policy (dependency_security=1). External effects and rollback: workflows clean up failed branches via deleteRef, but the framework documents no rollback/undo for agent write actions (external_effects=1, rollback=1). Source attribution is limited to LICENSE and package names, no NOTICE or contributor attribution (source_attribution=1).
README, package.json, and workflow scripts are mutually consistent (package names, CLI path, build commands align), giving reasonable self-consistency (self_consistency=2). Dependency availability is only engines and version ranges, no lockfile or install verification evidence (dependency_availability=1). Failure messages are explicit in workflows with ::error:: and exit codes, but framework-level failure messaging is not shown (failure_messages=2).
README lists multiple deploy targets (Node, Cloudflare, GitHub Actions, Daytona, etc.) and scenarios, covering audience and scenarios well (audience_and_scenarios=2). But capability boundaries (what the sandbox can and cannot do) and trigger precision (when the agent acts autonomously vs. needs confirmation) are not clearly defined (capability_boundaries=1, trigger_precision=1). Environment fit has engines and multi-platform deploy notes (environment_fit=2).
README is well-structured with a package table and feature list (information_architecture=2). Install notes are only pnpm scripts, no user-facing install steps (install_notes=1). Naming stability has no version or API stability commitment (naming_stability=1). Examples are rich but there is no FAQ (examples_and_faq=2). No known-limitations section (known_limitations=0). LICENSE is full Apache-2.0 text consistent with package.json (license=3). No CHANGELOG or versioning policy (versioning_changelog=0). Maintenance responsibility is unclear given unverified publisher and no maintainer statement, only inferable from workflows (maintenance_responsibility=1).
Example code is directly understandable and yields a usable agent definition (output_usability=2). As a 'harness framework' it offers differentiated value over a bare SDK (marginal_value=2). But cost (model calls, sandbox, multi-platform deploy) versus benefit is not discussed (cost_benefit=1).
README links heavily to an external docs site, so its claims cannot be verified within the repository (claim_traceability=1). Cross-source corroboration is limited to partial agreement between workflows and package.json (cross_source_corroboration=1). Fact/inference separation is weak, with 'secure sandbox' and 'autonomous' as asserted claims (fact_inference_separation=1).
- README claims a 'secure sandbox' but the repository contains no isolation, permission-boundary, or confirmation-flow documentation; review the sandbox implementation before deploying.
- The example agent grants write tools like openIssue with no user confirmation, risking unintended external side effects.
- Publisher identity is unverified and maintenance responsibility/update path is unclear; assess long-term maintenance carefully.
- No CHANGELOG, versioning policy, or known-limitations section; API stability is unknown.
- Dependency security shows only version ranges, with no lockfile audit or vulnerability-mitigation evidence.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Patch Changes - Updated dependencies [2cb57be] - @flue/[email protected]View on GitHub ↗ -
Release notes excerpt
Patch Changes - Updated dependencies [2cb57be] - @flue/[email protected]View on GitHub ↗ -
Release notes excerpt
Patch Changes - Updated dependencies [2cb57be] - @flue/[email protected]View on GitHub ↗