Agent Operations Lead: a Nova Função Que Vira Core Job da Liderança

Há dois anos, se eu quisesse saber o que meu time estava produzindo, bastava olhar o board do Jira e conversar em uma daily. Hoje, cada desenvolvedor do meu time roda o próprio "mini-time" de agentes de IA: um revisando pull request, outro gerando testes, outro escrevendo documentação, às vezes três ou quatro em paralelo na mesma feature. Multiplique isso pelo time inteiro e você tem uma organização operando numa escala que nenhum processo de gestão que aprendi nos últimos quinze anos foi desenhado para lidar.

Esse é o ponto central deste post: como head de tecnologia, não respondo só pelo trabalho das pessoas do meu time — respondo pelo comportamento agregado de uma frota de agentes de IA que essas pessoas operam. E a infraestrutura de liderança que construí a carreira toda para gerenciar humanos simplesmente não se transfere para gerenciar agentes. Não é a mesma disciplina, não são os mesmos sinais de alerta, não é o mesmo ritmo de decisão.

Diante desse gap, está surgindo uma função nova nos times de engenharia mais maduros em IA: o agent operations lead. É sobre essa função — o que ela faz, por que está aparecendo agora, e como decidir se você precisa criar essa cadeira — que eu quero falar hoje. Se você já leu meu post sobre topologia de times e agentes, pense neste como a continuação natural: aquele falou de como desenhar a estrutura, este fala de quem opera essa estrutura no dia a dia.

---

O que muda quando você lidera agentes, não pessoas

Gerenciar pessoas é, no fundo, gerenciar intenção, alinhamento e crescimento ao longo do tempo. Faço one-on-ones, dou feedback, ajudo alguém a crescer de pleno para sênior. Gerenciar agentes de IA é outra categoria de problema: não tem crescimento de carreira, não tem motivação, não tem contexto emocional. Tem comportamento, custo, taxa de erro e volume — e esses quatro eixos mudam de hora em hora, não de trimestre em trimestre.

Quando um desenvolvedor comete um erro recorrente, identifico o padrão em semanas e ajusto com uma conversa. Quando um agente erra, ele pode repetir o erro centenas de vezes num único dia, espalhado por múltiplos repositórios, antes que alguém perceba. A superfície de dano de um agente mal calibrado é ordens de magnitude maior que a de uma pessoa mal calibrada, e o tempo de detecção precisa ser proporcionalmente menor — não porque agentes sejam piores que humanos, mas porque a velocidade e a escala mudam o que "gestão" significa na prática.

O desafio central de gestão em 2026 é o gap entre geração e impacto. Times rodando múltiplos agentes em paralelo, em várias features ao mesmo tempo, produzem hoje num único dia mais material bruto — código, testes, documentação, propostas de refatoração — do que um time totalmente staffado produzia numa semana inteira, há apenas dois anos. Só que gerar não é o mesmo que entregar valor: alguém precisa revisar e decidir o que entra em produção. E esse "alguém" não escala na mesma proporção que os agentes escalam.

É exatamente nesse gap que a função de agent operations lead nasce. Não é sobre escrever mais código com IA — é sobre garantir que o volume gerado pelos agentes vire trabalho confiável e sustentável em produção, em vez de virar um passivo técnico silencioso que ninguém está monitorando.

O que o agent operations lead faz, na prática

Na prática, o agent operations lead cuida das "operações do software que pensa". Isso inclui, primeiro, tracking de deploy: quais agentes estão rodando, em quais repositórios, com quais permissões, e o que cada um mudou em produção nas últimas horas. Não é foto estática — é painel vivo, porque a frota muda de composição várias vezes ao dia.

Segundo, tracking de custo. Cada chamada de agente tem um preço, que varia com o modelo, o contexto e quantas iterações o agente precisou até convergir numa resposta aceitável. Sem alguém observando isso de forma agregada, é fácil um time descobrir só no fechamento do mês que gastou dez vezes mais do que devia porque um agente entrou num loop de retry silencioso. A conexão com observabilidade é direta — já escrevi sobre observabilidade e tracing de agentes em produção, e é esse tipo de instrumentação que dá ao agent operations lead a visibilidade que ele precisa para agir antes que o problema apareça na fatura.

Terceiro, identificação de bottlenecks. Diferente de um bottleneck humano — normalmente sobrecarga de uma pessoa específica — um bottleneck de agentes aparece como fila: agentes esperando revisão, revisores afogados em output que não conseguem validar na velocidade em que é gerado, ou agentes bloqueados por dependência de dados. O agent operations lead enxerga esse fluxo de ponta a ponta e decide onde adicionar capacidade, reduzir paralelismo, ou pausar um agente que gera mais trabalho de revisão do que valor.

Quarto, e talvez o mais estratégico: capacity planning. Isso significa projetar quantos agentes uma equipe consegue operar de forma responsável, dado o tamanho do time humano disponível para validar o que sai deles — um cálculo novo, sem histórico longo de referência, que muda a cada trimestre conforme os modelos melhoram.

---

AI governance specialist: o outro papel que está surgindo junto

Vale separar duas funções que às vezes se confundem. Enquanto o agent operations lead cuida do dia a dia operacional — deploy, custo, bottleneck, capacidade — surge também o AI governance specialist, cujo foco é outro: definir o que os agentes têm permissão de fazer, e depois auditar se essas regras estão sendo seguidas.

Na prática, o governance specialist escreve as políticas: este agente pode abrir pull request, mas não pode fazer merge; aquele pode tocar em código de billing, mas só em modo de sugestão, nunca com push direto; nenhum agente altera infraestrutura de produção sem aprovação humana explícita. E depois, criticamente, é quem audita — porque política sem auditoria é só um documento bonito que ninguém segue quando a pressão de entrega aperta.

---

---

Essas duas funções trabalham coladas, mas não são a mesma coisa. O agent operations lead quer velocidade e eficiência operacional; o governance specialist quer segurança e conformidade. Times pequenos acumulam as duas responsabilidades numa única pessoa no começo, mas conforme a frota cresce, vejo essas cadeiras se separando — otimizar para velocidade e otimizar para controle de risco puxam decisões em direções opostas, e é saudável ter vozes diferentes defendendo cada lado.

Um jeito simples de pensar nisso: o agent operations lead responde "os agentes estão rodando bem?"; o governance specialist responde "estão rodando dentro do que é permitido?". Se uma única pessoa tenta responder as duas sob pressão de prazo, a resposta que perde é quase sempre a de governança — porque ela não aparece no dashboard de velocidade que todo mundo olha primeiro.

Como fica o time de engenharia efetivo em 2026

Se eu desenhasse hoje o time de engenharia ideal para essa realidade, não desenharia um time de "desenvolvedores que usam IA". Desenharia camadas com responsabilidades diferentes. No topo, um ou dois arquitetos de IA sênior, responsáveis pelo design do sistema de agentes e pelos guardrails — as regras que limitam o que qualquer agente pode fazer, antes mesmo de o governance specialist entrar em cena caso a caso.

Depois vêm os engenheiros de nível médio, com papel que mudou de forma real: atuam como validadores. Não é rebaixamento de função — é, na minha experiência, um dos trabalhos mais difíceis de fazer bem, porque exige julgamento técnico rápido sobre output que pode parecer plausível mesmo quando está sutilmente errado. Revisar código de agente exige um ceticismo diferente do que revisar código de colega humano.

---

---

Ao lado disso, especialistas de domínio em segurança e engenharia de dados continuam essenciais, porque agentes tendem a otimizar para "funciona" sem entender as implicações de segurança ou de qualidade de dado de longo prazo. E, na camada de execução, os próprios agentes de IA, fazendo o trabalho de produção em volume.

O agent operations lead não substitui nenhuma dessas camadas — garante que elas conversem entre si de forma sustentável, olhando o sistema inteiro em vez de uma feature por vez. É um papel de cola operacional, parecido com o que um SRE faz para infraestrutura, aplicado a "software que pensa" em vez de servidores.

Quando contratar (ou virar) um agent operations lead

A pergunta prática é: minha empresa já precisa disso, ou ainda é cedo? Uso três sinais para decidir. O primeiro é volume: se o time já tem mais de cinco ou seis agentes rodando de forma independente, espalhados por squads diferentes, e ninguém sabe de cabeça quantos estão ativos agora, é sinal de que a visibilidade se perdeu.

O segundo é custo surpresa. Se a fatura de uso de modelo já surpreendeu o financeiro nos últimos dois meses — para cima, claro — é porque ninguém faz tracking de custo em tempo real com granularidade de agente. Esperar o boleto chegar para descobrir que um agente ficou em loop por seis horas é o equivalente moderno de só descobrir um vazamento de memória quando o servidor cai.

O terceiro sinal é o gap entre geração e revisão: se seus engenheiros de nível médio estão constantemente atrasados revisando output de agente, e a fila só cresce, o problema não é "precisamos de mais revisores" — é capacity planning, que precisa de alguém dedicado, não de mais responsabilidade empilhada em quem já está sobrecarregado.

Se esses sinais aparecem e não há orçamento para contratar alguém novo, a resposta honesta é: você mesmo precisa assumir esse chapéu, mesmo que parcialmente. Não dá para terceirizar a visibilidade sobre a frota de agentes para "depois resolvemos" — o comportamento agregado dela já é, hoje, parte do seu trabalho, queira você ou não.

Conclusão

A função de agent operations lead não é modismo de vaga do LinkedIn — é resposta a um problema estrutural que já existe no seu time hoje, mesmo sem esse nome na sua organização. Cada desenvolvedor rodando seu próprio mini-time de agentes criou uma escala de execução que a liderança tradicional, pensada para gerenciar pessoas, não estava preparada para monitorar em tempo real.

O que levo desse tema para o meu dia a dia é simples: parar de tratar "gestão de agentes" como subproduto de "gestão de pessoas" e tratá-la como disciplina própria, com métricas próprias — deploy, custo, bottleneck, capacidade — e, se possível, dono próprio. Junto com o AI governance specialist cuidando de permissões e auditoria, essas duas funções formam o par que falta na maioria dos times que já usam agentes em produção, mas ainda governam essa camada no improviso.

Se você ainda não sabe responder de cabeça quantos agentes estão ativos no seu time agora, quanto custaram no mês passado, e onde está a maior fila de revisão pendente, essa é a pergunta para levar à próxima reunião de squad. Não precisa ser uma contratação nova amanhã — mas precisa ser responsabilidade explícita de alguém, o mais rápido possível.

Fontes:

• Allstacks — Managing AI Agents Is Now the Core Job of Engineering Leadership
• Optimum Partners — Engineering Management 2026: Structuring an AI-Native Team
• CIO — How Agentic AI Will Reshape Engineering Workflows in 2026
• Corby Fine Coaching — Managing AI Agents as a Leader