Flue es un framework TypeScript de código abierto que introduce el concepto de “agent harness”: una capa de control programable que separa la lógica del agente del modelo subyacente. A diferencia de los SDKs tradicionales, Flue te da control granular sobre permisos, sandbox de ejecución y flujo de trabajo, con soporte nativo para modelos como Claude Sonnet 4.6.
En 30 segundos
- Flue es un framework TypeScript para construir agentes autónomos usando un “agent harness” en vez del típico SDK wrapper sobre LLMs.
- La arquitectura separa Modelo + Harness + Sandbox, igual que la arquitectura interna de Claude Code o Codex.
- Soporta skills reutilizables con output estructurado, session management y control de permisos a nivel granular.
- Se despliega como servidor HTTP en Node.js, Cloudflare Workers o entornos CI/CD sin infraestructura especial.
- Disponible en npm como
@flue/sdk, con sandbox virtual integrado y soporte para sandboxes remotos.
¿Qué es Flue? El Agent Harness Framework para la próxima generación
Flue es un framework TypeScript open source que te permite construir agentes autónomos usando una arquitectura de “agent harness”: en vez de envolver llamadas a la API del LLM, estructurás toda la lógica de control, permisos y ejecución alrededor del modelo. Según el sitio oficial, el tagline es explícito: “Not another SDK”. El punto de partida es que los agentes más poderosos que existen hoy, Claude Code y Codex, no están construidos como chatbots con herramientas pegadas. Están construidos como sistemas con planificación, manejo de contexto, escritura de archivos, generación de subagentes y resolución de problemas. ¿Por qué no todos los agentes son así? Esa es la pregunta que Flue intenta responder.
El framework Flue TypeScript para agentes no asume una arquitectura específica. Podés representar desde un chatbot simple hasta una plataforma entera de generación de código, sin cambiar de paradigma.
Agent Harness vs SDK: por qué la arquitectura importa
Ponele que construís un agente con un SDK tradicional. Básicamente tomás el cliente de la API, le agregás algunas funciones como “herramientas”, y dejás que el modelo decida cuándo llamarlas. Eso funciona para demos. Para producción, te topás con los problemas reales: ¿quién controla qué herramientas tiene el agente en cada momento? ¿Cómo sabés qué pasó cuando algo se rompe? ¿Dónde ejecuta el código que genera?
Un SDK te da acceso al modelo. Un harness te da control sobre el agente.
La diferencia no es semántica. El harness de Flue maneja tres cosas que los SDKs ignoran: aislamiento de ejecución mediante sandbox, control fino de permisos por token/entorno, y observabilidad del estado de la sesión en cada paso. Si alguna vez intentaste debuggear un agente LangChain que empezó a tomar decisiones raras en el paso 7 de 12, sabés exactamente de qué hablo.
El artículo de Inngest “Your agent needs a harness, not a framework” articula bien este argumento: los frameworks de alto nivel ocultan el control que necesitás en producción. Flue apunta exactamente a ese gap.
Arquitectura y componentes principales de Flue
La fórmula central es: Agent = Model + Harness. Cada parte tiene un rol claro. Para más detalles técnicos, mirá trabajar con ChatGPT.
El modelo
Cualquier LLM que soportes vía su API. Los ejemplos del sitio oficial usan anthropic/claude-sonnet-4-6, pero el harness es agnóstico al modelo. El modelo toma decisiones; el harness las ejecuta (o las bloquea).
El harness
La capa de control programable. Acá definís:
- Skills: workflows reutilizables con output estructurado y validado. Una skill no es una función suelta, es un contrato: argumentos tipados, resultado verificado antes de que el agente lo use.
- Session management: el agente mantiene estado de trabajo entre pasos, como haría Claude Code o Codex cuando trabaja en una tarea larga. No es stateless por default.
- Control de decisiones críticas: podés interceptar momentos específicos del flujo para requerir aprobación humana antes de que el agente ejecute algo irreversible (un commit, un deploy, un envío).
- Gestión de secretos: tokens y API keys con control granular por skill o por contexto de ejecución, no expuestos globalmente.
El sandbox
Donde el agente ejecuta código. Flue trae un sandbox virtual integrado, zero-config, para desarrollo y casos de uso donde no necesitás aislamiento fuerte. Para producción podés conectar tu propio sandbox remoto (un contenedor, una VM, lo que uses). La separación entre lógica del agente y entorno de ejecución es intencional: un agente Flue no corre código en tu máquina por default.
De chatbots hasta plataformas: casos de uso reales
El ejemplo que muestra la documentación oficial es un agente de triaje de GitHub. El endpoint POST /agents/triage/:id recibe el ID de un issue, llama a una skill que analiza el issue y ejecuta tests, valida el output con schema estructurado (usando algo como Valibot: v.object({ fixApplied: v.boolean() })), y solo si fixApplied es true ejecuta el commit. Si no, genera un comentario en GitHub resumiendo el triaje y para ahí.
¿Alguien verificó esto en un proyecto real con miles de issues? Todavía no hay casos de uso públicos reportados en producción. Pero la arquitectura tiene sentido para ese escenario.
Otros casos que encajan bien:
- Agente de code generation con paso de aprobación manual antes de hacer push
- Pipeline de CI/CD con agente que diagnostica failures y propone fixes en un PR
- Agente de documentación que lee código fuente y genera o actualiza docs con validación estructurada del output
- Orquestador de subagentes para tareas paralelas (el harness puede instanciar múltiples agentes con roles distintos)
Lo que distingue a Flue es que el mismo paradigma cubre todos estos casos. No hay un “modo chatbot” y un “modo agente complejo”. El harness escala con la complejidad del problema.
Deploy flexible: de CLI a servidor HTTP
Flue compila tu agente a un servidor HTTP deployable. Corrés el endpoint como cualquier API REST: POST /agents/triage/:id recibe el payload, el harness lo procesa, devuelve resultado. Sin infraestructura especial. Lo explicamos a fondo en cómo funcionan los modelos de lenguaje.
Los entornos soportados según la documentación incluyen Node.js estándar, Cloudflare Workers y entornos CI/CD como GitHub Actions o GitLab CI. Si ya tenés infraestructura de hosting web, el agente se integra como un servicio más (si buscás dónde hostear esto en Argentina, donweb.com tiene servidores con Node.js y acceso SSH completo).
La distribución en npm es @flue/sdk. El proyecto está en GitHub bajo withastro/flue, que sugiere algún tipo de relación con el ecosistema Astro (o al menos uso del mismo namespace de organización en GitHub).
Comparativa: Flue vs Mastra, OpenAI Agents SDK y VoltAgent
Todos en TypeScript. Todos para construir agentes. Pero los enfoques son distintos.
| Framework | Enfoque principal | Control de permisos | Sandbox integrado | Ideal para |
|---|---|---|---|---|
| Flue | Agent harness (control fino) | Granular por token/skill | Sí, virtual + remoto | Agentes autónomos en producción |
| Mastra | Workflows y automatización | A nivel de workflow | No nativo | Pipelines de datos y LLM |
| OpenAI Agents SDK | API-first, handoffs entre agentes | Básico por herramienta | No nativo | Ecosistema OpenAI |
| VoltAgent | Construcción rápida de agentes | Limitado | No nativo | Prototipos y MVPs |
La diferencia real está en el nivel de control que querés. Mastra es excelente si tu problema es orquestar workflows con LLMs en el medio. OpenAI Agents SDK es lo más simple si ya vivís en el ecosistema de OpenAI. Flue apunta a algo distinto: construir agentes que puedan tomar decisiones autónomas complejas con control auditado en cada paso, más cerca de cómo funciona Claude Code internamente que de cómo funciona un chatbot con tools.
Eso sí: Flue es nuevo. Mastra y OpenAI Agents SDK tienen comunidad, documentación extensa y casos de uso en producción documentados. Flue todavía está construyendo eso.
Primeros pasos: cómo construir tu primer agente con Flue
Instalación básica:
npm install @flue/sdk- Inicializá el agente con el modelo:
{ model: 'anthropic/claude-sonnet-4-6' } - Definí skills con argumentos tipados y schema de output usando Valibot u otro validador compatible
- Usá el objeto
sessionpara mantener estado y ejecutar pasos del workflow - Exportá el agente y Flue lo convierte en un endpoint HTTP listo para deploy
El flujo mínimo de un agente de triaje se ve así: recibís el payload con el número de issue, llamás la skill de análisis con session.call({ args: { issueNumber: payload.issueNumber } }), validás el resultado contra el schema, y en base a triage.fixApplied decidís el siguiente paso: commit o comentario en GitHub. Todo controlado por el harness, con acceso al GITHUB_TOKEN solo dentro del contexto donde fue declarado. Complementá con alternativas con Google y Gemini.
La configuración del agente va en un archivo AGENTS.md (un guiño claro a la convención que usa Claude Code con su CLAUDE.md). No es coincidencia: Flue está explícitamente modelado sobre cómo funcionan los coding agents de nivel profesional.
Errores comunes al arrancar con Flue
Tratar las skills como funciones sueltas. Una skill en Flue no es solo una función que el modelo puede llamar. Tiene un schema de input, un schema de output validado, y el harness verifica ese output antes de que el agente lo use para tomar decisiones. Si la validación falla, el agente no avanza. Definir las skills sin schemas es perder la mitad del valor del framework.
Ignorar el sandbox en desarrollo. El sandbox virtual integrado existe por algo. Corrés tu agente directamente en el sistema de archivos local durante el desarrollo, te parece que funciona bien, y cuando pasás a producción con sandbox aislado el comportamiento cambia porque asumías paths o variables de entorno del sistema host. Usá el sandbox desde el día uno.
Poner todos los secretos en el contexto global del agente. El control de permisos granular de Flue te permite declarar qué tokens están disponibles en qué contexto de ejecución. Si ponés el GITHUB_TOKEN disponible en toda la sesión, cualquier skill puede usarlo. Declaralo solo para las skills que lo necesitan. El modelo de permisos de Flue pierde sentido si lo ignorás.
Preguntas Frecuentes
¿Qué es Flue framework para agentes TypeScript?
Flue es un framework TypeScript open source que introduce el concepto de “agent harness”: una capa de control programable entre el LLM y el entorno de ejecución. A diferencia de los SDKs que envuelven llamadas a la API del modelo, Flue te da control sobre permisos, sandbox de ejecución, session management y validación de outputs. Está disponible como @flue/sdk en npm. Ya lo cubrimos antes en agentes IA potenciados con Claude.
¿Cómo construir agentes autónomos con Flue en TypeScript?
Instalás @flue/sdk, inicializás el agente con tu modelo preferido (por ejemplo anthropic/claude-sonnet-4-6), definís skills con schemas de input/output estructurados, y usás el objeto session para manejar el estado de la tarea. El agente se exporta como endpoint HTTP. Para casos donde necesitás aprobación humana en decisiones críticas, el harness permite interceptar esos momentos antes de ejecutar acciones irreversibles.
¿Cuáles son las diferencias entre Flue y otros frameworks de agentes?
Flue se diferencia por su enfoque en control de producción: sandbox de ejecución aislado, permisos granulares por skill, y session management con estado persistente entre pasos. Mastra prioriza workflows y pipelines. OpenAI Agents SDK está optimizado para el ecosistema OpenAI con handoffs entre agentes. VoltAgent apunta a construcción rápida de prototipos. Flue apunta a agentes autónomos complejos donde el control auditado de cada paso importa.
¿Cómo desplegar agentes Flue en producción?
Flue compila el agente a un servidor HTTP estándar. Podés deployarlo en Node.js, Cloudflare Workers, o entornos CI/CD como GitHub Actions y GitLab CI. No requiere infraestructura específica del framework. Para entornos de ejecución de código, podés usar el sandbox virtual integrado (zero-config) o conectar tu propio sandbox remoto para mayor aislamiento.
¿Qué ventajas tiene un agent harness sobre los SDKs tradicionales?
Un SDK te da acceso al modelo. Un harness te da control sobre lo que el agente puede hacer con ese acceso. Las ventajas concretas son: aislamiento de ejecución mediante sandbox, validación de outputs antes de que el agente los use para tomar decisiones, control de qué secretos están disponibles en qué contexto, y capacidad de requerir aprobación humana en pasos críticos. Para agentes que van más allá de responder preguntas, esa diferencia importa en producción.
Conclusión
Flue llega en un momento donde la mayoría de los frameworks de agentes compiten en features de alto nivel (RAG integrado, conectores, interfaces visuales) mientras el problema real de producción sigue sin resolverse: cómo tener control auditado sobre lo que hace un agente autónomo. La apuesta de Flue es que la arquitectura que hace poderosos a Claude Code y Codex (planning + context + controlled execution) debería ser el default para cualquier agente, no un privilegio de los labs de IA con cientos de ingenieros.
Si trabajás con TypeScript y estás construyendo algo que va más allá de un chatbot con herramientas, vale la pena explorar Flue. El framework es nuevo (pocos casos de uso en producción documentados públicamente), pero el modelo conceptual es sólido. La comunidad va a determinar si se convierte en referencia o en otro experimento interesante que no llegó a masa crítica. Por ahora, el código está en GitHub y el SDK en npm. Podés probarlo hoy.