🗺️ Do problema ao desenho
Você chegou aqui com duas coisas na mão: um problema escolhido (Módulo 3.2) e uma intenção clara (Módulo 3.1). Desenhar a arquitetura é traduzir isso num caminho concreto: quem fala com o sistema, o que ele faz com aquilo, e o que devolve. O desenho é a ponte entre "quero resolver isso" e "construí isso" — e desenhar antes evita refazer depois.
🧭 Arquitetura é só um desenho de fluxo
Não se assuste com a palavra "arquitetura". Aqui ela não é código nem diagrama de engenheiro: é um desenho simples do caminho que a intenção percorre. Entra por algum lugar, passa por algumas mãos, usa algumas ferramentas, respeita algumas regras e sai como resultado. Desenhar esse caminho é o trabalho deste módulo.
Pega o problema e a intenção
O ponto de partida é sempre a dor escolhida e o resultado que você quer — não a ferramenta da moda.
Desenha o caminho
Onde entra, por onde passa, o que usa, o que devolve — em caixas e setas, no papel ou na tela.
Vira blueprint
O desenho fechado guia o protótipo do Módulo 3.4 — construir vira execução, não improviso.
🚪 Canais e roteamento
Toda solução precisa de uma porta de entrada — o canal por onde a intenção chega (WhatsApp, site, e-mail, formulário). Mas o canal sozinho não basta: o sistema precisa de roteamento — saber, ao receber a mensagem, para qual serviço ou agente mandá-la lá dentro. Canal certo + roteamento certo faz a solução parecer fluida; o errado trava tudo na porta.
🔀 Canal × roteamento, lado a lado
- Canal: por onde a intenção entra e por onde a resposta sai (a porta visível ao usuário).
- Roteamento: a decisão interna de "essa mensagem é para qual parte do sistema?" — invisível ao usuário.
- Juntos: o usuário fala num lugar só e cada pedido cai na mão certa, sem ele perceber a engrenagem.
✓ Roteamento bem desenhado
- ✓Cada tipo de pedido tem um destino claro.
- ✓Há um caminho para o "não entendi" (fallback).
- ✓O usuário fala num canal só e tudo flui.
- ✓Dá para acrescentar um destino novo sem quebrar.
✗ Sem roteamento pensado
- ✗Tudo cai no mesmo lugar e se mistura.
- ✗Pedido fora do esperado trava sem resposta.
- ✗Cada canal novo vira uma gambiarra separada.
- ✗Ninguém sabe por onde a mensagem andou.
💡 Dica prática
Comece com UM canal — o que o seu público já usa. WhatsApp para atendimento, formulário no site para captura, e-mail para o interno. Um canal bem roteado vale mais que cinco canais bagunçados. Você acrescenta os outros depois que o primeiro funciona.
🧱 Serviços e agentes da solução
Dentro do sistema, o trabalho é feito por dois tipos de peça que você já conheceu no Dia 2: serviços (blocos de capacidade — buscar um dado, gerar um texto, registrar algo) e agentes (trabalhadores com uma missão, que decidem e usam serviços e ferramentas). Desenhar a arquitetura é decidir quais peças sua solução precisa e como elas se dividem o trabalho.
💡 Dica prática
Regra de ouro: cada peça faz UMA coisa bem feita. Se você está descrevendo um agente e usa a palavra "e" muitas vezes ("ele atende e cobra e agenda e relata"), provavelmente são vários agentes disfarçados de um. Separar deixa tudo mais fácil de testar e de evoluir peça por peça.
🔧 Ferramentas necessárias
Para agir no mundo real, a solução precisa de ferramentas: a planilha onde consulta um preço, o CRM onde registra um cliente, o calendário onde marca uma reunião, a API que envia uma mensagem. A regra de ouro do Dia 2 continua valendo: a ferramenta serve à intenção, nunca o contrário. Liste só o que o fluxo realmente precisa — e nada mais.
Planilha / banco
Onde a solução lê e grava dados.
CRM
Onde ficam os clientes e o histórico.
Calendário
Para marcar, lembrar e organizar tempo.
Mensageria
Para enviar e receber pelos canais.
APIs externas
Outros sistemas que a solução consulta.
Arquivos / docs
A base de conhecimento que ela consulta.
🧰 O teste do mínimo necessário
Para cada ferramenta que você pensa em incluir, pergunte: "sem ela, o fluxo ainda entrega o resultado?". Se sim, ela fica de fora do protótipo — entra depois, se fizer falta. Solução enxuta nasce, roda e mostra valor mais rápido. Ferramenta a mais é peso que você carrega sem precisar.
🛡️ Regras e segurança do fluxo
Quando a IA passa a agir no mundo real — enviar mensagens, mexer em dados, marcar coisas — a segurança vira parte da arquitetura, não um detalhe pra depois. Os muros que você viu no Módulo 2.6 entram no desenho: o que a solução pode fazer sozinha, o que precisa validar, e o que sempre exige um humano aprovando antes de acontecer.
Sem limites, uma ação errada vira um estrago real e caro.
Sem checar a entrada, o sistema age sobre dado errado.
Ações de risco (apagar, cobrar, enviar pra cliente) pedem um "ok" humano.
✅ O muro no ponto certo
Nem tudo precisa de muro. O segredo é colocar a barreira onde o risco é alto: ler um dado pode ser livre; apagar, cobrar ou mandar mensagem para um cliente pede validação ou aprovação. Marque no seu blueprint, com um cadeado, cada ponto onde uma ação só acontece depois de checada.
📐 O blueprint da solução
Agora você junta tudo num só desenho: intenção, canais, roteamento, serviços, agentes, ferramentas e regras. Esse é o blueprint — a planta da sua solução. É a reunião de tudo o que você viu no Dia 1 (terreno e canais) e no Dia 2 (alma, serviços, agentes, ferramentas, segurança), aplicada ao SEU problema. Com o blueprint na mão, construir o protótipo vira execução, não improviso.
O blueprint, em texto estruturado
Preencha uma linha de cada vez. Quando todas estiverem respondidas, você tem o blueprint da solução — pronto pro protótipo do Módulo 3.4.
Começa pela intenção e pelo resultado
As duas pontas do desenho: de onde parte (a dor) e onde chega (o ganho medido).
Liga o canal de entrada
Por onde a intenção chega e como o roteamento a manda para a peça certa.
Coloca serviços, agentes e ferramentas
Quem faz o trabalho no meio do caminho e o que cada um usa para agir.
Marca os muros
Onde entram validação e aprovação humana — os pontos de risco do fluxo.
💡 Dica prática
Um bom blueprint cabe em uma folha e qualquer pessoa da empresa consegue seguir o caminho com o dedo. Se o seu desenho ficou complexo demais para explicar em dois minutos, ele provavelmente está tentando resolver mais de um problema. Volte e recorte — foco em UM problema é o que faz a solução nascer.
Auto-checagem (opcional): o que é o blueprint da solução, no método JARVIS?
🗺️ Resumo do módulo
Próximo módulo:
3.4 — Protótipo Funcional: sair do blueprint e construir algo que funciona de verdade.