🗺️ Del problema al diseño
Llegaste aquí con dos cosas en la mano: un problema elegido (Módulo 3.2) y una intención clara (Módulo 3.1). Diseñar la arquitectura es traducir esto en un camino concreto: quién habla con el sistema, qué hace con eso y qué devuelve. El diseño es el puente entre "quiero resolver esto" y "construí esto" — y diseñar antes evita tener que rehacerlo después.
🧭 La arquitectura es solo un diagrama de flujo
No te asustes con la palabra "arquitectura". Aquí no se refiere a código ni a un diagrama de ingeniería: es un dibujo sencillo del recorrido de la intención. Entra por algún lugar, pasa por algunas manos, usa algunas herramientas, respeta algunas reglas y sale como resultado. Dibujar ese recorrido es el trabajo de este módulo.
Identifica el problema y la intención
El punto de partida siempre es el problema elegido y el resultado que quieres, no la herramienta de moda.
Traza el camino
Por dónde entra, por dónde pasa, qué usa y qué devuelve: en cuadros y flechas, en papel o en pantalla.
Se convierte en un blueprint
El diseño definido guía el prototipo del Módulo 3.4: construir se convierte en ejecución, no en improvisación.
🚪 Canales y enrutamiento
Toda solución necesita una puerta de entrada — el canal por el que llega la intención (WhatsApp, sitio web, correo electrónico, formulario). Pero el canal por sí solo no basta: el sistema necesita enrutamiento — saber, al recibir el mensaje, a qué servicio o agente enviarlo dentro del sistema. El canal correcto + el enrutamiento correcto hacen que la solución parezca fluida; si son incorrectos, todo se atasca en la puerta.
🔀 Canal × enrutamiento, lado a lado
- Canal: por dónde entra la intención y por dónde sale la respuesta (la puerta visible para el usuario).
- Enrutamiento: la decisión interna de "¿este mensaje es para qué parte del sistema?" — invisible para el usuario.
- Juntos: el usuario habla en un solo lugar y cada solicitud llega a quien corresponde, sin que note cómo funciona el mecanismo.
✓ Enrutamiento bien diseñado
- ✓Cada tipo de solicitud tiene un destino claro.
- ✓Hay una vía para el «no entendí» (fallback).
- ✓El usuario habla por un solo canal y todo fluye.
- ✓Se puede agregar un destino nuevo sin romper nada.
✗ Sin enrutamiento planificado
- ✗Todo cae en el mismo lugar y se mezcla.
- ✗Una solicitud inesperada se bloquea sin respuesta.
- ✗Cada canal nuevo se convierte en un arreglo improvisado aparte.
- ✗Nadie sabe por dónde pasó el mensaje.
💡 Consejo práctico
Empieza con UN canal: el que ya usa tu público. WhatsApp para la atención, un formulario en el sitio web para captar contactos, correo electrónico para el equipo interno. Un canal bien configurado vale más que cinco canales desordenados. Agrega los demás cuando el primero funcione.
🧱 Servicios y agentes de la solución
Dentro del sistema, el trabajo lo realizan dos tipos de componentes que ya conociste en el Día 2: servicios (bloques de capacidad — buscar un dato, generar un texto, registrar algo) y agentes (trabajadores con una misión, que toman decisiones y usan servicios y herramientas). Diseñar la arquitectura es decidir qué piezas necesita tu solución y cómo se reparten el trabajo.
💡 Consejo práctico
Regla de oro: cada pieza hace UNA cosa bien. Si estás describiendo un agente y usas la palabra "y" muchas veces ("atiende e cobra e agenda e relata»), probablemente sean varios agentes disfrazados de uno. Separarlos facilita probar y mejorar cada pieza.
🔧 Herramientas necesarias
Para actuar en el mundo real, la solución necesita herramientas: la hoja de cálculo donde consultas un precio, el CRM donde registras un cliente, el calendario donde agendas una reunión, la API que envía un mensaje. La regla de oro del Día 2 sigue vigente: la herramienta está al servicio de la intención, nunca al revés. Enumera solo lo que el flujo realmente necesita, y nada más.
Hoja de cálculo / base de datos
Dónde la solución lee y guarda datos.
CRM
Dónde están los clientes y el historial.
Calendario
Para agendar, recordar y organizar el tiempo.
Mensajería
Para enviar y recibir mensajes por los canales.
APIs externas
Otros sistemas que consulta la solución.
Archivos / docs
La base de conocimiento que consulta.
🧰 La prueba de lo mínimo necesario
Para cada herramienta que piensas incluir, pregúntate: "sin ella, ¿el flujo sigue entregando el resultado?". Si sí, déjala fuera del prototipo: se incorpora después, si hace falta. Una solución sencilla nace, funciona y muestra su valor más rápido. Cada herramienta adicional es un peso que cargas sin necesidad.
🛡️ Reglas y seguridad del flujo
Cuando la IA empieza a actuar en el mundo real —enviar mensajes, modificar datos, programar cosas—, la la seguridad se convierte en parte de la arquitectura, no un detalle para después. Los límites que viste en el Módulo 2.6 forman parte del diseño: qué puede hacer la solución por sí sola, qué debe validar y qué siempre requiere la aprobación de una persona antes de ejecutarse.
Sin límites, una acción equivocada provoca daños reales y costosos.
Sin validar la entrada, el sistema actúa sobre datos incorrectos.
Las acciones de riesgo (borrar, cobrar, enviar al cliente) requieren el «ok» de una persona.
✅ El muro en el punto adecuado
No todo necesita un muro. El secreto es poner la barrera donde el riesgo es alto: leer un dato puede ser libre; borrar, cobrar o enviarle un mensaje a un cliente requiere validación o aprobación. Marca en tu blueprint, con un candado, cada punto donde una acción solo se realiza después de ser verificada.
📐 El blueprint de la solución
Ahora reúnes todo en un solo diseño: intención, canales, enrutamiento, servicios, agentes, herramientas y reglas. Ese es el blueprint — el plano de tu solución. Reúne todo lo que viste el Día 1 (terreno y canales) y el Día 2 (esencia, servicios, agentes, herramientas, seguridad), aplicado a TU problema. Con el blueprint en mano, construir el prototipo se vuelve ejecución, no improvisación.
El blueprint, en texto estructurado
Completa una fila a la vez. Cuando todas estén respondidas, tendrás el blueprint de la solución, listo para el prototipo del Módulo 3.4.
Empieza por la intención y el resultado
Los dos extremos del diagrama: de dónde parte (el problema) y adónde llega (el beneficio medido).
Conecta el canal de entrada
Por donde llega la intención y cómo el enrutamiento la envía a la pieza adecuada.
Conecta servicios, agentes y herramientas
Quién hace el trabajo durante el proceso y qué usa cada quien para actuar.
Marca los muros
Dónde entran la validación y la aprobación humana: los puntos de riesgo del flujo.
💡 Consejo práctico
Un buen blueprint cabe en una hoja y cualquier persona de la empresa puede seguir el recorrido con el dedo. Si tu diseño quedó demasiado complejo para explicarlo en dos minutos, probablemente intenta resolver más de un problema. Vuelve atrás y delimítalo: enfocarse en UN problema es lo que hace que la solución cobre vida.
Autoevaluación (opcional): ¿qué es el blueprint de la solución en el método JARVIS?
🗺️ Resumen del módulo
Siguiente módulo:
3.4 — Prototipo funcional: pasar del blueprint a construir algo que funciona de verdad.