Como a maneira com que lidamos com orquestração de agentes é única.

Resumo

• Usei o IBM Bob em partes de um projeto, e na minha experiência ele ficou atrás do Claude Code em qualidade e em velocidade, e os subagentes foram difíceis de configurar e de acompanhar.
• Nas páginas de subagentes do Kiro e do Bob a ideia central é a mesma. O agente principal decide quando delegar, e cada subagente trabalha com contexto próprio e devolve um resultado.
• Minha tese é que, com a delegação resolvida, o que decide a qualidade da experiência é o que fica em código e o que fica na conversa, ou seja, quem calcula a colisão de arquivos, quem integra o que voltou e onde o acompanhamento mora. No Playmaker, esse lugar é um quadro.
• Na minha leitura, o mundo usa um combo de LangGraph, Deep Agents, OpenMemory e LangSmith. A Síntese montou o equivalente por função com Playmaker, Lore e Langfuse, e acrescentou o Blueprint (spec) e o Medha (um Notion melhorado).

O que aconteceu quando usei o IBM Bob

Em setembro, em um hackathon de 12 horas, usei o IBM Bob em partes do desenvolvimento da solução. O resultado não me agradou. O código saiu pior do que sai com o Claude Code, as tarefas simples demoraram mais do que eu esperava e, nas vezes em que o Bob foi rápido, a qualidade do que ele entregou caiu. Os subagentes, que eram o que eu mais queria testar, foram difíceis de configurar, e a quantidade de informação na tela tornou difícil entender o que estava acontecendo e como ele fazia as coisas.

Isso é experiência de uso em um projeto, sob pressa, e não um benchmark, e é assim que a trato aqui. Do Kiro eu só vi vídeos, então tudo o que digo dele vem da documentação. O que justifica um texto é que a documentação dos dois produtos descreve a mesma ideia que levou ao Playmaker, e vale olhar as duas lado a lado.

A mesma frase em duas documentações

Na página de subagentes do Kiro, o agente principal delega quando "identifies one that benefits from delegation", e os subagentes rodam em paralelo, cada um com a sua conversa isolada (Kiro ↗ (abre em outra aba)). Na do IBM Bob, é o Bob quem pode criar subagentes, com a ressalva de que ele faz isso com moderação e espera a sua aprovação antes de cada um (IBM Bob ↗ (abre em outra aba)). É o mesmo ponto de partida do Playmaker, em que o agente com quem você já conversa se oferece para gerenciar outros, e por isso a comparação vale a pena. Delegar de forma proativa é o começo dos três, e o que os separa vem depois do sim.

Os três lado a lado

A tabela resume o que encontrei. Onde está escrito "não encontrado", quero dizer que não achei no material que li (veja as referências no fim do artigo), o que não prova que o recurso não exista.

Nos dois produtos, o que a documentação descreve em detalhe é o isolamento da conversa. Do isolamento de arquivos por tarefa, de um passo em que o gerente rode os gates em uma cópia limpa antes de integrar e de uma memória que atravessa sessões, não achei descrição.

O quadro do Playmaker

Das diferenças da tabela, a que mais sinto no uso é a última linha. Quando rodo uma rodada no Playmaker, o gerente, que no meu caso é o Claude, diz em linguagem natural o que está acontecendo, quais são os próximos passos e qual agente está fazendo cada tarefa. Ao lado da conversa fica um quadro que organiza tudo por estado.

Nas imagens, o gerente avisa que três agentes entregaram e estão em revisão, que a tarefa t01 segue rodando e que o merge só acontece depois de ele ler a revisão e as checagens passarem. O quadro mostra o que roda e há quantos minutos, em qual CLI, o que foi entregue e espera revisão (com o botão de merge), e o que está na fila e por quê, como t02-contract esperando t01-schema ser mergeada. Em uma rodada mais adiantada aparece também o número da rodada de cada tarefa e a lista do que já está mergeado e ainda precisa ser testado por uma pessoa. Nessa rodada específica todos os workers eram da mesma CLI, o Antigravity, embora o Playmaker aceite misturar provedores.

Na minha opinião, é um incremento real para o desenvolvimento agêntico no Brasil, onde ainda vejo muita rodada de agentes acompanhada só pela conversa. Ele responde a duas perguntas que eu me fazia o tempo todo, o que está rodando agora e o que depende de quê, sem eu ter de perguntar. Para mim o Playmaker é bem mais simples de configurar e de acompanhar do que os subagentes do Bob que usei, e acredito que boa parte disso vem de o estado morar em um quadro e não em informação espalhada pela tela.

Proativos, os três, e a eficiência que ninguém mediu

Sobre quem é mais eficiente, a resposta honesta é que não há medição independente de nenhum dos três, infelizmente.

O que existe do lado do Bob são números da própria IBM. Uma matéria do DevOps.com repete o caso de um projeto de modernização que a Blue Pearl, uma empresa de serviços de nuvem, estimava em 9 meses e 14 engenheiros e que teria sido concluído em 3 dias com o Bob, e a própria matéria avisa que são números da IBM, de clientes da IBM, em um comunicado da IBM, sem explicar como o tempo foi medido (DevOps.com ↗ (abre em outra aba)). Um texto técnico sobre os subagentes do Bob afirma que rodar três em paralelo reduz de forma drástica o tempo total, sem apresentar medição (Heidloff ↗ (abre em outra aba)). Do lado do Kiro não achei número.

Para o Playmaker, a minha observação nos projetos é a de que o paralelo economiza tempo e gasta mais token, porque cada worker é uma sessão com contexto próprio.

Há uma diferença de desenho que a documentação deixa ver. O Bob parece pensado sobretudo para delegar a coleta de informação e as tarefas que sujariam o contexto principal. Nos modos Plan e Ask ele só cria subagentes do tipo explore, que leem e não escrevem, e só no modo Agent pode criar todos os tipos, inclusive o general, com acesso completo. O exemplo do Heidloff, com três subagentes escrevendo testes ao mesmo tempo, mostra que o uso para escrita existe. O Kiro planeja um grafo de tarefas e roda em paralelo as independentes, o que se parece mais com o que o Playmaker faz. A diferença está em quem garante que duas tarefas em paralelo não editem o mesmo arquivo, e nesse ponto o Playmaker põe a conta em um script em vez de deixá-la na conversa.

Onde o Bob parece mais forte, pelo que li e sem ter testado, é em fluxos corporativos com passos determinísticos, que usam código puro e não gastam token, e em um painel de custo integrado (Heidloff ↗ (abre em outra aba), DevOps.com ↗ (abre em outra aba)). São pontos reais, parecem interessantes.

Uma ferramenta a menos para assinar

Existe ainda uma diferença que não aparece na tabela lá de cima, mas que considero importante: o Playmaker não tenta substituir o ambiente em que você desenvolve. O Kiro e o IBM Bob são ferramentas completas, com seus próprios ambientes, configurações e formas de trabalhar. O Playmaker parte de outro princípio: você já tem um agente de que gosta, já paga por ele e não precisa trocar de ferramenta para trabalhar com vários agentes em paralelo.

Isso também vale para as ferramentas dedicadas à orquestração de agentes, como o Maestri. Existe todo um espaço de soluções voltadas a coordenar agentes, distribuir tarefas e organizar fluxos de execução. Para quem precisa desse tipo de recurso, adotar uma ferramenta adicional pode fazer sentido, mas também significa incorporar outro componente ao ambiente de desenvolvimento, com seu próprio custo e sua própria curva de aprendizado.

O Playmaker procura atender parte dessa necessidade de uma forma mais direta. Ele acrescenta gerenciamento de tarefas, isolamento por worktree, controle de dependências, integração de resultados e acompanhamento visual ao fluxo de trabalho que você já utiliza. Em vez de exigir que você migre para outro ambiente ou adote um framework de orquestração independente, aproveita as CLIs de agentes que já estão instaladas, como Claude Code, Codex e Antigravity, entre outras compatíveis.

Isso muda a conta. Você não precisa contratar outra assinatura de agente só para ter acesso à orquestração, nem depender de um único provedor para coordenar o trabalho. Pode continuar usando os serviços pelos quais já paga e misturar provedores quando fizer sentido. O Playmaker não elimina os custos de uso dos modelos, e ferramentas especializadas podem oferecer recursos que vão além do que ele propõe. A diferença é que, para determinados fluxos de desenvolvimento, talvez você não precise de toda essa estrutura adicional.

Para mim, essa é uma das decisões mais interessantes do projeto.

Em vez de construir outro ambiente que tenta concentrar todas as etapas do desenvolvimento, o Playmaker resolve um problema específico e deixa o restante onde já está. Você escolhe os agentes, mantém as assinaturas que fazem sentido para o seu trabalho e acrescenta uma camada de coordenação quando precisa dividir uma tarefa entre vários deles.

A proposta não é fazer você trabalhar dentro do Playmaker, mas permitir que você trabalhe melhor com as ferramentas que já escolheu. Isso reduz a barreira para experimentar o desenvolvimento com múltiplos agentes e permite obter parte dos benefícios da orquestração sem necessariamente investir em mais uma plataforma. Para desenvolvedores independentes e equipes pequenas, essa simplicidade pode ser tão importante quanto os próprios recursos técnicos.

O combo que, na minha leitura, o mundo usa

Aqui entra uma opinião minha, sem pesquisa de mercado por trás. Pelo que acompanho do setor, equipes que levam desenvolvimento agêntico a sério tendem a montar a mesma família de peças, e as quatro que mais aparecem para mim são estas.

O LangGraph é um framework de orquestração de baixo nível para agentes com estado, com execução durável, supervisão humana no meio do caminho e memória, e tem licença MIT (repositório ↗ (abre em outra aba)). O Deep Agents é um harness de agente já pronto, construído sobre o LangGraph, com planejamento, sistema de arquivos, subagentes com janela de contexto isolada e memória entre sessões, também MIT (repositório ↗ (abre em outra aba)). O OpenMemory, no repositório de hoje, é uma CLI para portar sessões de programação entre Claude Code, Codex e OpenCode, em beta (repositório ↗ (abre em outra aba)). O LangSmith é uma plataforma para observar e avaliar aplicações com LLM, em que os traces são o registro do que os agentes fizeram (documentação ↗ (abre em outra aba)).

A Síntese montou o equivalente por função, e a tabela abaixo mostra a correspondência.

As ferramentas da Síntese cobrem as funções que a gente usa. A equivalência é por função e não por paridade. O Lore guarda memória de projeto compartilhada entre pessoas e agentes, e o OpenMemory leva uma sessão de uma ferramenta para outra, então o ponto em comum é o contexto que sobrevive à sessão. A única coisa que o combo tem e a gente não tem é a execução durável do LangGraph, e hoje o Playmaker depende de um agente interativo para ser o gerente. Estudei rodá-lo em servidor ou CI, sem ninguém na conversa, e isso pediria um runtime próprio, em que o LangGraph seria uma boa base. Deixei para depois, talvez trabalhemos nisso em uma próxima versão.

Três perguntas para fazer a qualquer ferramenta

Seja qual for a ferramenta, três perguntas ajudam a ver o que está em código e o que está na conversa. A primeira é quem faz a conta de que duas tarefas em paralelo não vão editar o mesmo arquivo, e se essa conta sai igual na décima rodada. A segunda é quem confere o que voltou antes de integrar, e em qual cópia do repositório. A terceira é onde você vê, sem perguntar, o que está rodando, o que está esperando e o que depende de quê, e onde o rastro de quem decidiu o quê fica depois que a sessão acaba.

No fim, não basta ter mais agentes

Acho que estamos entrando em uma fase em que colocar vários agentes para trabalhar ao mesmo tempo deixou de ser a parte mais interessante do desenvolvimento agêntico. O desafio agora é fazer isso sem transformar o repositório em uma disputa de contexto, arquivos e decisões que ninguém consegue acompanhar.

Kiro e IBM Bob mostram que existe uma demanda por delegação proativa dentro dos ambientes de desenvolvimento. LangGraph, Deep Agents e outras ferramentas mostram que há um ecossistema inteiro sendo construído em torno da orquestração. O Playmaker é a nossa maneira de abordar esse problema: não como um novo ambiente de desenvolvimento, mas como uma camada que organiza o trabalho dos agentes que você já utiliza.

Não acho que ele substitua todas essas ferramentas, nem que precise fazê-lo. Cada uma tem escolhas de arquitetura e problemas que pretende resolver. O que acredito é que boa parte dos desenvolvedores não precisa começar montando uma infraestrutura inteira de orquestração para conseguir trabalhar com agentes em paralelo. Precisa saber o que cada um está fazendo, evitar que um atrapalhe o trabalho do outro e ter alguma garantia de que o resultado foi verificado antes de entrar no projeto.

No desenvolvimento agêntico, a quantidade de agentes importa menos do que a qualidade da coordenação entre eles. É nisso que estamos trabalhando na Síntese.

Fontes

• Repositórios da Síntese, Playmaker ↗ (abre em outra aba) e Blueprint ↗ (abre em outra aba).
• Lore ↗ (abre em outra aba).
• Kiro, subagentes em agentes personalizados ↗ (abre em outra aba) e Kiro Crew, subagentes ↗ (abre em outra aba).
• Kiro, documentação de specs ↗ (abre em outra aba) e de steering ↗ (abre em outra aba).
• IBM Bob, subagentes ↗ (abre em outra aba) e modos ↗ (abre em outra aba).
• Niklas Heidloff, Introducing Workflows and Sub-Agents in IBM Bob v2 ↗ (abre em outra aba).
• DevOps.com, IBM Bob Gets Multi-Agent Muscle and a Cost Dashboard for Enterprise Coding ↗ (abre em outra aba).
• LangChain, LangGraph ↗ (abre em outra aba), Deep Agents ↗ (abre em outra aba) e LangSmith ↗ (abre em outra aba).
• Mem0, OpenMemory ↗ (abre em outra aba).