Apache Burr: construindo agentes e aplicações de IA confiáveis

• Apache Burr é um framework para criar, em Python, aplicações de IA orientadas por decisão, desde chatbots simples até sistemas complexos com múltiplos agentes
• As aplicações são definidas como um conjunto de ações e transições e escritas com funções Python e decoradores, sem DSL ou YAML
• A Burr UI oferece monitoramento, depuração e rastreamento por etapa de execução, com visualização em tempo real das mudanças de estado
• É possível salvar o estado em disco, banco de dados ou backends customizados e retomar a partir de pontos de interrupção, além de oferecer suporte a espera por entrada humana e execução paralela
• Integra-se a ferramentas já existentes como OpenAI, Anthropic, LangChain, FastAPI e PostgreSQL, sem exigir lock-in ou wrappers

---

Construindo agentes e aplicações de IA confiáveis

• Apache Burr é um projeto em incubação da Apache que facilita o desenvolvimento de aplicações que tomam decisões
• Seu escopo vai de chatbots simples até sistemas complexos com múltiplos agentes
• A implementação é feita em Python puro e adota a proposta de “no magic”
• Como métricas públicas, exibe 1.641 estrelas no GitHub, 379k+ downloads no PyPI e 457+ membros no Discord

API Python simples e poderosa

• O Burr oferece uma interface combinável para montar desde chatbots até sistemas com múltiplos agentes
• O código de exemplo usa burr.core com action, State e ApplicationBuilder para definir a ação chat
• @action(reads=["messages"], writes=["messages"]) especifica quais estados são lidos e escritos
• ApplicationBuilder() configura ações, transições, estado inicial e rastreador local antes de construir a aplicação
• O exemplo de execução usa app.run(halt_after=["chat"], inputs={"llm_client": client}), passando o cliente de LLM como entrada

Elementos necessários para criar aplicações de IA

• Simple Python API define a aplicação como um conjunto de ações e transições, usando apenas funções Python e decoradores, sem DSL ou YAML
• Built-in Observability permite monitorar, depurar e rastrear em tempo real todas as etapas da aplicação pela Burr UI
• Persistence & State Management salva automaticamente o estado em disco, banco de dados ou backends customizados e permite retomar a partir de pontos de interrupção
• Human-in-the-Loop permite pausar a execução em qualquer etapa e aguardar entrada humana, sendo adequado para fluxos de aprovação e agentes interativos
• Branching & Parallelism oferece suporte à execução paralela de ações, fan out / fan in, construção de DAGs complexos e composição de subaplicações
• Testing & Replay aumenta a confiança em sistemas de IA com reprodução de execuções passadas, testes unitários de ações individuais e validação de transições de estado

Integração com a stack existente

• O Burr se integra às ferramentas e frameworks que você já usa, sem exigir lock-in nem wrappers
• Entre as integrações com LLMs estão OpenAI, Anthropic e Instructor
• Entre as integrações com frameworks estão LangChain, Hamilton e Haystack
• Entre as integrações de UI e serving estão Streamlit e FastAPI
• Entre as integrações de validação e armazenamento estão Pydantic e PostgreSQL
• A lista completa de integrações pode ser consultada na documentação

Experiência de uso de desenvolvedores e equipes

• O depoimento da Peanut Robotics afirma que, após avaliar vários frameworks de LLM, o gerenciamento de estado do Burr foi uma resposta poderosa para implantar robôs baseados em tomada de decisão por IA
• O depoimento da Watto.ai destaca que é fácil criar aplicações de IA modulares e que a UI facilita a depuração
• O depoimento da Paxton AI enfatiza que o Burr não usa conceitos estranhos e obscuros só por se tratar de IA
• O depoimento da Provectus afirma que o gerenciamento de estado do Burr é útil para criar snapshots de estado, depurar, reproduzir execuções e montar casos de avaliação
• O depoimento da CognitiveGraphs avalia que, em comparação com várias plataformas agentic de LLM como LangChain, CrewAi, AutoGen e Agency Swarm, o Burr oferece um framework mais robusto para projetar comportamentos complexos
• O depoimento da TaskHuman relata que, após migrar do LangChain para o Burr, conseguiram começar em poucas horas e converteram toda a base de código para o Burr

Comunidade e status do projeto

• A comunidade é organizada como um espaço para pedir ajuda, compartilhar projetos e contribuir para o futuro do Burr
• Os canais de participação são Discord, GitHub e Twitter / X
• Os recursos do projeto incluem documentação, exemplos, YouTube, roadmap e changelog
• O Apache Burr é um projeto em incubação na Apache Software Foundation, com apoio do Apache Incubator
• O status de incubação não reflete necessariamente o nível de completude ou estabilidade do código, mas indica que o projeto ainda não recebeu aprovação completa da ASF

[GN⁺]

Comentários do Hacker News

• Ainda estou reservando julgamento sobre frameworks de agentes, e a utilidade varia conforme a natureza do agente. Por exemplo, é diferente entre precisar devolver uma resposta boa o suficiente em até 3 segundos e precisar resolver um problema ao longo de 3 horas
  No fim, um agente se resume a composição de contexto, chamada ao LLM, execução das chamadas de ferramentas solicitadas, parsing da saída final do modelo e retorno ao frontend. Existem extensões como memória ou chamadas assíncronas de ferramentas, mas, da perspectiva tradicional de engenharia de software, isso não é tão complexo assim
  Todo mundo quer criar seu próprio framework de agentes, mas, se você precisa construir um agente específico, acho que código 1:1 ajustado para esse agente é muito mais simples e melhor de manter. As abstrações do framework muitas vezes escondem e atrapalham a lógica central, e no fim você precisa se adequar às abstrações escolhidas pelo framework, o que às vezes se desalinha do objetivo real

  • Acho que o ponto central de sistemas agentivos não é usar agentes, mas usá-los só quando realmente forem necessários. Um sistema que funciona precisa de pipelines/receitas para expressar fluxos em múltiplas etapas, um sistema operacional para executar de forma estável etapas de modelo e de intervenção humana em pools de trabalhadores com múltiplos agentes, gerenciamento, distribuição, segurança e permissões de skills robustas que façam o máximo possível em código, e gestão de contexto para colocar o contexto certo na sessão certa
    Além disso, é preciso gerenciamento de projeto para lidar com tickets, dependências, progresso e reinício de tickets travados, armazenamento do histórico de conversas e recursos de memória, devaneio e aprendizado acumulado, observabilidade para ver custos e uso, avaliação e ajuste automático de prompts, troca de provedores de modelo e fixação de versões de modelo, além de um sandbox para executar sessões reais
    Não é necessário obter tudo de um único fornecedor, mas, na maioria dos casos, acho importante não ficar preso a um único provedor de modelo e possuir diretamente o seu próprio contexto e aprendizado acumulado
  • A parte mais grave da maioria dos frameworks de agentes é esconder a lógica central. Deve ficar claro o que está sendo enviado ao modelo de linguagem de fato e o que está voltando
    Tudo em uma aplicação agentiva acaba sendo realizado como sequências de tokens ou chamadas ao provedor, então isso precisa estar evidente em quase todas as camadas do app
  • Tive pensamento parecido com dezenas de frameworks de frontend. É como assumir uma enorme abstração e complexidade por recompensas que parecem vir no futuro, mas nunca chegam
    Ainda assim, as pessoas precisam de coisas para fazer ou brinquedos divertidos, e o “próximo cara” em geral não é considerado tão importante, então parece aceitável empurrar para ele o resultado de um tempo de brincadeira remunerado
  • Concordo em certa medida com a abordagem de criar código 1:1 ajustado para um agente específico. Mas, quando você cria uma técnica ou abordagem nova em um agente novo, do ponto de vista de manutenção fica a questão de como atualizar agentes antigos e se você quer atualizá-los
    Por exemplo, parece que o Apache Burr suporta ou vai suportar um sistema de vector RAG plugável, mas o que eu preciso é de uma forma de adicionar documentos ao contexto e mantê-los como parte do prompt de sistema atualizado, com ajustes bem específicos nesse processo. É um uso customizado de um conceito existente, RAG, então não se encaixa bem em um framework específico
    Para o meu caso de uso, a implementação sob medida faz sentido, mas a decisão de engenharia sobre como atualizar agentes antigos continua existindo
  • A vantagem dos frameworks não está em facilitar a escrita do agente em si, mas em ferramentas e observabilidade e coisas do tipo. O LangChain tem muitos pontos criticáveis, mas mostrou isso de forma muito clara no começo
    Criar um chatbot do zero pode ser fácil, ou até mais fácil, mas a história muda quando você precisa adicionar observabilidade ou rastreamento. Se for possível acrescentar uma única variável de ambiente e ver praticamente todo o tracing na UI quase sem trabalho extra, uma solução feita à mão dificilmente consegue competir

• Fico curioso se esta página foi feita com https://vorpus.github.io/performativeUI/
  Ela pisa em praticamente todos os clichês típicos de uma landing page gerada por IA. Ou então dá até a impressão de ser uma sátira proposital

• Tenho usado bastante esse framework em projetos pessoais e de trabalho. Foi bom obter workflows com estado confiáveis para modelos de IA e observabilidade gratuita
  Juntei uma ferramenta para montar a máquina de estados do Burr via MCP e dar trilhos para o agente seguir, enquanto a ferramenta MCP fica limitada à navegação da máquina de estados, por mais complexa que ela fique: https://github.com/msradam/theodosia
  Agora estou trabalhando em converter skills em máquinas de estado. Muitas skills populares já são escritas como etapas que modelos de IA podem seguir, então parece que usar os recursos explícitos do Burr pode torná-las mais confiáveis

• Fico curioso sobre como isso se compara a https://strandsagents.com/. Tenho interesse nas ferramentas dessa área e ainda não estou preso a nenhuma em particular, mas Bedrock + Serverless on Agent Core parece um “caminho guiado fácil”. Só não gosto da dependência de plataforma

  • Também tenho curiosidade sobre a experiência de outras pessoas. Estou usando essa stack e continuo me perguntando se o Strands oferece algum molho secreto especial junto com o Agent Core
    Até agora não parece, e às vezes os dois até parecem entrar em conflito entre si

• Aqui dá para ver o padrão builder e decoradores. Python também tem decoradores, mas acho que o uso mais apropriado é como um “filtro” aplicado a funções ou métodos. Tipo: esta função deve ser colocada em cache, a saída desta função deve sempre ser serializada, esta função deve ser preparada como ferramenta para um executor no estilo agente
  Não acho que devam ser usados para registro ou controle de fluxo. Você pode discordar, mas alguém precisava dizer isso. O FastAPI acabou puxando demais o uso moderno de decoradores para a direção errada
  O padrão builder é mais uma convenção surgida porque Rust não tem argumentos nomeados de verdade, enquanto funções em Python já expõem contratos nomeados. Quase nunca há motivo para passar parâmetros de configuração em sequência por chamadas de método encadeadas
  Se você precisa adicionar um estado que ainda não existe no construtor ou na factory, isso não é padrão builder, é registro. O único lugar em que o padrão builder é aceitável é em algo como um construtor de consultas. Você vai montando conceitos de forma repetitiva, e os slots de metadados que são os nomes dos métodos e os argumentos nomeados realmente se tornam úteis. Usar métodos que recebem um único parâmetro em vez de argumentos nomeados me parece errado

  • Aqui, o decorador especificamente anexa metadados à função para transformá-la em um componente reutilizável, e o builder monta o workflow. No Hamilton, como a composição é totalmente declarativa, tudo é tratado com decoradores, mas a reutilização é na prática uma questão separada
  • O padrão builder não é usado só em Rust, mas concordo que em Python ele fica feio

• Parece uma versão bem ingênua do que seria um agente de IA confiável
  Confiabilidade significa “consegue concluir a tarefa que recebeu”, e não tem exatamente relação com uma máquina de estados

• Nunca tinha ouvido falar de Burr; fico curioso sobre por que ele entrou em incubação na Apache

  • Não há motivo para que não entrasse. A ASF tem uma longa história de incubar novos projetos livres e de código aberto
    Alguns se formam e viram nomes conhecidos por todos, outros fracassam e vão para o attic. A ASF oferece suporte organizacional e, em geral, ajuda a formar boas comunidades
  • Porque fui eu que submeti. Foi um processo lento, já que eu estava aprendendo o procedimento da Apache e tocando outras coisas ao mesmo tempo, mas agora já ganhou algum impulso e estamos começando a fazer releases mais regulares

• A página parece lixo descartável feito com Claude Code, e nem tenta funcionar sem JavaScript. Pelo menos tem consistência de marca

• Não encontrei a origem explícita do nome, mas, para quem tiver curiosidade, aqui vai um exemplo com Hamilton: https://github.com/apache/burr/tree/main/examples/multi-agen...

  • Burr recebeu esse nome por causa de Aaron Burr, um dos pais fundadores dos EUA, 3º vice-presidente e também assassino e rival de Alexander Hamilton
    A conexão com Hamilton está no fato de que foi a segunda biblioteca open source lançada pela DAGWorks, depois da biblioteca Hamilton. É um nome imaginando como teria sido se Burr e Hamilton tivessem entrado em harmonia e, superando suas diferenças, construído uma federação melhor
    Originalmente, Burr foi criado como um mecanismo para lidar com o estado entre execuções de DAGs do Hamilton. DAGs não têm ciclos. Depois perceberam que o escopo era mais amplo e o abriram de forma mais geral
    https://pypi.org/project/burr/

• Queria saber se há alguma ferramenta ou plataforma de orquestração de agentes de programação que vocês recomendem. Quero executar, gerenciar e monitorar agentes do codex ou do claude em várias máquinas
  Se possível, algo self-hosted ou open source seria melhor. Sei que o claude code já tem bastante coisa assim internamente, mas é só para Claude

  • Pelos documentos, o Burr tem um cookbook de agentes que pode servir para começar isso, e também consegue lidar com workflows em várias máquinas. Fico pensando se não é justamente isso que você está procurando
    Não tenho certeza de como ele se integra com skills e afins, mas, pelo que parece, deve funcionar
    https://burr.apache.org/docs/examples/agents/