Autonomia de agentes em produção: como definir o que roda sozinho e o que passa por validação
6 perguntas para Marcos Francisco, Head de Tecnologia na RankMyApp
Colocar um agente pra gerar código, escrever teste ou levantar especificação virou trivial. A maioria dos times já faz isso, em algum grau, hoje.
O que não é trivial é o que acontece quando dezenas desses agentes executam ao mesmo tempo em produção. A arquitetura que multiplica a entrega multiplica também a velocidade com que um erro chega lá. A pergunta deixa de ser quanto o agente produz e passa a ser quem mantém a responsabilidade final sobre o que foi entregue.
Conversamos com Marcos Francisco, Head de Tecnologia na RankMyApp, sobre o que precisa estar no lugar antes de ampliar a autonomia de um agente e por que governança, aqui, não é freio, é o que permite acelerar.
Como você define o que um agente pode executar sozinho e o que ainda exige validação humana, quando esse critério precisa valer para todas as squads??
MF: A autonomia de um agente deve ser proporcional ao risco da atividade que ele executa. Essa foi a primeira premissa que adotamos. Não tratamos agentes apenas como ferramentas, mas como novas personas dentro da organização, cada uma com responsabilidades, permissões e limites claramente definidos.
Atividades de baixo impacto, como geração de documentação, criação de testes ou propostas iniciais de código, podem ser executadas de forma totalmente autônoma. Já decisões que afetam produção, segurança, infraestrutura ou experiência do cliente precisam passar por validação humana.
Por isso, estruturamos nossa governança seguindo o conceito de Human in the Loop (HITL). O objetivo não é que o ser humano execute tudo, mas que governe o processo, valide decisões críticas e mantenha a responsabilidade final sobre aquilo que chega ao ambiente produtivo.
Na prática, percebemos que o desafio não é construir agentes inteligentes. O verdadeiro desafio é construir mecanismos para que essa inteligência seja utilizada de forma segura, previsível e auditável.
Na sua visão, o que muda na gestão de risco quando agentes passam a executar dentro do fluxo de produção? O que precisa estar sob controle antes de ampliar essa autonomia com segurança?
A principal vantagem de uma arquitetura baseada em agentes é exatamente aquilo que também representa seu maior risco: velocidade e paralelismo.
Quando dezenas de agentes conseguem produzir especificações, código, testes e documentação simultaneamente, aumentamos significativamente a capacidade de entrega. Porém, também ampliamos a velocidade com que erros podem ser propagados para produção.
Por isso, antes de ampliar qualquer autonomia, estruturamos uma camada robusta de governança baseada em quatro pilares:
observabilidade completa da execução dos agentes;
trilhas de auditoria para todas as decisões;
guardrails técnicos e de segurança;
mecanismos de rollback e fallback quando o comportamento esperado não é atingido.
Além disso, acompanhamos continuamente indicadores como taxa de revisão humana, retrabalho gerado pelos agentes e qualidade das entregas.
A inteligência artificial aumenta exponencialmente nossa capacidade de execução. A governança precisa crescer na mesma velocidade.
Visão de Arquitetura para Orquestradores e Agentes de IA
Na prática, o que você acompanha no dia a dia pra saber se um processo de desenvolvimento com agentes está rodando conforme o esperado, além do output continuar saindo?
O volume de código produzido deixou de ser uma métrica relevante. O que realmente importa é a eficiência do processo.
Hoje acompanhamos indicadores que mostram se os agentes estão gerando valor ou apenas aumentando o retrabalho.
Entre eles, destaco:
Cycle Time, para medir a velocidade da entrega e identificar aumento de revisões humanas;
Taxa de retrabalho, indicando quando um agente começa a perder eficiência;
Custo por token, que permite avaliar eficiência operacional e otimização do uso dos modelos;
Taxa de aceite das sugestões geradas pelos agentes, que reflete diretamente sua qualidade.
Também observamos sinais indiretos. Quando um agente passa a consumir mais tokens para produzir resultados semelhantes ou exige um número crescente de intervenções humanas, normalmente isso indica necessidade de evoluir o contexto fornecido, revisar especificações ou até substituir o modelo utilizado.
Aprendemos que agentes precisam ser tratados como qualquer outro componente de software: monitorados, avaliados continuamente e evoluídos ao longo do tempo.
Na transição de experimentos pontuais com AI para um processo que o time opera no dia a dia, o que você estruturou desde o início, o que abandonou no caminho e o que só funcionou depois de virar regra?
A RankMyApp já utilizava IA nos seus produtos desde 2022. O desafio mais recente foi transformar esse uso em uma capacidade organizacional, integrada ao processo de engenharia.
Começamos avaliando 3 diferentes modelos de LLM e sua aderência aos nossos casos de uso. Em seguida, estruturamos uma arquitetura baseada em governança, separando claramente agentes de Upstream, responsáveis por entendimento e especificação, dos agentes de Downstream, voltados para implementação, testes e documentação. Totalizando o lançamento de 12 agentes no ambiente produtivo
Também criamos um orquestrador centralizado responsável pelo gerenciamento dos agentes, definição de permissões, políticas de fallback e aplicação de guardrails.
No início acreditávamos que cada desenvolvedor poderia manter seus próprios agentes. Funcionou enquanto a adoção era pequena, mas rapidamente percebemos que esse modelo gerava inconsistências, duplicação de conhecimento e dificuldades para evoluir a plataforma.
Migramos então para uma arquitetura centralizada, baseada em componentes compartilhados como AI Gateway, MCP homologados, catálogo de agentes, governança de prompts e ferramentas de avaliação de modelos.
O maior aprendizado foi perceber que IA não é uma funcionalidade adicional da engenharia. Ela passa a fazer parte da própria arquitetura da organização.
Que rituais e cerimônias do time perderam sentido ou mudaram de função quando AI virou parte do fluxo, e o que ocupou o espaço deles?
A principal mudança aconteceu antes mesmo do desenvolvimento começar.
No modelo tradicional, boa parte do tempo era consumida em reuniões de refinamento para esclarecer requisitos entre Produto e Engenharia.
Com a introdução de agentes de Upstream, grande parte desse trabalho passou a ser realizada automaticamente. Os agentes identificam inconsistências, levantam dúvidas, sugerem regras de negócio ausentes e organizam o contexto antes da implementação.
Isso reduziu significativamente a necessidade de reuniões operacionais e permitiu que o time utilizasse esse tempo para produzir especificações muito mais completas.
Percebemos que, em um ambiente AI-First, escrever uma boa especificação passou a ser muito mais importante do que escrever rapidamente um bom código.
O papel do engenheiro também mudou. Gastamos menos energia esclarecendo requisitos e mais tempo desenhando soluções, validando resultados e evoluindo a arquitetura.
Que fontes de informação você considera indispensáveis para que lideranças de Produto, Design e Engenharia se mantenham atualizadas sobre AI e seus movimentos no mercado?
O ritmo de evolução da IA é provavelmente o mais acelerado que já vimos na indústria de tecnologia. Por isso, acompanhar apenas lançamentos de modelos deixou de ser suficiente.
Minha recomendação é dividir o aprendizado em três níveis.
O primeiro é construir uma base sólida por meio de instituições reconhecidas, como MIT, Stanford, Harvard e NIST, além de acompanhar publicações sobre AI Engineering e governança de IA.
O segundo é acompanhar pesquisadores e profissionais que estão influenciando diretamente essa transformação, como Andrej Karpathy, Simon Willison e Ethan Mollick, que frequentemente compartilham aprendizados muito aplicáveis ao dia a dia das organizações.
O terceiro — e talvez o mais importante — é participar ativamente de comunidades e trocar experiências com outras empresas. É nessas conversas que surgem os aprendizados mais valiosos sobre adoção, governança e desafios reais.
Os modelos mudam quase diariamente. Os princípios de arquitetura, liderança e governança permanecem.