Transformação para IA agentic: o playbook de 4 etapas do Google
Tive uma pequena discussão comigo mesmo no último domingo de manhã. Eu tinha acabado de mapear o sétimo “agente de IA” que construí neste trimestre — uma coisinha organizada alimentada pelo Claude que coleta preços de concorrentes, joga tudo em uma planilha e me avisa no Slack. Funciona. Economiza talvez quarenta minutos por semana. E, olhando para o diagrama, percebi algo desconfortável.
Eu tinha construído sete agentes. Eu tinha construído zero fluxos de trabalho.
Essa distinção parece preciosismo semântico até você refletir sobre ela. Então, deixa de parecer preciosismo e começa a soar como o verdadeiro motivo pelo qual a maioria dos projetos-piloto de IA corporativa morre silenciosamente no segundo ano. E é exatamente esse o problema que o novo Framework de Transformação Agentic de IA do Google — aquele que a Clara apresenta no curso de Estratégia Agentic no Google Skills — foi criado para resolver.
Passei boa parte de três dias trabalhando com o framework, mapeando-o em relação aos meus próprios projetos e testando se ele realmente se sustenta fora de uma demonstração polida de varejo. Algumas partes mudaram a forma como estou estruturando meu próximo projeto com clientes. Outras, acredito que são genuinamente complicadas demais para quem constrói sozinho. E uma etapa — a de engenharia de valor — é justamente aquilo que eu gostaria que alguém tivesse me entregado dezoito meses atrás.
Deixe-me mostrar o que quero dizer.
A Diferença Entre um Agente e um Workflow Agente
Aqui está a frase que mudou completamente minha perspectiva: um agente de IA executa uma tarefa. Um sistema de IA agente executa um processo.
Quando desenvolvi aquele scraper de preços da concorrência, criei um agente. Ele faz uma coisa, em um momento específico, e então para. Um humano ainda precisa analisar os dados, decidir se precisamos ajustar nossos preços, redigir o ticket de alteração, obter aprovação e colocar a mudança no ar. O agente é uma ferramenta. O workflow ainda é totalmente humano.
Um sistema agente é o que acontece quando você para de encaixar a IA em tarefas isoladas e começa a entregar a ela todo o processo. Ele coleta os preços dos concorrentes. Analisa se a diferença é relevante. Verifica nossa política de margem. Redige uma alteração de preço. Submete para quem precisa aprovar. Publica a atualização no catálogo de produtos. Monitora a conversão pelas próximas 72 horas e, então, mantém a alteração ou a reverte.
Isso não é um agente maior. É uma categoria diferente de sistema.
A abordagem do Google — e acredito que esteja correta — é que estamos em um ponto de inflexão com IA agente semelhante ao que vivenciamos com computação em nuvem por volta de 2010 ou com mobile em 2008. Não é apenas uma “nova ferramenta útil”. É uma reorganização de como o trabalho é realizado. As empresas que entenderam a arquitetura cloud-native cedo engoliram as que trataram a AWS como “servidores alugados”. Essa mesma divisão está começando agora entre IA agente e IA de tarefas.
E em nenhum lugar essa divisão é mais visível do que no varejo.
Comércio Agente e a Morte Silenciosa do Clique
Aqui está um número que deve chamar a atenção de todo fundador de e-commerce. A eMarketer projeta que o comércio eletrônico impulsionado por plataformas de IA atingirá cerca de US$ 20,9 bilhões em 2026 — um salto de aproximadamente 4x em relação a 2025. A McKinsey prevê que o comércio agente gerará US$ 1 trilhão em receita no varejo dos EUA até 2030. O Morgan Stanley acredita que quase metade dos compradores online estará usando agentes de compras baseados em IA até lá, respondendo por cerca de um quarto de seus gastos.
Tradução: uma porcentagem significativa dos seus futuros clientes nunca verá sua landing page. Eles dirão a um agente o que precisam. O agente fará a compra.
É disso que as pessoas falam quando mencionam o “comércio zero clique”, e isso já está aparecendo nos dados de tráfego — o tráfego de mecanismos de busca para destinos de marcas específicas caiu cerca de 25% na entrada de 2026, com uma migração clara para canais de GenAI como ChatGPT, Perplexity e Gemini, que estão assumindo tanto a descoberta quanto (cada vez mais) a camada de transação. Cerca de 70% dos consumidores dizem estar pelo menos um pouco confortáveis em deixar um agente de IA realizar compras em seu nome. 45% já utilizam assistentes de IA para buscar ideias de produtos. 13% já concluíram uma compra por meio de um deles — e esse número é o alerta, não o teto.
Voltarei ao que isso significa para a forma como você constrói páginas de produto — há uma implicação específica e desagradável para SEO que acredito que a maioria das equipes ainda não considerou. Mas antes, o framework em si, porque é ele que vai dizer se você está construindo algo que sobrevive a essa mudança ou algo que morre com ela.
O Framework de Quatro Estágios do Google, Testado em Projetos Reais
O framework possui quatro estágios: Descobrir, Projetar, Construir, Escalar. Isso soa suspeitosamente como todo outro slide de consultoria que já vi. Não é. O valor está no conteúdo de cada estágio, e a ordem importa mais do que as pessoas costumam reconhecer. Vou guiá-lo por cada estágio da forma como a Clara estrutura no curso, e depois direi onde acredito que ele se adapta na prática.
Estágio 1: Descobrir — A Mudança de Mentalidade do “E Se?”
O estágio Descobrir é, em sua maioria, cognitivo. A tese é que a maioria das empresas encara a IA pensando no “como é” — ou seja, analisam o processo existente e perguntam: “Onde podemos encaixar IA para tornar isso mais rápido?” Essa pergunta tem um teto, e ele é baixo. Você acaba com uma versão mais rápida do mesmo processo. Uma tarefa de quarenta minutos vira uma tarefa de doze minutos. Legal. Mas não é transformador.
A mentalidade do “e se?” faz uma pergunta diferente. Ela diz: se tivéssemos um sistema incansável, razoavelmente inteligente, capaz de observar, decidir e agir em todo esse processo de ponta a ponta, como seria esse processo? Você para de otimizar os passos e começa a questionar se esses passos precisam existir.
Testei esse exercício com um fluxo de onboarding de clientes que eu estava “IA-ficando” para um pequeno SaaS. Pensando no “como é”, eu estava construindo um agente que redigia e-mails de boas-vindas. Pensando no “e se?”, perguntei: por que existe um e-mail de boas-vindas? Ele existia para guiar manualmente um novo usuário na configuração. Se um agente pode detectar uma nova conta, observar a primeira sessão do usuário e oferecer ajuda proativamente dentro do produto quando ele encontra dificuldades — não há e-mail de boas-vindas. Não há guia de configuração. Não há ticket no help center sobre “como começar”. Todo o formato do onboarding muda.
Esse é o abismo entre o “como é” e o “e se?”. E o desconforto desse abismo é o verdadeiro entregável do primeiro estágio. Você deve sair dele um pouco desorientado. Se sair com uma lista organizada de “lugares para colocar IA”, fez errado.
Estágio 2: Projetar — Engenharia de Valor e Jornadas Críticas do Usuário
Este é o estágio que considero a verdadeira joia do framework, e também o mais subestimado no discurso sobre IA agentica. O estágio dois faz duas coisas: força você a quantificar o valor de negócio de cada projeto agentico potencial antes de construir, e faz mapear as Jornadas Críticas do Usuário — as CUJs — que o sistema agentico precisa navegar.
Engenharia de valor, em linguagem simples, é a disciplina de recusar construir a próxima coisa em IA até que você possa responder a três perguntas: o que exatamente isso muda para o negócio em dólares ou horas, quem é o humano responsável por esse resultado hoje, e o que acontece com o trabalho desse humano quando o agente faz isso bem. Se não conseguir responder às três com detalhes, o projeto volta para a fila. Não é priorizado só porque alguém no offsite da liderança disse “IA” com convicção.
Sendo honesto — este é o estágio em que pessoalmente mais falhei. Adoro construir. Costumo racionalizar o valor depois. O framework parte do princípio, corretamente, de que a maioria de nós faz isso, e incorpora a disciplina antes de qualquer linha de código ser escrita.
A parte das Jornadas Críticas do Usuário é o complemento operacional. Uma CUJ não é uma lista de funcionalidades. É o caminho específico que um humano real (ou um agente em nome de um humano) percorre para realizar algo importante. Você mapeia a jornada, marca cada ponto de decisão, cada dependência de dados, cada lugar onde o processo atual quebra ou transfere para outro sistema. Depois, pergunta quais desses passos um agente pode assumir de ponta a ponta e quais ainda exigem um humano no loop.
Isso importa porque a maioria dos projetos “agenticos” falha não porque o modelo é ruim, mas porque ninguém mapeou a jornada. O agente trava no passo 4 porque os dados do passo 3 estão em um sistema inacessível para ele. Ou o passo 6 exige uma aprovação que ninguém documentou. Ou a transferência entre agente e humano acontece por um canal do Slack monitorado apenas por um gerente específico. O mapeamento das CUJs revela tudo isso antes de construir, o que é cerca de 200x mais barato do que descobrir depois.
Estágio 3: Construir — Prototipagem No-Code com as Ferramentas Certas
O terceiro estágio é onde fica divertido, e onde o Google faz uma aposta bastante ousada. A posição do framework é que o protótipo deve ser construído pela equipe multifuncional que mapeou a CUJ — não repassado para um time de engenharia interpretar. O objetivo de usar ferramentas no-code como Google AI Studio e Gemini Enterprise neste estágio é manter as pessoas mais próximas do processo no comando enquanto o sistema toma forma.
Esta parte do curso é direcionada diretamente para gerentes de produto de IA — o enquadramento explícito é que um PM deve ser capaz de construir um protótipo agentico funcional sem abrir um único ticket de engenharia. Tenho sentimentos mistos sobre isso. Por um lado, já vi muitas iniciativas de IA corporativa morrerem no abismo entre a especificação do PM e a interpretação do engenheiro. Permitir que o PM construa o protótipo diretamente fecha esse abismo, e o ganho de velocidade é real.
Por outro lado, protótipos no-code têm o hábito de virar sistemas de produção por acidente. Aquilo que foi construído em três dias “só para provar o conceito” é apresentado à liderança, a liderança adora, e de repente está rodando em produção com todo o rigor arquitetural de um hackathon de sábado à tarde. Já vi isso acontecer com fluxos do Zapier, apps do Bubble, automações do Notion. Não há motivo para que protótipos de IA agentica sejam exceção.
A disciplina do framework no terceiro estágio é o que o salva. Protótipos são explicitamente definidos como descartáveis — prova de conceito, não produção. O objetivo do estágio é validar que a CUJ se sustenta quando um agente realmente a executa, que os números da engenharia de valor estavam corretos e que as transferências humanas funcionam. Uma vez validado, você avança para o estágio quatro, onde o sistema de produção real é construído com a arquitetura, segurança e observabilidade que o ambiente produtivo exige.
Estágio 4: Escalar — O Estágio que Ninguém Quer Discutir
O curso é honesto sobre algo: o estágio quatro — realmente escalar e operacionalizar sistemas agenticos em uma empresa — é o estágio com o playbook menos maduro. Todos ainda estão descobrindo como fazer. As empresas que conseguiram (e não são muitas) tratam como um programa de vários trimestres envolvendo times de plataforma, frameworks de governança, observabilidade de agentes e uma política clara para quando a autoridade de decisão do agente deve ser transferida para um humano.
Os dois personagens que Clara usa para tornar isso concreto são Beth, chefe de estratégia de uma rede varejista fictícia chamada Symbol Mart, e Tomo, o líder técnico. O trabalho de Beth é manter a transformação agentica alinhada ao valor de negócio e garantir que os projetos priorizados realmente movam os indicadores que deveriam. O trabalho de Tomo é garantir que os sistemas construídos sejam seguros, pragmáticos e escaláveis o suficiente para sobreviver à transição do protótipo para a implantação empresarial.
A dupla importa. O motivo pelo qual a maioria das iniciativas de IA agentica falha no estágio quatro é que são de responsabilidade exclusiva de uma dessas duas pessoas. Liderança só da Beth produz belos slides e protótipos que nunca escalam. Liderança só do Tomo produz sistemas robustos que automatizam coisas que ninguém realmente precisava automatizar. A principal afirmação operacional do framework é que a taxa de sucesso no estágio quatro é função de quão bem esses dois papéis estão acoplados em toda a transformação.
Esse é o framework. Agora vou contar onde acredito que ele se adapta.
O Que Realmente Funciona e O Que Acho Superdimensionado
Quero ser cuidadoso aqui, porque é fácil ler um framework do Google e tanto reverenciá-lo quanto descartá-lo. Ambas as reações são preguiçosas. Aqui está o que realmente penso após trabalhar com ele.
A mudança de mentalidade da fase Discover é a peça mais importante — e a mais fácil de pular. Quase ninguém faz isso corretamente. Quase todo mundo entra na IA agente carregando o modelo de processo atual e encaixando agentes nas etapas já existentes. O custo de pular o exercício do “e se” é passar um ano construindo agentes que apenas aceleram um processo fadado ao fracasso.
A disciplina de engenharia de valor da fase Design é o elemento que estou adotando integralmente e aplicando ao meu próprio trabalho, inclusive em projetos que não têm nada a ver com IA agente. O princípio se generaliza — quantifique o valor antes de construir, nomeie o humano cujo trabalho será alterado e recuse-se a aprovar o projeto até conseguir fazer ambos. Provavelmente vou escrever um post separado só sobre isso, porque merece.
O mapeamento CUJ está correto em espírito, mas é um pouco pesado na prática para qualquer coisa abaixo do nível corporativo. Se você é uma startup de cinco pessoas ou um construtor solo, não precisa de um documento CUJ formal. Você precisa percorrer o fluxo de trabalho em um quadro branco e marcar as transferências. A formalidade do framework escala conforme o tamanho da organização. Use o princípio, dimensione o artefato.
A ênfase no no-code da fase Build é adequada para protótipos e perigosa para produção. Trate isso de acordo. O protótipo é construído rapidamente no Google AI Studio, Gemini Enterprise ou qualquer que seja seu stack. O sistema de produção é construído com um processo de engenharia real. Não deixe o demo virar o deployment.
A fase Scale é onde o framework é honesto sobre seus próprios limites, e respeito isso. Ninguém tem um playbook para transformação agente em escala corporativa ainda. O que o framework oferece é o formato organizacional correto — o pareamento Beth e Tomo, o alinhamento de valor, o pragmatismo técnico. Os detalhes, você terá que descobrir na prática.
O que o framework não diz explicitamente, mas provavelmente deveria: uma quantidade significativa dessas transformações vai fracassar. Não porque o framework esteja errado, mas porque a mudança organizacional necessária para colocá-lo em prática é realmente difícil. Permitir que um agente assuma um processo de ponta a ponta significa que o trabalho de alguém vai mudar. Às vezes essa mudança é um enriquecimento — a pessoa passa de executar o trabalho para supervisionar o sistema. Às vezes é eliminação. O framework é um documento de estratégia, não um documento de gestão de mudança. Você vai precisar dos dois.
O Que Isso Significa Se Você Está Construindo Agora
Se você é desenvolvedor, a mudança mais útil é parar de perguntar “qual tarefa posso automatizar com um agente” e começar a perguntar “qual processo posso entregar a um sistema autônomo”. Pergunta diferente, arquitetura diferente, teto de valor diferente. Os agentes que você constrói sob a segunda pergunta valem aproximadamente 10x mais do que os que você constrói sob a primeira, na minha experiência.
Se você é gerente de produto ou fundador, a disciplina de engenharia de valor é a prática de maior alavancagem que você pode adotar neste trimestre. Antes de aprovar o próximo recurso de IA, escreva em um parágrafo: o que muda especificamente para o negócio quando isso funciona, quem é o responsável humano por esse resultado hoje e o que acontece com o trabalho dessa pessoa quando o agente executa bem a tarefa. Se você não consegue escrever esse parágrafo, o recurso não está pronto para ser desenvolvido.
Se você administra um negócio de e-commerce, a mudança para o comércio agentico não é um problema para 2030. É um problema para 2026. O fato de 70% dos consumidores se sentirem confortáveis com compras realizadas por agentes significa que o agente de compras que vive dentro do ChatGPT ou do Gemini vai decidir se o seu produto sequer aparecerá no conjunto de consideração, muito antes de o cliente digitar o nome da sua marca. Isso tem implicações para a estrutura dos dados do produto, para a acessibilidade via API, para a forma como você descreve seus produtos de maneira legível por máquinas. Se você está construindo a página de produto de hoje para o consumidor humano de amanhã, está construindo para um comprador que está sendo silenciosamente substituído.
Se você é líder em uma empresa, a dupla Beth-e-Tomo é o ponto a internalizar. Encontre sua Beth. Encontre seu Tomo. Faça com que eles sejam co-responsáveis pela transformação. Se qualquer um deles faltar ou for deixado de lado, o programa vai produzir algo — apresentações ou sistemas — mas não vai produzir transformação.
Uma Observação Sobre a Promessa do No-Code
Há um ponto na abordagem do curso sobre o qual quero fazer uma ressalva. A promessa de que PMs de IA podem construir sistemas agentic de qualidade de produção sem engenheiros é, na minha avaliação honesta, parcialmente verdadeira e perigosamente sedutora.
A parte parcialmente verdadeira: PMs podem, sem dúvida, criar protótipos que comprovam o CUJ, validam o valor e demonstram o fluxo de trabalho. Isso é real e representa um avanço significativo. A parte perigosamente sedutora: o abismo entre um protótipo funcional e um sistema de produção que lida com segurança, escala, recuperação de erros, observabilidade, compliance e os casos extremos que surgem na hora 73 de operação contínua é enorme. É nesse abismo que a engenharia atua. O no-code não elimina esse espaço. Ele acelera o protótipo, o que é ótimo. Trate-o dessa forma.
A maneira correta de interpretar a ênfase do Google em no-code não é "engenheiros não são mais necessários para IA agentic." É "a fase de prototipagem não precisa mais esperar pela disponibilidade da engenharia, o que significa que mais ideias podem ser validadas rapidamente, e, assim, a capacidade de engenharia é direcionada para os protótipos que realmente provaram seu valor." Essa é uma afirmação muito mais modesta, e é nela que realmente acredito.
O Que Estou Fazendo Diferente Esta Semana
Voltando à discussão de domingo de manhã com a qual comecei — aquela em que percebi que havia criado sete agentes e zero fluxos de trabalho — passei ontem redesenhando um deles.
O scraper de preços da concorrência está se tornando um sistema de preços da concorrência. Ele ainda coleta os dados. Mas agora ele avalia se a diferença de preço importa, considerando nosso piso de margem, elabora uma proposta de ajuste de preço, envia para mim uma solicitação de aprovação em uma linha com o raciocínio anexado e, após a aprovação, aplica a mudança e monitora a conversão por 72 horas antes de manter ou reverter a alteração. O trabalho que eu fazia — analisar os dados, decidir, executar, monitorar — agora está estruturado pelo sistema. Meu papel é aprovar ou rejeitar a proposta. Isso é um processo, não uma tarefa.
Levei cerca de quatro horas para redesenhá-lo. Estimo que isso vai me economizar quatro horas por mês para sempre. A versão com agente me poupava quarenta minutos por semana. A versão com fluxo de trabalho me poupa meio dia. Mesmo modelo, mesmos dados, mesmas ferramentas — a diferença está na pergunta feita na etapa de design.
É para isso que o framework realmente serve. Não para criar apresentações melhores sobre estratégia de IA. Mas para fazer você se perguntar algo diferente no momento em que toda a arquitetura do que você constrói é decidida.
Escolha uma coisa nesta semana que você já “IA-ificou” como tarefa. Faça a pergunta do “e se”. Pergunte se um sistema agente poderia assumir todo o processo em vez de apenas uma parte dele. Se a resposta for sim, redesenhe. Se a resposta for não, pergunte por quê — porque esse “não” geralmente aponta para a restrição real, e a restrição real normalmente é uma transferência manual que ninguém se preocupou em mapear.
Isso, mais do que qualquer framework, é o verdadeiro movimento.
Perguntas Frequentes
Qual é a diferença entre um agente de IA e um sistema de IA agêntico?
Um agente de IA executa uma única tarefa; um sistema de IA agêntico conduz todo um processo de forma autônoma, abrangendo múltiplas etapas, decisões e repasses. O agente é uma ferramenta dentro de um fluxo de trabalho ainda humano. O sistema agêntico substitui o próprio fluxo de trabalho. Para uma distinção mais aprofundada com exemplos, consulte a seção acima sobre agentes versus fluxos de trabalho.
Quais são as quatro etapas do Framework de Transformação de IA Agêntica do Google?
As quatro etapas são Descobrir (mudança de mentalidade do estado atual para o que é possível), Projetar (engenharia de valor mais mapeamento da Jornada Crítica do Usuário), Construir (prototipagem sem código com ferramentas como Google AI Studio e Gemini Enterprise) e Escalar (operacionalização de sistemas agênticos em toda a empresa). A ordem importa — pular a etapa Descobrir é o erro mais comum.
O que é comércio agêntico e por que isso será relevante em 2026?
Comércio agêntico é o e-commerce realizado por agentes de IA atuando em nome de compradores humanos — uma experiência de compra "zero clique" em que o agente descobre, avalia e compra sem que o usuário precise visitar um site. A eMarketer projeta US$ 20,9 bilhões em e-commerce impulsionado por plataformas de IA em 2026, cerca de 4 vezes mais que em 2025, com a McKinsey prevendo US$ 1 trilhão até 2030.
O que é uma Jornada Crítica do Usuário (CUJ) no design de IA agêntica?
Uma Jornada Crítica do Usuário mapeia o caminho específico de ponta a ponta que um usuário (ou agente agindo em seu nome) percorre para alcançar um resultado significativo, marcando cada decisão, dependência de dados e repasse. O mapeamento da CUJ revela as lacunas operacionais que inviabilizam projetos agênticos — acesso a dados ausente, aprovações não documentadas, repasses quebrados — antes mesmo de qualquer linha de código ser escrita.
Gerentes de produto de IA podem construir sistemas agênticos sem engenheiros usando ferramentas no-code?
Parcialmente. PMs podem criar protótipos validados usando ferramentas como Google AI Studio e Gemini Enterprise, o que representa um avanço significativo em velocidade. Mas transformar um protótipo funcional em um sistema de produção que lide com segurança, escala, recuperação de erros e observabilidade ainda exige engenharia. O enquadramento correto é prototipagem mais rápida, não substituição da engenharia.
Vamos Trabalhar Juntos
Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Eu posso ajudar.
- Fiverr (soluções e integrações personalizadas): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções corporativas): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
