IBM CUGA atinge #1 em benchmarks com uma API de 4 argumentos

IBM Research publicou cuga-apps em 23 de junho de 2026: 24 aplicações FastAPI em arquivo único, cada uma envolvendo um CugaAgent. Casos de uso variam de um recomendador de filmes até um consultor de arquitetura IBM Cloud. Cada arquivo foi projetado para ser lido e forkado. O framework subjacente — CUGA (Configurable Generalist Agent, `pip install cuga`) — manteve #1 no AppWorld (750 tarefas do mundo real em 457 APIs) de julho de 2025 até fevereiro de 2026, e liderou WebArena de fevereiro até setembro de 2025.

Um CugaAgent leva quatro argumentos: uma factory de modelo, uma lista de ferramentas, uma string special_instructions e um caminho cuga_folder. Chame `await agent.invoke(...)` e o harness manipula planejamento, loop de execução, dispatch de ferramenta, rastreamento de estado entre etapas, e um passe de reflexão que captura chamadas de ferramenta ruins e replaneja sem superficializar a falha. Em uma tarefa de 20 passos, a maioria das implementações de agent perde o rastro dos resultados intermediários e os re-deriva incorretamente no próximo turno. CUGA mantém estado através de um gerenciador de variáveis na camada de orquestração.

A vinculação de ferramentas é uniforme em todas as fontes. Specs OpenAPI, servidores MCP e funções LangChain decoradas se anexam da mesma forma. Cada cuga-app se divide: capacidades genéricas (busca na web, operações de arquivo) carregam de servidores MCP compartilhados via `load_tools(["web"])`; lógica específica do domínio vive como Python inline no mesmo arquivo. O app consultor IBM Cloud define `search_ibm_catalog` como uma função decorada com `@tool` que atinge a IBM Cloud Global Catalog API, depois mistura ferramentas da web de um servidor MCP—duas linhas para conectar ambas.

CUGA expõe três modos de raciocínio—Fast, Balanced, Accurate—selecionados de config, não de código. A mesma definição de agent funciona em todos os três. A maioria dos harnesses integra o tradeoff custo/performance na implementação do agent; mudar requer reescrita. Aqui é uma chave de config. Sandboxes de código seguem o mesmo padrão: local, Docker/Podman, ou E2B cloud, trocados sem tocar na lógica do agent.

A galeria cuga-apps hospedada roda em gpt-oss-120b servido via Groq, não uma API frontier. Modelos abertos custam 80–90% menos que alternativas fechadas pela estimativa da IBM. A inferência baseada em LPU do Groq mantém latência por-passo baixa o suficiente para que tarefas de 20-passos não se compusessem em tempos de parede inutilizáveis. Llama-4-Maverick-17B-128E-Instruct-fp8 é o segundo modelo testado no ambiente hospedado.

Governança é configurada, não codificada. Arquivos de política são documentos Markdown em `.cuga/` sob a pasta do projeto. CUGA os injeta nas fases distintas da camada de orquestração—planejamento de API, execução de código, reflexão, atalho de ferramenta, decomposição de tarefa—cada uma superficializada como chave explícita em settings.toml. Cinco tipos de política estão disponíveis: Intent Guard, Playbook, Tool Approval, Tool Guide, Output Formatter. Habilite portas human-in-the-loop via `api_planner_hitl = true` em settings.toml. A mesma definição de agent que roda em dev roda em produção governada—sem reescrita, sem branch.

O caminho multi-agent usa o protocolo A2A. Um Supervisor SDK permite que um único coordenador dispatch trabalho para múltiplos CugaAgents. Workflows do Supervisor são definidos em YAML. Agent Skills—workflows de domínio empacotados como arquivos SKILL.md com frontmatter—são descobertos e carregados sob demanda via chamada de ferramenta `load_skill`, mantendo o prompt do agent base magro. Integração Langflow adiciona uma camada UI drag-and-drop para wiring visual de agents.

Fork um dos 24 apps, troque a lista de ferramentas e o prompt do sistema pelo seu domínio, e você tem um agent em caminho de produção com reflexão, hooks de governança, e portabilidade de provedor já conectados.