Um app de IA útil começa pelo fluxo, não pelo modelo

Em poucas horas, uma demo já aceita texto ou voz, chama um modelo e devolve uma resposta bem escrita. A tela parece pronta. O problema aparece quando alguém pergunta de onde veio um fato, qual regra foi aplicada ou o que acontece se uma informação obrigatória estiver ausente.

Uma resposta bonita pode continuar ali mesmo quando o produto ainda não está definido.

Um projeto vencedor de um hackathon em São Paulo colocou essa diferença em um contexto bem brasileiro: orientar pequenos negócios sobre oportunidades de compras governamentais combinando Codex, dados públicos, regras de elegibilidade, entrada por voz e uma interface simples. O anúncio não permite concluir que o projeto esteja em produção ou que a arquitetura resolva todos os casos. Mesmo assim, a composição do problema é mais interessante do que a escolha do modelo.

Existe uma necessidade concreta, uma base factual, regras que não deveriam ser improvisadas e uma pessoa que precisa entender o resultado para tomar o próximo passo. É esse caminho que vale desenhar primeiro.

Comece pelo resultado que pode ser conferido

Antes de discutir prompt, framework ou provedor, complete esta frase:

Ao final, o usuário consegue…

Para um app que ajuda uma pequena empresa a encontrar oportunidades públicas, uma versão útil seria:

Ao final, o usuário consegue ver oportunidades compatíveis com o perfil informado, junto da fonte, da data dos dados, do motivo da correspondência e dos pontos que ainda exigem confirmação.

Essa frase já obriga o produto a assumir compromissos. “Encontrar oportunidades” pede uma fonte consultável. “Compatíveis” pede critérios. “Perfil informado” pede uma entrada que possa ser corrigida. Fonte, data e motivo pedem rastreabilidade na interface.

Agora fica mais fácil definir a evidência de sucesso. Um teste não deveria aceitar como resultado apenas uma frase plausível. Ele precisa verificar, por exemplo, se os itens exibidos existem na base consultada, se os filtros foram aplicados e se campos ambíguos chegaram ao usuário como pendência, não como certeza inventada.

Desenhe o fluxo em seis blocos

Eu costumo tratar o primeiro desenho como um mapa curto de responsabilidades:

O mapa não precisa nascer como um diagrama sofisticado. Uma página no repositório, perto do código, já serve. O importante é dar um dono a cada bloco e deixar claro qual evidência mostra que ele funcionou.

Também ajuda registrar o contrato da tarefa do modelo. Um rascunho pode ser simples:

type InterpretedNeed = {  categories: string[]  location?: string  ambiguities: string[]}type Recommendation = {  opportunityId: string  sourceUrl: string  sourceUpdatedAt: string  matchReason: string  requiresHumanReview: boolean}

Esses tipos não provam que a recomendação está correta, mas impedem que uma resposta livre seja confundida com o estado inteiro do produto. Eles também mostram quais informações o frontend precisa expor e quais campos a validação deve rejeitar quando faltarem.

Não terceirize regra de negócio para uma frase convincente

Modelos são bons em transformar linguagem solta em uma estrutura, resumir documentos e explicar por que dois elementos parecem relacionados. Eles também conseguem produzir uma justificativa elegante para uma conclusão errada.

Por isso, a divisão de trabalho precisa acompanhar o custo do erro. Se um critério de elegibilidade pode ser descrito por uma regra vigente e testável, mantenha esse critério fora do prompt. Use o modelo para interpretar a necessidade do usuário e explicar o resultado, mas não para inventar silenciosamente o limite que decide se uma empresa está apta.

Num fluxo desse tipo, a sequência poderia ser:

1. receber a descrição por texto ou transcrever a entrada por voz;
2. pedir confirmação para nomes, valores ou termos ambíguos;
3. transformar a necessidade confirmada em parâmetros de busca;
4. consultar a fonte pública e guardar a data da consulta;
5. aplicar os filtros determinísticos que o sistema realmente conhece;
6. usar o modelo para organizar os resultados e escrever explicações apoiadas nos dados retornados;
7. mostrar fontes, motivos e pendências antes de qualquer ação seguinte.

Essa é uma proposta de produto para explorar o caso, não uma descrição da implementação do hackathon. A distinção importa porque um anúncio de evento não é documentação de arquitetura nem prova de eficácia em produção.

As regras determinísticas também têm custo. Políticas mudam, dados chegam incompletos e testes envelhecem. A vantagem é que a mudança fica localizável: a equipe consegue versionar a regra, criar casos de teste e descobrir quais resultados precisam ser reavaliados. Uma regra escondida em texto livre é muito mais difícil de auditar.

Voz reduz atrito, mas exige uma etapa de confirmação

Entrada por voz pode aproximar o app de quem conhece o próprio negócio, mas não domina a linguagem do sistema de compras. Ela também introduz ruído.

Uma categoria pode ser transcrita de forma errada. Um valor pode perder a unidade. Uma localidade pode ter nomes parecidos. Se a transcrição entrar direto no filtro, a interface transforma uma dúvida de entrada em uma falsa certeza de saída.

O frontend deveria devolver os campos interpretados antes de executar a busca quando a ambiguidade muda o resultado. A equipe não precisa criar um formulário enorme. Pode ser uma revisão curta, com o trecho original ao lado do valor entendido e uma marcação clara nos campos incertos.

Essa etapa parece desacelerar a experiência, mas evita algo bem pior: uma resposta rápida sobre o problema errado.

Escolha a rota pelas capacidades exigidas

Com o fluxo desenhado, a conversa sobre stack fica menos abstrata. Em vez de perguntar “qual modelo é melhor?”, a equipe compara rotas contra uma matriz pequena:

As notas da versão prévia do Visual Studio, publicadas em 25 de agosto, ajudam a enxergar essa ideia na prática. O recurso Agent pode usar modelos por rotas como Microsoft Foundry, OpenAI, Anthropic e Ollama com BYOK, ou seja, com a chave do próprio usuário. A interface informa quando determinada capacidade do modo agente não está disponível na rota escolhida. Isso não significa que os provedores tenham paridade. Mostra justamente por que o ambiente precisa conhecer as diferenças.

Suporte a um modelo não garante suporte às ferramentas, ao formato de saída, ao ambiente ou à política de dados exigidos pelo seu fluxo. Se uma capacidade obrigatória não existe, o sistema deve bloquear, pedir confirmação ou reduzir a funcionalidade conforme uma regra definida. Trocar de rota e fingir que nada mudou costuma produzir os bugs mais difíceis de perceber.

Suporte a vários modelos não precisa virar uma abstração universal

Há um risco do outro lado: criar quatro adaptadores, duas filas e uma camada genérica para toda API antes de validar o primeiro usuário.

Para começar, eu isolaria a chamada principal atrás de uma fronteira estreita e registraria a matriz de capacidades no repositório. A segunda rota só entraria quando houvesse uma necessidade concreta, como privacidade, disponibilidade, custo ou uma ferramenta específica.

O teste entre rotas deve olhar para o contrato do fluxo, não apenas para uma resposta de exemplo. A rota alternativa precisa devolver o formato esperado, respeitar a condição de parada, chamar somente as ferramentas permitidas e falhar de maneira visível quando não conseguir cumprir isso.

Múltiplos provedores reduzem uma dependência, mas trazem diferenças de comportamento para dentro do produto. Essa troca pode valer a pena quando a equipe também assume o custo extra de testes e manutenção.

Um exemplo de falha que a interface não deveria esconder

Imagine que a fonte pública foi atualizada pela última vez há vários dias e um campo necessário para verificar uma regra não está presente. O modelo ainda consegue escrever uma explicação convincente com o restante do contexto.

O produto deveria evitar a recomendação fechada. Uma saída honesta seria mostrar os itens encontrados, a data da base e um aviso de que a elegibilidade não pôde ser confirmada. A ação seguinte pode ser revisar os dados ou abrir a fonte original.

Esse comportamento nasce antes do prompt. Ele depende de o pipeline carregar metadados da fonte, de a validação reconhecer o campo ausente e de o frontend ter um estado visual para “não confirmado”. Pedir ao modelo que “seja cuidadoso” não substitui nenhuma dessas decisões.

O mesmo vale para indisponibilidade. Se a rota do modelo falhar, talvez o app ainda consiga exibir resultados filtrados sem a explicação em linguagem natural. Se a fonte de verdade falhar, gerar uma resposta com memória do modelo seria uma degradação perigosa. Falhas diferentes pedem comportamentos diferentes.

Um checklist para sair da demo

Antes de investir mais tempo na escolha do modelo, revise o fluxo com estas perguntas:

• O resultado útil cabe em uma frase observável?
• Cada fato importante tem uma fonte de verdade identificada?
• Regras críticas têm versão e casos de teste fora do texto livre?
• A tarefa do modelo tem entrada, saída e condição de parada claras?
• Dados ausentes geram bloqueio ou confirmação em vez de palpite silencioso?
• A interface mostra fonte, data, motivo e pendências?
• A rota escolhida suporta as ferramentas e o ambiente exigidos?
• Existe uma degradação definida para cada capacidade opcional?

Esse checklist também melhora a conversa entre produto, frontend e backend. O frontend passa a conhecer estados além de “carregando” e “concluído”. O backend sabe onde preservar fonte e versão. Produto consegue decidir quais erros permitem continuar e quais exigem revisão humana.

O modelo continua importante. Preço, latência, qualidade e disponibilidade afetam a experiência. A diferença é que essas escolhas passam a ocupar uma parte delimitada do sistema.

Quando o fluxo está explícito, trocar o modelo vira uma decisão de rota que pode ser testada. Sem esse mapa, cada troca corre o risco de mudar também as regras, as garantias e até o problema que o app dizia resolver.

Fontes

• Expanding our presence in Brazil
• Visual Studio 2026 Insiders release notes