A maior parte dos projetos de IA que eu vejo morrer não morre por causa do modelo. Morre antes. Morre porque ninguém decompôs a operação.
Em 2024 eu entrei numa mineradora em Minas Gerais pela primeira vez. Eles tinham me chamado porque queriam "automatizar com IA" o processamento de notas fiscais dos fornecedores. Recebem centenas todo mês. Tinha um time inteiro digitando código de produto, abrindo o Protheus, conferindo, gerando pedido de compra, emitindo NF de saída. Manualmente. Em 2024.
A primeira coisa que eu fiz não foi código. Foi sentar com a equipe operacional e desenhar onde estava cada decisão. Não cada tarefa. Cada decisão. Existe uma diferença e essa diferença é tudo.
Tarefa não é decisão
Tarefa é "abrir o Protheus, digitar o código X, salvar". Software automatiza tarefa desde os anos 80. Já temos RPA pra isso há décadas.
Decisão é "esse item da nota corresponde a qual código do catálogo? Se eu não tiver certeza, quem revisa? Em quanto tempo? Sob qual regra?". É aí que o ser humano gasta a maior parte da semana. E é aí que IA finalmente entra.
A grande virada de 2024-2026 não é que ficou mais barato escrever código. É que a decisão, pela primeira vez, entrou no escopo do que pode ser automatizado. Modelo de linguagem grande faz isso bem. Faz raciocínio sobre contexto, faz julgamento sobre ambiguidade, faz match semântico. Tudo coisa que antes só humano fazia.
Se você joga um modelo em cima de uma operação que não foi decomposta, ele faz exatamente o que o humano fazia antes. Mal. Lento. Sem governança.
Esse é o ponto onde a maioria das consultorias de IA naufraga. Eles entregam um chatbot. Entregam um wrapper de OpenAI conectado a um banco de dados. Entregam uma "automação". E o cliente em três meses tá com um sistema rodando em produção que ninguém sabe explicar, que falha sem aviso, que nenhum funcionário confia.
A empresa vira um grafo
Eu trabalho de um jeito diferente. Antes de escrever uma linha de código, eu faço a empresa virar um diagrama. Não um organograma. Um grafo de decisões.
Esse grafo tem três partes: as decisões que se repetem (o coração da operação), as informações que cada decisão consome (de onde vem, em quanto tempo, com qual confiabilidade), e os agentes humanos que hoje fazem cada decisão. Quando esses três estão mapeados, fica óbvio onde a IA tem alavancagem real e onde ela vai ser teatro.
Geralmente o desenho não vai pra todo lado. Vai pra dois ou três pontos. Esses são os pontos onde a operação inteira destrava se você acertar. Os outros 70% da operação continuam fazendo o que sempre fizeram, e tá ótimo. IA não precisa estar em tudo. Precisa estar nas decisões certas.
O caso da Toledo
Foi assim que a Toledo virou. A gente identificou que o nó da operação não era a digitação. Era a classificação. Decidir "essa nota corresponde a qual produto do nosso catálogo". É uma decisão semântica, depende de contexto histórico, depende de fornecedor, depende de variações na nomenclatura.
Humano demora horas. Modelo bem orquestrado faz em segundos com confiança alta na maioria dos casos, e quando não tem confiança, escalona pra humano de forma deliberada. Isso é diferente de "automatizar a digitação". É outra categoria de sistema.
A arquitetura que sai disso não é um chatbot. É uma malha. Tem agente que escuta e-mail. Tem agente que parseia a nota. Tem agente que classifica. Tem agente que gera pedido de compra. Tem agente que emite NF de saída. Cada um faz uma coisa bem, cada um tem permissões claras, cada um deixa rastro auditável. Eles coordenam entre si. Isso é arquitetura.
Discovery não é fase. É a base.
Quando o cliente pergunta "quanto tempo até rodar", a resposta verdadeira não é "duas semanas". É "depende do quanto a operação foi decomposta". Se a operação tá clara, a construção é rápida. Se a operação não tá clara, nenhum tempo de construção é suficiente, porque você vai estar construindo a coisa errada.
Por isso eu separo Discovery de Build. Discovery é onde a arquitetura é feita. Build é onde ela vira código. Sem Discovery, Build é loteria. Com Discovery, Build é execução.
Tem uma analogia que ajuda. Pense em construir um prédio. Ninguém em sã consciência pede pro engenheiro "começa a construir e a gente vê o desenho depois". Mas em software, especialmente em software com IA, o cliente médio aceita exatamente isso. Aceita porque a indústria treinou ele a aceitar. "Vamos rodar um piloto", "vamos fazer um POC", "vamos iterar". Tudo isso é jeito de não fazer arquitetura.
Iteração é boa. Iteração sem arquitetura é só estar perdido com velocidade.
Menos agentes, não mais
Tem outra coisa que eu aprendi e que demorou pra ficar claro. A arquitetura agêntica boa não é a que tem mais agentes. É a que tem menos. Cada agente custa coordenação. Cada interface entre agente e agente é uma fonte de falha. O instinto de "vou criar um agente pra cada coisa" leva a sistemas frágeis. O instinto certo é "qual o menor número de agentes que cobre essa operação com a separação de papéis necessária pra auditabilidade".
Geralmente é menos do que parece. Toledo tem sete agentes. Pra processar centenas de notas por mês com confiabilidade de produção. Sete. Não setenta.
O ERP fica. Os agentes orbitam.
Outra coisa: os agentes não substituem o ERP. O ERP é a fonte de verdade. Os agentes orbitam ele. Decidem, decidem com base no que tá no ERP, escrevem de volta no ERP. Isso parece óbvio mas a indústria insiste em "replatformar tudo". A maioria das operações enterprise já investiu décadas em ERP, em CRM, em sistema de produção. Não faz sentido jogar isso fora. Faz sentido orquestrar em cima.
Essa é a outra parte da arquitetura: decidir o que fica, o que vai e o que orbita. Tem time de IA que entra querendo reescrever tudo. Tem time de IA que entra querendo só vender API. Os dois extremos quebram. O meio é onde mora a engenharia. O ERP fica. As decisões automatizam. A interface humana muda.
O humano sobe um nível
Sobre a interface humana, uma observação que vale por toda essa conversa. Sistema agêntico bem feito não tira o humano. Move o humano. Antes ele digitava pedido. Agora ele governa o sistema que digita pedido. É um trabalho mais qualificado. Mais escasso. Mais bem pago. Empresa que faz isso direito não dispensa pessoas, sobe o nível delas.
Quem fica preocupado com isso é porque tá pensando em automatizar tarefa, não em redesenhar operação. Tarefa automatiza, gente sobra. Operação redesenha, gente vira ativo escasso.
A pergunta que abre toda Discovery
Eu termino com uma pergunta que eu faço pro cliente toda vez no primeiro encontro. "Se você pudesse desenhar a sua empresa do zero hoje, com tudo que existe agora, ela teria essa cara?". Nove em cada dez respondem que não. A cara que ela tem foi um acúmulo histórico. Foi software comprado em 2008, processo escrito em 2014, time montado em 2019. Faz sentido em camadas. Não faz sentido como sistema.
Arquitetura antes do código é o trabalho de tirar a empresa desse acúmulo e devolver pra ela uma forma de sistema. Coordenada. Auditável. Escalável. Resiliente a mudança de negócio. Não é um projeto de seis meses. É a fundação que torna possível todo projeto de IA que vem depois.
A gente da Forya cobra antes pelo Discovery. Não é por capricho. É porque a maior alavanca da operação tá ali. Quando o Discovery é bom, o Build é uma execução técnica. Quando o Discovery é ruim, o Build é a desculpa do prejuízo.
Pergunte pela arquitetura. Não pergunte pelo prazo. Não pergunte pelo modelo. Pergunte pela arquitetura.
Se tem uma coisa que eu queria que todo CEO entendesse antes de assinar com qualquer agência de IA, é isso. Se a resposta for vaga, troque de agência. A clareza da arquitetura é o sinal antecipado mais forte do quanto o sistema vai funcionar.
Isso é o que a gente faz. Antes do código. Por isso o código que vem depois funciona.