📐 Desenho de Soluções

Um blueprint é a especificação técnica da automação — um documento que descreve cada componente, os dados que entram e saem, e como as peças se conectam, antes de tocar em qualquer ferramenta.

Construir sem blueprint é improvisar no editor: você se perde, retrabalha e descobre falhas tarde. O blueprint torna o problema visível e barato de corrigir no papel.

Especificação ≠ implementação · pensar antes de construir · um blueprint legível por quem não vai construir.

Pegar cada caixa do diagrama to-be e classificá-la em um tipo de componente: o que dispara (trigger), o que move/transforma dados (passos), o que raciocina (IA) e o que produz efeito no mundo (ações).

Sem essa tradução, o diagrama é só um desenho bonito. Classificar em componentes revela exatamente quantas integrações, prompts e nós você vai precisar.

1 caixa = 1 ou mais componentes · separar lógica determinística de IA · nomear cada componente.

A espinha dorsal de quase toda automação com IA segue seis estágios: algo dispara, dados são coletados, a IA interpreta, uma decisão é tomada, uma ação é executada e tudo é registrado.

Conhecer a anatomia padrão te dá um molde reutilizável: você encaixa qualquer caso novo nesses seis estágios em vez de inventar a estrutura do zero.

6 estágios canônicos · o log nunca é opcional · decisão separada da ação.

Para cada componente, definir explicitamente o que entra e o que sai e em qual formato (texto, JSON, arquivo, número). É o contrato que conecta uma peça à seguinte.

A maioria das quebras de fluxo acontece na junção: um componente entrega num formato que o próximo não entende. Definir formatos no blueprint elimina isso antes de existir.

Contrato de dados · JSON como língua franca · campos obrigatórios vs. opcionais.

Mapear, para cada componente, o que pode dar errado (API fora do ar, dado faltando, IA sem certeza) e definir o comportamento de fallback: repetir, pular, alertar um humano ou parar.

Automação sem plano B é frágil: a primeira exceção derruba tudo. Antecipar falhas no blueprint é o que transforma um protótipo em algo confiável de verdade.

Retry vs. fallback · human-in-the-loop · falhar barulhento, nunca silencioso.

Definir, antes de construir, o que conta como sucesso: tempo economizado, taxa de acerto, % de casos que exigem intervenção humana, custo por execução.

Sem métrica de sucesso definida antes, você nunca sabe se a automação está boa o suficiente para entregar — ou se está, na verdade, criando mais trabalho.

Métrica antes da construção · baseline manual · custo por execução conta.

Três caminhos para orquestrar a automação: n8n (low-code, self-host, flexível), Make (visual, SaaS, rápido de começar) e código puro (máximo controle, máxima manutenção).

A escolha errada da base custa caro depois: você bate em limites de licença, em falta de um conector ou em complexidade que o low-code não suporta. Escolher com critério evita migração futura.

Low-code vs. código · self-host vs. SaaS · custo de manutenção é parte do custo.

Decidir se a tarefa realmente precisa de um LLM (vs. regra/regex) e, se precisar, qual modelo: um pequeno e barato para classificar, um grande e caro para raciocínio complexo.

Usar o modelo mais caro em tudo queima orçamento; usar o mais barato em tarefa difícil queima confiabilidade. Casar tarefa com modelo é o que mantém custo e qualidade sob controle.

LLM não é a resposta para tudo · modelo pequeno para tarefa simples · custo por token × volume.

RAG (Retrieval-Augmented Generation) busca trechos relevantes de uma base de conhecimento própria e os injeta no prompt, fazendo a IA responder com base nos seus documentos, não só no treino dela.

Quando a automação depende de informação que só existe na sua empresa (políticas, catálogo, histórico), RAG é o que evita a IA inventar e a mantém ancorada na verdade.

Recuperar antes de gerar · embeddings e busca semântica · RAG só quando há conhecimento próprio.

MCP (Model Context Protocol) é um padrão para conectar a IA a ferramentas externas — ler arquivos, consultar bancos, chamar APIs — de forma uniforme, sem código de cola para cada integração.

Quando a automação exige que a IA aja (não só responda), MCP padroniza esse acesso. Entender quando usar evita reinventar conectores e mantém a stack escalável.

Protocolo padronizado · IA que usa ferramentas · reuso de conectores.

Os encanamentos da automação: APIs (você pede dados), webhooks (o sistema te avisa) e bancos (você guarda e consulta estado), com Supabase como exemplo de banco + API + auth num pacote.

Quase toda automação útil precisa puxar, receber ou persistir dados. Saber a diferença entre API e webhook, e quando precisar de um banco, é o que conecta o fluxo ao mundo real.

Pull (API) vs. push (webhook) · estado precisa de banco · Supabase como atalho.

Um conjunto de critérios para comparar opções: custo, velocidade de entrega, manutenção, controle, limites de escala e dependência de fornecedor — e o reconhecimento de que toda escolha troca uma coisa por outra.

Decisões de stack tomadas por moda ou hábito custam caro. Um quadro de trade-offs explícito te força a justificar cada escolha e a defender ela diante do cliente.

Não existe escolha grátis · critério explícito · simples ganha quando empata.

Tratar o prompt não como uma conversa, mas como um pedaço de especificação: instruções precisas, sem ambiguidade, que definem exatamente o comportamento esperado da IA dentro do fluxo.

Na automação não há humano para corrigir a IA em tempo real. O prompt precisa estar certo de antemão — é código que roda sozinho mil vezes.

Prompt = código em linguagem natural · zero ambiguidade · escrever para a máquina, não pra conversa.

Um esqueleto reutilizável: definir o papel da IA, dar o contexto necessário, especificar a tarefa, fixar o formato de saída e listar as regras e restrições.

Prompts ad-hoc dão resultados inconsistentes. Uma estrutura fixa torna o comportamento previsível e o prompt fácil de revisar e manter.

Papel + contexto + tarefa + formato + regras · seções nomeadas · template reutilizável.

Pedir que a IA responda num JSON com campos fixos, e validar essa resposta antes de usá-la — garantindo que o próximo passo do fluxo receba sempre a mesma estrutura.

Texto livre quebra a automação: o passo seguinte não sabe onde está cada informação. JSON validado é o que torna a saída da IA confiável o suficiente para alimentar uma ação automática.

JSON com schema · validar antes de usar · rejeitar e repetir se inválido.

Guardrails são limites no prompt e na validação (o que a IA não pode fazer, o que rejeitar); fallback é o que acontece quando a IA não tem certeza ou foge das regras: pedir confirmação, escalar ou usar um valor padrão.

A IA erra e alucina. Guardrails e fallback são o que impedem que um erro vire uma ação irreversível executada automaticamente.

Limitar o que a IA pode fazer · campo de confiança · caminho seguro quando incerto.

Usar um campo da saída JSON da IA (ex.: categoria, prioridade) como chave de uma decisão IF/switch no fluxo, roteando cada caso para uma ação diferente.

É aqui que a IA deixa de ser um enfeite e vira o cérebro da automação: ela classifica, o fluxo ramifica. Saber desenhar essa ponte é o que torna a automação inteligente de verdade.

IA decide, fluxo executa · campo categórico como chave · um ramo por caso + ramo padrão.

Montar um conjunto de casos de teste (incluindo casos difíceis e adversariais), rodar o prompt contra todos, medir a taxa de acerto e ajustar o prompt até estabilizar.

Um prompt que funciona em um exemplo pode falhar em dez. Só um ciclo de teste com casos reais te dá confiança para colocar a IA pra decidir sozinha em produção.

Conjunto de testes · casos difíceis primeiro · iterar até estabilizar a taxa de acerto.