Em quase todo time que começa a construir produto com IA ha um momento curioso. A primeira versão funciona bem o bastante para animar todo mundo. O modelo responde com fluidez, entende o pedido, escreve bonito, às vezes até impressiona mais do que deveria. A sensação é de que a parte difícil ficou para trás.
Ela não ficou.
O que costuma acontecer depois é quase cômico, se não fosse caro. Entra documento mal formatado. O usuário faz uma pergunta ambígua. A ferramenta externa demora. A conversa fica longa. O sistema consulta uma base desatualizada. O custo sobe sem ninguém perceber direito por quê. A resposta continua bem escrita, o que torna tudo um pouco pior, porque erro elegante engana mais do que erro tosco.
É nessa hora que muita gente percebe que não está construindo apenas uma interface em cima de um modelo. Está construindo um sistema. E sistema tem memória, contexto, permissão, latência, estado, observabilidade, teste, regressão. Ou deveria ter.
Esse é o ponto que separa um brinquedo inteligente de um app com IA que aguenta uso de verdade.
O modelo não é o produto inteiro
Vale insistir nisso porque esse equívoco aparece o tempo todo. O modelo é uma peça muito poderosa, mas ele não resolve sozinho o desenho do produto. Um bom app com IA nasce quando alguém entende que a resposta final depende menos de uma frase genial no prompt e mais da arquitetura invisível que cerca essa frase.
Pensa num assistente interno para uma equipe de operações. Na demo, ele responde perguntas sobre processos, encontra políticas, resume incidentes e sugere próximos passos. Parece excelente. Só que, no uso real, esse mesmo assistente precisa saber qual política está valendo hoje, qual documento o usuário tem permissão para ver, quando deve consultar um sistema externo, quando deve admitir incerteza, quando precisa pedir confirmação humana, e quando é melhor não improvisar.
É aí que a conversa fica interessante. Porque construir app com IA deixou de ser simplesmente pedir para o modelo gerar texto. Hoje, o trabalho parece mais com montar um circuito. Você escolhe que contexto entra, que ferramentas podem ser chamadas, como o histórico é resumido, como o app mede qualidade, de que maneira os erros aparecem para a equipe. Cada uma dessas escolhas muda o comportamento final mais do que muita gente imagina.
Parece detalhe até o dia em que a aplicação começa a responder com segurança sobre algo que ela nunca deveria ter respondido.
Contexto bom não é contexto grande
Esse talvez seja o ajuste mental mais útil para quem está começando ou mesmo para quem já colocou algo em produção, mas ainda está lutando com consistência. Existe uma tentação constante de jogar mais contexto no prompt. Mais histórico, mais documentos, mais instruções, mais exemplos, mais regras, mais tudo. Como se quantidade fosse sinônimo de clareza.
Não é.
Contexto demais confunde, dilui o que importa e abre espaço para o modelo se agarrar ao trecho errado. Contexto de menos deixa lacunas e estimula improviso. O trabalho bonito, e meio artesanal mesmo, está em escolher o que precisa entrar naquela rodada específica da conversa.
Essa etapa merece até mais respeito do que geralmente recebe. Não se trata só de escrever um bom prompt. Trata se de decidir como o estado da aplicação é empacotado para o modelo. A mensagem do usuário sozinha raramente basta. Entra histórico recente, às vezes entra memória resumida, entram trechos recuperados de uma base, entram resultados de ferramenta, entram políticas, entra o objetivo daquela tela, entra o formato de saída esperado.
Quando essa curadoria é bem feita, o sistema parece inteligente. Quando ela é preguiçosa, ele parece volátil. O mesmo modelo que parecia ótimo de manhã fica irreconhecível à tarde, não porque desaprendeu, mas porque o contexto que recebeu mudou de qualidade.
Se o contexto chega bagunçado, a resposta sai bagunçada com uma confiança impressionante.
Recuperar informação não é só plugar documentos
É aqui que RAG entra na conversa com um pouco mais de honestidade. Muita gente trata recuperação de contexto como uma etapa meio burocrática. Sobe os PDFs, gera embeddings, conecta uma busca vetorial e pronto. Na prática, é uma das partes mais sensíveis da arquitetura.
O problema começa na ingestão. Documento corporativo raramente é limpo. Tem tabela quebrada, cabeçalho repetido, versão desatualizada, pedaço irrelevante e trecho que só faz sentido quando visto junto de outro logo acima. Se você fragmenta mal o material, o sistema recupera pedaços tecnicamente próximos da consulta, mas semanticamente fracos. A resposta parece quase certa, o que costuma ser a pior categoria de erro.
Tem um raciocínio simples que ajuda aqui. O objetivo da recuperação não é encontrar qualquer trecho parecido com a pergunta. O objetivo é devolver o melhor contexto possível para que o modelo consiga pensar em cima de informação útil. Isso muda a forma de olhar para chunking, overlap, títulos, metadados, deduplicação, data de atualização, reranking.
Quando alguém pergunta qual política vale para reembolso internacional, você não quer que o sistema puxe um fragmento que contenha as palavras reembolso e viagem perdidas no meio de um documento de 2023. Você quer o trecho certo, na versão certa, com o escopo certo, idealmente acompanhado do cabeçalho que situa aquilo. Esse trabalho parece operacional até o momento em que você percebe que ele responde por uma parte enorme da qualidade percebida.
Tem mais um detalhe que pouca gente leva a sério no começo. Pergunta de usuário quase nunca vem pronta para recuperação. Ela vem mal formulada, abreviada, incompleta, às vezes carregada de contexto implícito. Um sistema melhor costuma reescrever a consulta internamente, expandir termos, considerar sinônimos, aplicar filtros e só então buscar. A etapa de recuperar informação não precisa ser um único passo. Ela pode ser uma pequena cadeia de refinamentos.
Quando isso é bem implementado, o leitor comum chama de app inteligente. O engenheiro reconhece outra coisa. Reconhece disciplina.
Ferramenta boa exige fronteira boa
Uma virada importante acontece quando o app deixa de apenas responder e passa a agir. Consultar agenda, abrir ticket, buscar preço, atualizar CRM, disparar fluxo, classificar documento, chamar web search, pedir dado para outro serviço. Nesse ponto, a aplicação ganha utilidade de verdade. Também ganha superfície de risco.
É sedutor pensar que basta expor as ferramentas para o modelo e deixá lo escolher. Só que ferramenta não é só capacidade. Ferramenta é contrato. Entrada válida, permissão, timeout, erro esperado, comportamento idempotente, escopo permitido, log. Se isso não estiver bem definido, o modelo vira uma espécie de gerente criativo comandando um backstage improvisado.
O ideal é tratar ferramentas como peças determinísticas, pequenas e confiáveis. O modelo decide quando usar. A execução da ferramenta continua sob regras bem concretas. Esse arranjo funciona porque cada lado faz o que sabe fazer melhor. O modelo interpreta intenção, lida com ambiguidade e escolhe o próximo passo. O sistema tradicional valida, executa, audita e devolve resultado estruturado.
Quem já passou por isso sabe como a qualidade sobe quando a ferramenta para de devolver texto solto e começa a devolver dados organizados. O modelo agradece. A depuração agradece mais ainda. Em vez de receber uma frase vaga dizendo que houve um problema, ele recebe um status claro, campos previsíveis, motivo de falha e possibilidade de recuperação.
Esse tipo de engenharia pode parecer menos glamouroso do que mexer no prompt. Curiosamente, é o que mais separa um app utilizável de um app ornamental.
Nem todo app precisa virar um exército de agentes
Esse tema merecia menos hype e mais calma, pois a camada MCP precisa ser boa no app. Multiagentes podem ser excelentes em certos cenários, especialmente quando existem domínios muito distintos, ferramentas muito diferentes ou etapas especializadas demais para caberem num único fluxo mental. Só que também adicionam coordenação, custo, latência, estados intermediários e novas formas de dar errado.
Na prática, muita complexidade que parece pedir vários agentes ainda cabe num desenho mais enxuto com um agente principal, boas ferramentas e um conjunto decente de instruções variáveis. Tem algo muito elegante nisso. Você adia a fragmentação até existir motivo real para fragmentar.
É fácil reconhecer quando um time foi cedo demais para uma arquitetura espalhada. Ninguém entende o que cada agente sabe. Os handoffs ficam nebulosos. O sistema passa a errar na transferência entre etapas, não na etapa em si. Fica lindo no diagrama e mais frágil no comportamento.
Começar com um agente só não é falta de ambição. Em muita situação, é maturidade. Primeiro você prova que o fluxo tem valor, que as ferramentas estão sólidas, que a recuperação de contexto é boa, que os testes capturam regressão. Só depois faz sentido dividir responsabilidades.
Essa ordem poupa energia, e poupa uma quantidade deliciosa de sofrimento técnico.
O app que você não mede vira superstição
Existe um tipo de confiança que aparece cedo demais em times de IA. O produto funciona bem em meia dúzia de exemplos conhecidos, então todo mundo passa a discutir sensação. Está melhor. Está mais esperto. Parece mais preciso. Soa mais natural. A equipe começa a operar por impressões, e impressões são traiçoeiras.
Aplicação com IA pede avaliação contínua. Não apenas porque o modelo pode variar, mas porque todo o resto também varia. A base muda, o prompt muda, a ordem do contexto muda, uma ferramenta muda o schema, um resumo do histórico perde informação importante, a consulta interna para busca é reescrita de outra maneira. Qualquer ajuste pequeno pode produzir regressões estranhas.
Aqui entra uma das práticas mais subestimadas do processo inteiro. Construir um conjunto de casos que represente o trabalho real da aplicação. Perguntas simples, perguntas ambíguas, documentos ruins, consultas maliciosas, entradas incompletas, situações em que o sistema deveria responder, e situações em que deveria recusar ou pedir confirmação. Esse acervo vira uma espécie de espelho do produto.
Não precisa começar sofisticado. Um bom conjunto de exemplos reais já muda o jogo. O importante é sair do terreno da torcida. Quando a equipe mede qualidade de recuperação, fidelidade à base, uso correto de ferramentas, taxa de erro por tipo de tarefa e consistência do comportamento, a conversa muda de nível. O que antes era gosto pessoal vira engenharia.
E isso alivia. Muita ansiedade em app com IA nasce do fato de que ninguém sabe exatamente se melhorou ou só ficou diferente.
Observabilidade é o que impede a loucura silenciosa
Tem uma pergunta que aparece em toda operação séria com IA. Por que o sistema respondeu isso?
Se você não consegue responder, ainda não terminou de construir o produto.
Logs tradicionais ajudam, claro. Mas eles não bastam quando o comportamento depende de contexto montado em tempo real, múltiplas chamadas de ferramenta, decisões intermediárias e cadeias de mensagens. Você precisa ver o caminho. Que contexto entrou, que ferramenta foi chamada, o que voltou, em que momento houve handoff, onde o modelo hesitou, onde uma proteção interveio, onde a latência explodiu.
Quando esse tipo de rastreabilidade existe, debug deixa de ser leitura de borra de café. Você encontra a causa com alguma dignidade. Descobre que o problema não era alucinação pura, e sim um chunk ruim. Ou um timeout mascarado. Ou uma mensagem antiga reaproveitada quando não devia. Ou uma ferramenta generosa demais nas permissões. De repente, comportamento estranho vira bug tratável.
É curioso como essa camada quase sempre entra tarde. O time passa semanas refinando a superfície da experiência e adia justamente a parte que permitiria entender o que a experiência está fazendo por baixo.
Custo e latência também escrevem a experiência
Quase todo mundo aprende isso do mesmo jeito. Em produção, da forma menos romântica possível.
O usuário sente latência antes de entender qualidade. Se a resposta demora demais, a percepção de inteligência cai. Se o app custa demais para responder tarefas simples, o negócio aperta. Não adianta construir uma aplicação brilhante que só funciona financeiramente com tráfego tímido e sessões curtas.
Tem algumas alavancas clássicas aqui. Reaproveitar prefixos estáveis, cachear contexto recorrente, usar modelos mais leves em etapas menores, reservar o modelo mais caro para pontos realmente difíceis, transmitir resposta em streaming quando faz sentido, resumir histórico em vez de empilhar tudo, evitar chamadas de ferramenta desnecessárias, não reexecutar busca quando nada mudou.
Nada disso é truque marginal. É parte da arquitetura. O time que entende isso cedo costuma produzir experiência melhor com menos dinheiro queimado. O time que ignora entra naquela espiral chata em que cada melhoria de qualidade cobra um pedágio enorme de custo ou tempo.
O mais bonito é que otimização boa não precisa deixar o produto frio. Pelo contrário. Um sistema mais rápido, mais previsível e mais econômico costuma parecer mais confiável. O usuário não chama isso de engenharia elegante. Ele chama de produto bom.
O ponto menos óbvio de todos
Vou arriscar uma tese simples. A maior parte dos apps com IA não fracassa porque o modelo escreve mal. Fracassa porque o sistema decide mal o que mostrar ao modelo, o que permitir que ele faça e como conferir se o resultado prestou.
Essa mudança de lente ajuda muito. Em vez de perguntar qual é o melhor modelo, você começa a perguntar coisas mais férteis. Qual contexto realmente entra em cada tarefa. Como o sistema recupera informação. Onde a ferramenta pode falhar. Que tipos de erro valem bloqueio humano. O que fica medido desde a primeira semana. Como os logs contam a história de uma resposta. Em que momento vale dividir o fluxo em especializações. O que pode ser cacheado sem criar comportamento confuso.
Repara como a conversa amadurece. Ela sai do fascínio e entra no ofício.
No fim das contas, construir apps com IA virou uma atividade menos mágica e mais interessante. Continua existindo surpresa, claro. Continua existindo aquele momento gostoso em que o sistema faz algo e você pensa que isso aqui ficou realmente bom. Só que a qualidade duradoura não nasce desse susto bom. Ela nasce de uma sequência de decisões discretas, técnicas e muito humanas.
O melhor app com IA quase nunca é o mais espalhafatoso. É aquele que parece saber a hora de responder, a hora de buscar, a hora de agir, a hora de pedir ajuda e a hora de dizer que ainda não tem certeza.
Quando um produto chega nesse ponto, o usuário talvez nem perceba toda a engenharia por trás. Ele só sente que pode confiar.
E confiança, nesse nicho, vale mais do que deslumbramento.