Quando o seu agente usa outro agente para codar

Existe uma mudança de paradigma que acontece quando você para de pensar em Claude Code como uma ferramenta interativa e começa a pensar nele como um componente que pode ser invocado programaticamente por outro sistema.

Claude Code pode ser chamado como subagente. Você passa contexto, define o escopo da tarefa, e o agente executa: escreve o código, roda, analisa o resultado, itera. Do ponto de vista do orquestrador externo, foi uma chamada que retornou um resultado. Do ponto de vista do Claude Code, foi uma sessão normal com um objetivo bem definido.

Esse padrão é o que o Hermes Agent implementa quando integra com Claude Code: o orquestrador gerencia memória, contexto de longo prazo, routing de intenções. Quando aparece uma tarefa de código, ele delega para o Claude Code como subagente especializado.

O que muda quando você trata um agente de código como ferramenta

A diferença entre ter um agente que gera código e ter um agente que pode delegar para um agente que gera e executa código é maior do que parece.

No primeiro caso, você tem um componente especializado. Ele sabe fazer uma coisa bem. Mas ele só funciona dentro dos limites do que foi projetado. Se a tarefa muda, você precisa mudar o agente.

No segundo caso, você tem um orquestrador geral que pode delegar dinamicamente. A tarefa de código não precisa ser prevista em design time. O orquestrador recebe uma intenção, reconhece que envolve código, invoca o subagente especializado com o contexto relevante, e incorpora o resultado no fluxo principal.

Isso é especialmente poderoso porque Claude Code não é só geração: é geração mais execução mais avaliação do resultado. O subagente retorna não só o código, mas o output da execução e o raciocínio sobre o que funcionou ou não. O orquestrador recebe isso como contexto estruturado para decidir o próximo passo.

Como isso se aplica em sistemas empresariais

No Athena, o agente que gera queries SQL para o TOTVS Protheus, o fluxo atual é especializado por design. O agente recebe uma pergunta, busca contexto de estrutura de tabelas e regras de negócio, gera a query, e devolve o resultado. Funciona bem para o escopo que foi projetado.

Mas existe uma limitação: quando a query precisa de iteração, quando o resultado não corresponde ao esperado e o agente precisa reformular, esse ciclo ainda depende muito da camada de orquestração externa para fechar o loop. Um subagente com capacidade de execução real, que pode rodar a query, analisar o retorno e iterar de forma autônoma, mudaria o que é possível sem intervenção humana no meio.

O mesmo vale para o GITFLOW, onde processos de automação de BPM envolvem lógica condicional que precisa ser testada antes de entrar em produção. Ter um agente que pode gerar a lógica, instanciar um ambiente de teste, validar o comportamento e reportar o resultado muda o custo de desenvolvimento de automações complexas.

O que você ganha e o que você sacrifica

Usar um agente como subagente tem custos reais.

O primeiro é latência. Uma chamada de Claude Code como subagente não é instantânea. Tem overhead de inicialização, de contexto, de execução. Para tarefas de código que levam segundos ou minutos, isso é aceitável. Para tarefas que precisam ser rápidas, pode não ser.

O segundo é custo de tokens. Cada invocação do subagente tem seu próprio contexto, seu próprio histórico, seus próprios tokens de input e output. Em workflows de alto volume, isso entra no cálculo.

O terceiro é complexidade de depuração. Quando o sistema falha, você agora tem duas camadas de agente para investigar. O orquestrador tomou a decisão certa de delegar? O subagente recebeu o contexto correto? O resultado foi interpretado da forma adequada? Cada uma dessas perguntas exige observabilidade separada.

Quando vale a pena

O padrão de agente-delegando-para-agente faz sentido quando a tarefa de código tem escopo variável e não pode ser totalmente prevista em design time, quando o ciclo de tentativa-erro-iteração é intrínseco ao problema, e quando você precisa de um orquestrador que mantenha estado de longo prazo enquanto o subagente executa tasks discretas.

O que muda com esse padrão é o nível de autonomia que você consegue sem sacrificar qualidade. Em vez de um agente especializado que é bom dentro dos limites do que foi projetado, você tem uma composição onde o orquestrador é responsável pelo raciocínio estratégico e o subagente é responsável pela execução técnica.

Em que tipo de tarefa no seu domínio um subagente com capacidade de execução de código mudaria o que é possível fazer de forma autônoma?