Orquestrador e Subagentes
A arquitetura em que um agente central distribui tarefas para agentes especializados, cada um com a própria janela de contexto e o próprio modelo.
O desenho
Num grafo, o nó que se conecta a todos os outros vira o orquestrador, e cada nó ao redor vira um subagente.
- Antes: você conversa com um agente único, que faz tudo.
- Agora: você fala só com o orquestrador, que comanda os subagentes, tem a visão do todo e distribui tarefas em paralelo.
O orquestrador sabe o que cada subagente está fazendo. Os subagentes não sabem uns dos outros, e na maioria dos casos é assim que deve ser.
Colocando nome nas bolinhas: agente de roteiro, agente de thumbnail, agente de SEO. Eles rodam em paralelo porque roteiro não depende de thumbnail nem de SEO.
E dá para descer níveis. O agente de roteiro pode ter três subagentes por idioma, porque cada mercado tem ângulo e público diferentes. E dentro de cada um mora um gauntlet loop com executor e revisor.
As duas vantagens que pagam a conta
1. Janela de contexto limpa. Cada agente tem a própria janela. O orquestrador gasta pouquíssimo token, talvez 20 mil, só para distribuir tarefa. O resultado fica mais preciso porque a etapa de roteiro não sabe nada de thumbnail, e não precisa saber.
2. Diversificação de modelos. Cada agente pode usar um modelo diferente, e essa é a resposta para a objeção de que loop gasta mais token.
| Papel | Modelo recomendado |
|---|---|
| Orquestrador | Modelo de fronteira, janela grande, porque recebe tudo de volta |
| Roteiro | Intermediário já resolve |
| Thumbnail e etapas auxiliares | Modelos menores e mais baratos |
A analogia do estagiário
Pensa no estagiário da sua empresa. Ele sabe pouco, é a parte mais fraca. Mas se existe onboarding, se as pastas estão organizadas e se os processos estão claros, ele não tem dificuldade.
Não é o estagiário que é bom, é a empresa em volta dele que é boa. É exatamente por isso que dá para colocar modelos mais fracos em etapas do processo, desde que você gaste tempo estruturando o sistema.
Gates humanos
Não existe automatizar um canal do início ao fim, a não ser que o resultado seja ruim mesmo. A pipeline precisa de gates humanos: etapas marcadas como humanas, e etapas automatizadas que ainda dependem de aprovação. Quando o sistema detecta desvio das especificações, ele para e avisa.