Orquestrar agentes é a habilidade mais defensável da era da IA

Artigo 1 de 4 da série “As seis habilidades da era dos agentes”. Os outros: aprender a arquitetura, não a ferramenta · o primeiro agente sério · o stack de habilidades.

Em um vídeo recente, o investidor Greg Isenberg fez uma provocação que vale a pena levar a sério: “aprenda IA” virou um conselho inútil. Genérico demais. No lugar, ele listou seis habilidades concretas que ficam mais valiosas conforme a IA melhora — não menos. E colocou em primeiro lugar uma que descreveu como “a versão adulta do prompt engineering”: saber configurar agentes corretamente, gerenciá-los e, quando faz sentido, rodar modelos localmente.

Quero passar este artigo inteiro defendendo uma tese: essa não é só “mais uma” das seis. É a base de todas as outras, e é a mais defensável de carreira que existe hoje. Porque é a única que a própria IA não consegue absorber.

O problema que toda empresa está prestes a ter

Isenberg descreve o futuro próximo das empresas com uma precisão que merece atenção. A imagem é mais ou menos esta: dez ferramentas de IA contratadas, cinquenta workflows espalhados, um monte de automações meio funcionando — e ninguém na organização capaz de transformar esse amontoado no que ela de fato quer, que é um sistema operacional de trabalho.

Não é um problema de ferramenta faltando. É o oposto: ferramenta sobrando, orquestração faltando.

A pessoa valiosa nesse cenário, na descrição dele, é a que consegue entrar e dizer, com clareza: aqui está o agente de suporte, aqui o de pesquisa, aqui o de follow-up de vendas; aqui estão as regras de cada um; aqui o que cada um tem permissão de fazer; aqui onde ele precisa de aprovação humana; e aqui como a gente sabe se está funcionando. Quem sabe fazer isso, conclui Isenberg, fica muito difícil de substituir.

Pare nessa última frase. “Difícil de substituir” é a definição operacional de uma habilidade defensável. E repare no que ela exige: não é digitar bem numa caixa de texto. É arquitetar um sistema de responsabilidades.

A diferença entre um prompt e um agente

A confusão mais comum no mercado é achar que prompt engineering e orquestração de agentes são a mesma coisa em escalas diferentes. Não são. São camadas distintas.

Um prompt é uma instrução. Você pede, o modelo responde, e a transação morre ali. É útil, é uma porta de entrada, e virou commodity — qualquer pessoa aprende a escrever um prompt decente numa tarde.

Um agente, na imagem que o próprio Isenberg usa, é um pequeno funcionário. E um funcionário tem seis coisas que um prompt não tem:

• Contexto — ele sabe sobre o que está trabalhando, com acesso aos dados certos.
• Ferramentas — ele pode agir no mundo: consultar um sistema, escrever num arquivo, disparar uma mensagem.
• Permissões — há coisas que ele faz sozinho e coisas que ele precisa pedir autorização para fazer.
• Memória — ele lembra do que aconteceu antes, dentro e entre execuções.
• Uma meta — ele existe para um resultado específico, não para “responder perguntas”.
• Uma forma de checar o próprio trabalho antes de te incomodar.

Esse último ponto — autoavaliação antes de escalar para o humano — é o que separa um agente de produção de um chatbot caro. Um funcionário júnior que entrega trabalho errado sem revisar dá mais trabalho do que economiza. Um agente sem eval é exatamente isso.

Orquestração é o ofício de montar esses seis elementos para cada agente, e depois fazer vários deles conviverem sem se atropelar. Não é uma habilidade de digitação. É uma habilidade de projeto de sistemas — só que o material de construção, agora, é linguagem e julgamento, não código puro.

Por que essa é a habilidade que a IA não terceiriza

Aqui está o argumento central, e por que coloco essa skill acima das outras cinco.

Conforme a IA melhora, ela vai escrever cada vez mais código sozinha. Vai gerar a automação, montar o fluxo, sugerir o prompt. Quase tudo na pilha técnica fica mais barato e mais abundante. Então o valor migra para o que não fica abundante.

E o que não fica abundante é o julgamento sobre qual trabalho deve virar agente, onde a informação está presa, e quem aprova o quê. A IA pode construir o agente. Ela não pode decidir, pela sua empresa, que a aprovação de um desconto acima de 15% tem que passar por um humano, ou que o agente de suporte nunca toca em dados financeiros, ou que o follow-up de vendas só dispara depois que o CRM confirma que a proposta foi aberta. Essas decisões são sobre risco, confiança e responsabilidade dentro de uma operação específica. Elas exigem alguém que entenda o negócio e a máquina.

Esse alguém tem nome no Vale do Silício: Forward Deployed Engineer. É o cargo que explodiu nas conversas sobre IA justamente porque mapeia, palavra por palavra, a descrição de Isenberg. Ele não chama de FDE no vídeo — chega à definição por outro caminho, olhando o mercado de fora, como investidor. Quando uma descrição de cargo emerge de dois ângulos independentes ao mesmo tempo, não é moda. É uma categoria se consolidando.

No Brasil, eu chamo isso de Engenharia de Agentes. Mesmo ofício, nome traduzido.

A parte “local” não é detalhe técnico

Isenberg insiste num ponto que muita gente trata como nota de rodapé: aprender a rodar modelos localmente, com ferramentas como Ollama ou LM Studio. O contra-argumento óbvio aparece nos comentários do próprio vídeo — “modelos locais vão ficando menores, isso vai perder importância”. A resposta dele é a parte que interessa.

Mesmo que os modelos locais encolham, você aprende a arquitetura do futuro. Você passa a entender quais tarefas precisam de um cérebro gigante na nuvem e quais precisam apenas de um trabalhador confiável que nunca dorme. Aprende o que pode ficar na sua máquina, o que precisa tocar documentos privados, o que deve ficar atrás de uma parede por questão de privacidade, custo ou latência — e como tudo isso se conecta.

Para quem faz FDE de verdade, isso é pão com manteiga. O cliente que se importa com soberania de dados não vai mandar a base de contratos para uma API de terceiro. A decisão “local vs. nuvem” é, na prática, uma decisão de arquitetura que você toma toda semana. Saber tomá-la é parte do mesmo músculo de orquestração — só que aplicado à infraestrutura.

Como começar a treinar esse músculo

Isenberg dá um conselho de prática que eu assino embaixo, e que detalho no terceiro artigo desta série: não tente construir o agente que sabe tudo. Construa um agente pequeno, faça ele virar muito valioso, agende e dê a ele uma métrica clara de sucesso.

O reflexo de orquestração se treina assim — no concreto, num escopo apertado, com responsabilidade real. Cada agente pequeno que você coloca de pé te ensina os seis elementos de uma vez: contexto, ferramentas, permissões, memória, meta e avaliação. Some dez desses e você não aprendeu “a usar IA”. Você aprendeu a projetar a operação de uma empresa em cima de IA.

E é por isso que essa é a habilidade que eu colocaria em primeiro lugar também. As outras cinco da lista de Isenberg — distribuição, robótica, curadoria, builder-distributor, comunidade — são alavancas poderosas. Mas todas elas, dentro de uma empresa, acabam precisando de agentes bem orquestrados para escalar. Essa skill é o chão onde as outras pisam.

Leia a série completa:

• 1/4: Orquestrar agentes é a habilidade mais defensável
• 2/4: “Aprender IA” é um conselho ruim
• 3/4: O primeiro agente sério
• 4/4: As seis habilidades da era dos agentes

Se a sua empresa já tem ferramentas de IA demais e sistema de menos, o gargalo não é o modelo. É a orquestração — a skill número um.

👉 Agende uma call de descoberta de 30 minutos. A gente mapeia quais dos seus processos já merecem virar agentes — e quem aprova o quê.

Inspirado no vídeo de Greg Isenberg, “Learn AI” Is Bad Advice. Learn This Instead. As ideias sobre as seis habilidades são dele; a leitura sob a ótica de Forward Deployed Engineering é da 21 Robots.