Assisti recentemente, no StartSe AI Festival 2026, a uma palestra que continuou na minha cabeça por dias. No palco estava Isabella Piratininga, Diretora de Tecnologia e Inovação do iFood, e o tema era a construção de produto agêntico em escala, contada a partir do caso do Ailo, o assistente conversacional do iFood.
Quero ser transparente logo de início: este texto é a minha leitura do que ouvi ali, não uma cobertura nem uma transcrição. É o que eu, como desenvolvedor, anotei e resolvi destrinchar para outros desenvolvedores. Escolhi escrever sobre isso por um motivo simples: o iFood provavelmente roda uma das maiores operações de agentes em produção no Brasil hoje, e ouvir quem coloca isso de pé todos os dias, com usuários reais e SLA para cumprir, vale mais do que a maior parte do que se fala sobre agentes por aí.
Para dar a dimensão do que está em jogo: o iFood já opera mais de 10 mil agentes ativos internamente, soma mais de 200 mil agentes no atendimento, processa mais de 180 milhões de pedidos por mês, atende mais de 65 milhões de usuários ativos e conecta mais de 500 mil estabelecimentos parceiros. Em escala assim, agentes deixam de ser experimento e passam a ser infraestrutura de produção. E é por isso que os princípios abaixo merecem atenção de desenvolvedores, qualquer que seja a sua stack.
A pergunta que abre tudo
Tudo começou com uma provocação que, para mim, foi o melhor momento: quanto do seu produto, hoje, foi desenhado de fato para mudar o comportamento do usuário?
Repare que a provocação é sobre comportamento, não sobre interface e nem sobre modelo. E comportamento demora para mudar. Praticamente todo mundo está construindo agente, mas quase ninguém está construindo a noção desse tipo de produto. A tecnologia deixou de ser o gargalo, porque os modelos já entregam muita coisa. O problema difícil migrou de lugar. Ele agora está em mudar o comportamento de quem usa, e também o dos times que constroem o produto.
A consequência prática para desenvolvedores é imediata: parar de medir progresso pela quantidade de features de IA entregues e começar a medir pela mudança de comportamento que elas de fato produzem.
A diferença entre produto generativo e produto agêntico
Antes dos princípios, vale uma distinção que considero o ponto de partida de qualquer decisão de arquitetura nesse espaço.
Um produto generativo é aquele em que você dá um input, pede uma coisa e espera uma resposta. O loop é curto, a interação é direta e quase tudo acontece em tempo real. Se a resposta não veio boa, você pergunta de novo. Um chatbot simples vive nesse mundo.
Um produto agêntico funciona por delegação. Você não pede e espera: você entrega uma tarefa e confia que ela será executada. E é aqui que a coisa muda de figura, porque toda a interação que acontece por trás, a quantidade de loops, as decisões intermediárias, nada disso é transparente para o usuário. A superfície de falha de um produto agêntico tende a ser bem maior que a de um chatbot. Quando um chatbot erra, você reformula a mensagem e tenta de novo. Quando um agente erra no meio de um fluxo de várias etapas, o estrago é proporcionalmente maior. Um exemplo concreto: um agente pessoal chamado Tim mandou um e-mail errado para a pessoa errada e quebrou um fluxo de comunicação. Multiplique esse tipo de erro pela escala do iFood e fica claro por que essa distinção precisa estar resolvida desde a primeira linha de código.
Vale ser honesto sobre outro ponto: o agente 100% autônomo, que executa tudo de ponta a ponta sem intervenção, ainda não é realidade. Não importa qual modelo você escolha. Sem tratar regras, sem dar contexto e sem ensinar o agente a parar na hora certa, ele não chega lá. Construir produto complexo esperando autonomia total é uma boa receita para criar frustração, inclusive a sua.
Os cinco princípios que guiam a construção
São cinco princípios, e cada um deles tem uma tradução direta para o trabalho de desenvolvimento.
1. Confiança
O princípio se resume em uma frase direta: a confiança se constrói nos pequenos momentos. Antes de tentar algo grandioso, você precisa acumular pequenos acertos, porque a chance de errar no grandioso é alta, e quando você perde a confiança de um usuário, normalmente perde esse usuário de vez, e ele dificilmente volta.
No código, confiança deixa de ser um conceito de produto e passa a ser uma propriedade de engenharia. Ela se traduz em escopo estreito e confiável antes de escopo amplo e instável, em degradação graciosa quando o agente não tem certeza, e em previsibilidade de comportamento entre execuções. Um agente que acerta todas as tarefas de um conjunto pequeno constrói mais confiança do que um agente que acerta 70% de tudo.
2. Custo
IA ainda é uma tecnologia cara, e não adianta fingir o contrário. O iFood monitora consumo de token e custo de chamada, e isso continua no painel de observabilidade. Mas o ponto que importa é uma mudança de lente: o que pesa, na visão de produto, é o custo real por tarefa concluída. É a tarefa bem feita que resolve o problema do usuário. Contar tokens economizados, isoladamente, não resolve o problema e não evolui o seu agente.
Isso muda a instrumentação de forma concreta. Não basta medir custo por chamada de modelo. É preciso atribuir custo à tarefa inteira, do início até a conclusão, incluindo todos os passos intermediários e as repetições. E é preciso cruzar esse custo com o resultado, porque uma resposta barata que não resolveu o problema do usuário não é barata: ela volta como retrabalho, como suporte ou como um usuário a menos. É FinOps aplicado a agente, com a unidade de medida certa.
3. Determinismo
Esse é o princípio que mais conversa com a cabeça de desenvolvedores. No começo, o time do iFood olhava o desenvolvimento de agente como se tudo precisasse passar por um LLM. E não é assim que funciona. Se alguém chega no iFood e diz “quero refazer meu último pedido”, não é preciso reasoning sofisticado para resolver isso. É uma operação determinística.
A lição é que a engenharia básica continua valendo, e identificar quais etapas precisam de raciocínio do modelo e quais precisam apenas de código previsível qualifica o seu produto. Fazer isso não rebaixa o agente, apenas coloca a tecnologia no lugar certo. Na prática, isso desenha uma camada de orquestração e roteamento: o LLM passa a ser uma ferramenta entre várias, acionada quando o problema realmente exige interpretação, enquanto os caminhos determinísticos seguem determinísticos. O ganho é triplo, porque você reduz custo, reduz latência e reduz superfície de falha de uma vez só.
4. Evals
Avaliação de agente é assunto conhecido, mas há um recorte que vale repetir. Numa dinâmica comum de chatbot, você olha a entrada e a saída. Isso continua sendo necessário. Mas o valor real, na construção de um produto agêntico, está em olhar o meio.
É no meio que você aprende. Quantas interações o agente precisou, quantos passos ele deu para chegar à conclusão, qual foi o custo daquele caminho, e, principalmente, se ele entendeu o momento em que não dava mais para agir sozinho e era hora de perguntar ao usuário. Traduzindo para o código: instrumentar a trajetória inteira, não só as pontas. Logar cada passo, cada chamada de ferramenta, cada ponto de decisão, e avaliar esse percurso. Sem visibilidade do meio, não há informação para evoluir o produto, e o time acaba tentando consertar no escuro.
5. Onboard
O quinto princípio é o onboard, com uma ressalva importante: não se trata do onboarding tradicional, aquele da animação que mostra o produto ou do tooltip avisando que ali tem um agente de IA. O onboard de um produto agêntico é o trabalho de garantir os pequenos acertos de forma consistente e frequente, e de comunicar valor até o usuário viver um momento em que a experiência claramente funcionou e resolveu o problema dele.
A consequência técnica desse princípio é o que mais interessa aqui. Tratar IA como uma feature qualquer dentro de um produto qualquer não constrói esse reconhecimento. O agente precisa se comportar de forma consistente entre execuções, precisa saber a hora de perguntar em vez de agir, e precisa comunicar o que fez. Consistência de comportamento, nesse contexto, é uma propriedade de engenharia: depende de como você desenha o controle do agente.
O agente como nova interface do produto
Se eu tivesse que escolher a ideia mais importante de tudo isso, seria esta: a construção de um produto agêntico não é um roadmap de feature. O próprio time do iFood construiu a primeira versão do Ailo como feature, inclusive na arquitetura e na infraestrutura, e está reescrevendo, e vai reescrever de novo se descobrir que algo não funciona.
O enquadramento aqui é o de uma replataformização. A provocação é partir do princípio de que essa tecnologia sempre existiu e perguntar: o que o seu produto se torna a partir daí? Os agentes vão passar a ser a nova interface de interação, e isso é uma mudança de arquitetura, não um item de backlog.
O Ailo é o exemplo concreto desse processo. Ele já está em produção para uma parcela da base, com crescimento orgânico, disponível inclusive pelo WhatsApp. Quase 2 milhões de usuários já tiveram acesso, e ele tem cerca de 200 mil usuários ativos por mês. Em alguns fluxos, fazer um pedido pelo Ailo chega a ser 50% mais rápido do que pelo aplicativo tradicional. E um detalhe diz muito sobre a maturidade da operação: o Ailo foi colocado para teste rodando ao vivo, em produção, sem nenhum preparo especial do time, e não como uma demo ensaiada.
Vale registrar também que nada disso foi uma história fácil. O iFood investe em inteligência de dados desde 2018, e em 2024 mais de 90% da empresa já usava assistentes de IA, apoiada por uma plataforma interna, o Toqan. Os primeiros feedbacks do Ailo foram duros, com usuários frustrados por respostas que tentavam ser mágicas e personalizadas demais com pouca informação. O aprendizado foi justamente o do primeiro princípio: começar pequeno.
Oportunidades para desenvolvedores
A leitura otimista de tudo isso é que o diferencial mudou de lugar e ficou mais acessível. Se a tecnologia não é mais o gargalo, o que separa um produto agêntico bom de um ruim é julgamento de engenharia e de produto. É saber onde aplicar o modelo e onde aplicar código determinístico, é instrumentar a trajetória, é desenhar para confiança. Esse é exatamente o tipo de coisa que um desenvolvedor experiente sabe fazer, e que não se resolve trocando de modelo.
Há uma oportunidade clara na camada de plataforma. O iFood usa o Toqan como camada interna para a empresa inteira criar agentes, e essa necessidade de padronizar orquestração, observabilidade e avaliação vai aparecer em qualquer organização que leve agentes a sério. Quem souber construir essa camada vai ser muito requisitado. E há a oportunidade do design determinista como prática: equipes que tratam o LLM como uma ferramenta entre várias, e não como o centro de tudo, entregam produtos mais baratos, mais rápidos e mais estáveis.
Os riscos que vêm junto
O outro lado é um inventário honesto de riscos, e vale listá-los com a mesma clareza.
- Superfície de falha ampliada. Em um fluxo de várias etapas, um erro no meio se propaga e o impacto final é grande.
- Custo fora de controle. Acontece quando você mede tokens em vez de custo por tarefa concluída e descobre tarde demais que cada tarefa resolvida saiu cara.
- Fragilidade da confiança. Um único erro grave pode custar o usuário para sempre, o que eleva o preço de cada falha em produção.
- Delegação excessiva. Construir produto complexo esperando autonomia total de um agente que ainda não entrega isso.
- Dívida de arquitetura. Tratar o agente como feature cobra a conta depois na forma de reescrita, exatamente como o iFood está fazendo com o Ailo.
- Cegueira de avaliação. Olhar só entrada e saída e não enxergar onde o agente de fato quebra.
- Mágica cedo demais. Tentar entregar uma experiência hiperpersonalizada antes de ter acumulado os pequenos acertos que sustentam essa promessa.
O que eu levo disso
Fico com uma convicção reforçada: construir com agentes, feito do jeito certo, tem menos a ver com escolher o modelo da moda e mais a ver com disciplina de engenharia. Os cinco princípios, confiança, custo, determinismo, evals e onboard, são todos, no fundo, decisões de arquitetura e de instrumentação. Nenhum deles depende de um modelo específico.
E volto à provocação do começo, porque ela resume bem o que está em jogo. Colocar um agente no produto é a parte fácil da decisão. A parte difícil, e a que de fato importa, é o desenho: o seu produto foi construído para mudar o comportamento de quem usa, e a engenharia que sustenta essa mudança com confiança foi construída junto? O iFood está respondendo a essa pergunta em produção, na escala dele, e errando e reescrevendo no caminho. Para desenvolvedores, essa é a lição mais útil de tudo: ninguém tem o mapa pronto, e a vantagem é de quem tem disciplina para construir, medir e iterar.
