Apache Burr: creación de agentes y aplicaciones de IA confiables

• Apache Burr es un framework para crear en Python aplicaciones de IA basadas en decisiones, desde chatbots simples hasta sistemas complejos de múltiples agentes
• Las aplicaciones se definen como un conjunto de acciones y transiciones, y se escriben con funciones y decoradores de Python, sin DSL ni YAML
• Burr UI ofrece monitoreo, depuración y trazabilidad por etapa de ejecución, y permite ver los cambios de estado en tiempo real
• Puede guardar el estado en disco, bases de datos o backends personalizados, reanudar desde puntos de interrupción y también admite espera de entrada humana y ejecución en paralelo
• Se integra con herramientas existentes como OpenAI, Anthropic, LangChain, FastAPI y PostgreSQL, y puede usarse sin lock-in ni wrappers

---

Creación de agentes y aplicaciones de IA confiables

• Apache Burr es un proyecto en incubación de Apache que facilita el desarrollo de aplicaciones que toman decisiones
• Su alcance va desde chatbots simples hasta complejos sistemas de múltiples agentes
• La implementación se hace en Python puro y promueve la idea de “no magic”
• Como métricas públicas, muestra 1,641 estrellas en GitHub, 379k+ descargas en PyPI y 457+ miembros en Discord

Una API de Python simple y potente

• Burr ofrece una interfaz componible para construir desde chatbots hasta sistemas de múltiples agentes
• El código de ejemplo define la acción chat usando action, State y ApplicationBuilder de burr.core
• @action(reads=["messages"], writes=["messages"]) especifica el estado que se lee y el que se escribe
• ApplicationBuilder() configura acciones, transiciones, estado inicial y un rastreador local, y luego construye la aplicación
• El ejemplo de ejecución pasa el cliente LLM como entrada con la forma app.run(halt_after=["chat"], inputs={"llm_client": client})

Elementos necesarios para crear aplicaciones de IA

• Simple Python API define la aplicación como un conjunto de acciones y transiciones, usando solo funciones y decoradores de Python, sin DSL ni YAML
• Built-in Observability permite monitorear, depurar y rastrear en tiempo real cada etapa de la aplicación con Burr UI
• Persistence & State Management guarda automáticamente el estado en disco, bases de datos o backends personalizados y permite reanudar desde puntos de interrupción
• Human-in-the-Loop permite detener la ejecución en cualquier etapa y esperar entrada humana, lo que la hace adecuada para flujos de aprobación y agentes interactivos
• Branching & Parallelism admite ejecución paralela de acciones, fan out / fan in, construcción de DAG complejos y composición de subaplicaciones
• Testing & Replay aumenta la confianza en los sistemas de IA mediante reproducción de ejecuciones pasadas, pruebas unitarias de acciones individuales y validación de transiciones de estado

Integración con la pila existente

• Burr se integra con las herramientas y frameworks que ya se usan, y no requiere lock-in ni wrappers
• Entre las integraciones con LLM se muestran OpenAI, Anthropic e Instructor
• Entre las integraciones con frameworks se muestran LangChain, Hamilton y Haystack
• Entre las integraciones de UI y serving se muestran Streamlit y FastAPI
• Entre las integraciones de validación y almacenamiento se muestran Pydantic y PostgreSQL
• La lista completa de integraciones puede consultarse en la documentación

Experiencia de uso de desarrolladores y equipos

• La reseña de Peanut Robotics señala que, tras evaluar varios frameworks de LLM, la gestión de estado de Burr fue una respuesta sólida para desplegar robots basados en toma de decisiones con IA
• La reseña de Watto.ai destaca que facilita la creación de aplicaciones de IA modulares y que la UI simplifica la depuración
• La reseña de Paxton AI enfatiza que no usa conceptos extraños ni rebuscados solo por tratarse de IA
• La reseña de Provectus considera útil la gestión de estado de Burr para crear snapshots de estado, depurar, reproducir y construir casos de evaluación
• La reseña de CognitiveGraphs evalúa que, frente a varias plataformas agentic de LLM como LangChain, CrewAi, AutoGen y Agency Swarm, Burr ofrece un framework más sólido para diseñar comportamientos complejos
• La reseña de TaskHuman comenta que, tras pasar de LangChain a Burr, comenzaron en pocas horas y terminaron migrando toda su base de código a Burr

Comunidad y estado del proyecto

• La comunidad está organizada como un espacio para pedir ayuda, compartir proyectos y contribuir al futuro de Burr
• Las vías de participación se ofrecen a través de Discord, GitHub y Twitter / X
• Los recursos del proyecto enlazan a documentación, ejemplos, YouTube, hoja de ruta y registro de cambios
• Apache Burr es un proyecto en incubación dentro de Apache Software Foundation, patrocinado por Apache Incubator
• El estado de incubación no refleja necesariamente el nivel de completitud o estabilidad del código, pero indica que aún no ha recibido la aprobación completa de ASF

[GN⁺]

Comentarios de Hacker News

• Todavía me reservo el juicio sobre los frameworks de agentes, y su utilidad cambia según la naturaleza del agente. Por ejemplo, no es lo mismo tener que devolver una respuesta suficientemente buena en 3 segundos que resolver un problema durante 3 horas
  Al final, un agente se reduce a construir contexto, llamar al LLM, ejecutar las llamadas a las herramientas solicitadas, parsear la salida final del modelo y devolverla al frontend. Hay extensiones como memoria o llamadas asíncronas a herramientas, pero desde una perspectiva tradicional de ingeniería de software no es algo tan complejo
  Todos quieren hacer su propio framework de agentes, pero si hay que construir un agente específico, creo que un código 1:1 ajustado a ese agente es mucho más fácil y mejor de mantener. La abstracción del framework muchas veces oculta y estorba la lógica central, y al final uno tiene que adaptarse a la abstracción que eligió el framework, lo que a veces se desvía del objetivo real

  • Creo que la clave de los sistemas de tipo agente no está en usar agentes, sino en usarlos solo cuando de verdad hacen falta. Un sistema que funcione necesita pipelines/recetas para expresar flujos de varias etapas, un sistema operativo que ejecute de forma estable modelos y etapas con intervención humana en un pool de trabajadores-agente, y gestión, despliegue, seguridad y permisos de skills robustas que resuelvan en código la mayor cantidad posible de trabajo, además de gestión de contexto para poner el contexto correcto en la sesión correcta
    Además de eso, hace falta gestión de proyectos para manejar tickets, dependencias, avance y reinicio de tickets atascados; almacenamiento del historial de conversaciones y funciones de memoria, soñar y aprendizaje acumulativo; observabilidad para ver costos y uso; evaluación y ajuste automático de prompts; cambio de proveedor de modelos y fijación de versiones de modelo; y un sandbox donde correr las sesiones reales
    No hace falta obtener todo de un solo proveedor, pero en la mayoría de los casos creo que no hay que quedar atrapado con un único proveedor de modelos, y que el contexto propio y el aprendizaje acumulativo deberían ser propiedad directa de uno
  • La parte más grave de la mayoría de los frameworks de agentes es que ocultan la lógica central. Debería verse con claridad qué se envía realmente al modelo de lenguaje y qué regresa
    Todo en una aplicación de tipo agente termina materializándose en secuencias de tokens o llamadas al proveedor, así que eso debería ser evidente en casi todas las capas de la app
  • Pensé algo parecido con las decenas de frameworks de frontend. Te cargan con una enorme abstracción y complejidad por una recompensa que parece venir en el futuro, pero nunca llega
    Aun así, la gente necesita cosas que hacer o juguetes divertidos, y parece que “la siguiente persona” por lo general no importa tanto, así que da igual heredarle el resultado de ese tiempo de juego pagado
  • Estoy de acuerdo hasta cierto punto con hacer código 1:1 ajustado a un agente específico. Pero desde el punto de vista del mantenimiento, sigue quedando la duda de cómo actualizar agentes viejos cuando en un agente nuevo creaste técnicas o enfoques nuevos, y si de verdad quieres actualizarlos
    Por ejemplo, parece que Apache Burr soporta o va a soportar un sistema vectorial RAG enchufable, pero lo que necesito es una forma de agregar documentos al contexto y mantenerlos como parte del prompt del sistema actualizado, con ajustes muy específicos dentro de ese proceso. Es una manera personalizada de usar el concepto existente de RAG, así que no encaja muy bien con un framework específico
    Para mi caso de uso, una implementación a medida sí tiene sentido, pero sigue quedando la decisión de ingeniería sobre cómo actualizar agentes antiguos
  • La ventaja de un framework no está realmente en facilitar la escritura del agente, sino en las herramientas y la observabilidad, entre otras cosas. LangChain tiene mucho que se le puede criticar, pero esto lo mostró con mucha claridad desde el principio
    Crear un chatbot desde cero puede ser fácil o incluso más fácil, pero cuando tienes que agregar observabilidad o tracing, la historia cambia. Si puedes agregar una sola variable de entorno y revisar todo el tracing en una UI casi sin trabajo extra, una solución hecha a mano lo tiene difícil para competir

• Me pregunto si esta página fue hecha con https://vorpus.github.io/performativeUI/
  Pisa prácticamente todos los clichés típicos posibles de una landing page generada por IA. O quizá es una sátira intencional

• Me gusta usar este framework tanto en proyectos personales como en proyectos de trabajo. Me gustó porque te da workflows con estado confiables para modelos de IA y observabilidad gratuita
  Armé una herramienta que monta la máquina de estados de Burr sobre MCP y les da a los agentes rieles a seguir, mientras que la herramienta MCP queda limitada a explorar la máquina de estados por más compleja que esta sea: https://github.com/msradam/theodosia
  Ahora estoy trabajando en convertir skills en máquinas de estado. Muchas skills populares ya están escritas en forma de pasos que los modelos de IA deben seguir, así que parece que se podrían volver más confiables aprovechando las capacidades explícitas de Burr

• Me pregunto cómo se compara con https://strandsagents.com/. Me interesan las herramientas de esta área y todavía no estoy atado a una en particular, pero Bedrock + Serverless on Agent Core se siente como un “camino guiado fácil”. Aunque no me gusta la dependencia de plataforma

  • Me interesa conocer otras experiencias. Estoy usando este stack y sigo con la duda de si Strands aporta alguna salsa secreta especial junto con Agent Core
    Hasta ahora no me lo ha parecido, y a veces incluso da la impresión de que ambos chocan entre sí

• Aquí se ve el patrón builder y decoradores. Python también tiene decoradores, pero me parece que su uso más apropiado es como “filtros” aplicados a funciones o métodos. En plan: esta función se cachea, la salida de esta función siempre se serializa, o esta función se prepara como herramienta de un motor de ejecución tipo agente
  No me parece que sean para registro o control de flujo. Quizá no estés de acuerdo, pero alguien tenía que decirlo. FastAPI ha empujado demasiado el uso moderno de decoradores en una dirección equivocada
  El patrón builder es más una convención nacida porque Rust no tiene argumentos con nombre como keyword, y las funciones de Python ya exponen un contrato con nombre. Casi nunca hay razón para pasar parámetros de configuración en orden mediante llamadas encadenadas a métodos
  Si necesitas agregar estado que todavía no existe en un constructor o factory, eso no es patrón builder sino registro. El único lugar donde toleraría el patrón builder es en algo como un constructor de consultas. Ahí vas acumulando el concepto de forma iterativa, y los espacios de metadatos que dan los nombres de métodos y los argumentos keyword sí resultan realmente útiles. Usar métodos que reciben un solo parámetro en lugar de argumentos keyword me parece incorrecto

  • Aquí, en concreto, los decoradores adjuntan metadatos a la función para convertirla en un componente reutilizable, y el builder construye el flujo de trabajo. En Hamilton todo se maneja con decoradores porque la composición es puramente declarativa, pero la reutilización en realidad es un tema aparte
  • El patrón builder no se usa solo en Rust, pero sí coincido en que en Python se ve feo

• Parece una versión bastante ingenua de lo que sería un agente de IA confiable
  La confiabilidad significa “¿puede terminar la tarea que se le encargó?”, y no tiene mucho que ver con una máquina de estados

• Es la primera vez que escucho de Burr; me da curiosidad por qué entró en incubación en Apache

  • No hay ninguna razón para que no. La ASF tiene una larga historia incubando nuevos proyectos libres y de código abierto
    Algunos se gradúan y se vuelven nombres que todo el mundo conoce; otros fracasan y terminan en el attic. La ASF ofrece apoyo organizacional y, por lo general, ayuda a cultivar buenas comunidades
  • Porque yo lo propuse. Fue un proceso lento porque estaba aprendiendo el procedimiento de Apache y llevando otras cosas al mismo tiempo, pero ahora ya tiene algo de impulso y estamos empezando a hacer lanzamientos más regulares

• La página parece basura desechable hecha con Claude Code, y ni siquiera intenta funcionar sin JavaScript. Al menos tiene consistencia de marca

• No encontré una referencia explícita del nombre, pero para quien tenga curiosidad hay un ejemplo de Hamilton: https://github.com/apache/burr/tree/main/examples/multi-agen...

  • Burr toma su nombre de Aaron Burr, uno de los padres fundadores de Estados Unidos, tercer vicepresidente del país, asesino y rival de Alexander Hamilton
    La conexión con Hamilton es que fue la segunda librería de código abierto que DAGWorks publicó después de la librería Hamilton. El nombre imagina qué habría pasado si Burr y Hamilton hubieran armonizado sus diferencias para construir una federación mejor
    Originalmente, Burr se creó como un mecanismo para manejar el estado entre ejecuciones de DAG de Hamilton, porque los DAG no tienen ciclos. Después nos dimos cuenta de que aplicaba a un ámbito más amplio y lo publicamos de manera más general
    https://pypi.org/project/burr/

• Me pregunto si hay alguna herramienta o plataforma de orquestación para agentes de código que valga la pena recomendar. Quiero ejecutar, administrar y monitorear agentes de codex o claude en varias máquinas
  Si es posible, preferiría algo self-hosted o de código abierto. Sé que Claude Code internamente ya tiene muchas funciones de ese tipo, pero está limitado a Claude

  • Viendo la documentación, parece que Burr tiene un cookbook de agentes con el que podrías empezar, y también puede manejar flujos de trabajo en varias máquinas. Me pregunto si justo eso es lo que estabas buscando
    No tengo claro cómo se integra con skills y cosas así, pero por lo que se ve parece que podría funcionar
    https://burr.apache.org/docs/examples/agents/