🧩 De piezas a sistema
Imagina cinco piezas de un motor esparcidas sobre el banco de trabajo: el pistón, la bujía, el cigüeñal, el tanque y el velocímetro. Cada pieza es perfecta, pero el auto no avanza. El Canvas del día 2 te dio las cinco piezas correctas: Contexto, Objetivos, Reglas, Memoria, Validación. Hoy las ensamblas de una manera que pone el motor en marcha. Un sistema no es la suma de sus piezas: es la disposición que hace que la intención se convierta en resultado de forma repetible.
Uno prompt bonito es un único disparo. Escribes, la IA responde y la calidad depende de tu inspiración en ese momento. Funciona una vez, falla la siguiente y nadie sabe por qué. Eso es improvisación, no un sistema.
Un sistema es un entorno de información. Antes de que pidas cualquier cosa, la IA ya SABE quién es, qué debe entregar, qué puede y qué no puede hacer, qué aprendió antes y cómo se comprobará el resultado. El pedido se vuelve la parte pequeña; el entorno hace el trabajo pesado.
La clave de la repetibilidad es esta: lo que garantiza la calidad no puede estar solo en tu cabeza. Si la regla de tono, el objetivo y el criterio de aceptación solo existen cuando te acuerdas de escribirlos, el sistema eres tú, y tú no puedes escalar ni dormir. Cuando esto se convierte en un entorno persistente, cualquier ejecución, cualquier día, parte de la misma base.
Los 5 pilares solo se convierten en sistema cuando se conectan en una cadena: Intención → Contexto → Proceso → Resultado. El Contexto y la Memoria aportan información; los Objetivos y las Reglas orientan y limitan; la Validación cierra el ciclo indicando si funcionó. Quita un eslabón y el sistema vuelve a ser un prompt que depende de la suerte.
La prueba para saber si tienes un sistema es brutalmente sencilla: ¿otra persona (o tú dentro de un mes) puede ejecutarlo y llegar a un resultado equivalente sin que le expliques nada en vivo? Si la respuesta es sí, es un sistema. Si depende de que expliques el contexto cada vez, todavía son piezas sueltas.
Repetible, confiable y alineado son las tres pruebas. Repetible: se ejecuta de nuevo y da un resultado parecido. Confiable: el resultado cumple los criterios, no solo es agradable a la vista. Alineado: cumple el objetivo y respeta las reglas del negocio. Un sistema es lo que cumple las tres cosas al mismo tiempo.
Las piezas sueltas no sirven. Ensambladas en un sistema, sí.
Ejemplo listo — Atención al cliente: prompt suelto vs. sistema
Un pequeño negocio quiere usar IA para responder a sus clientes por WhatsApp.
✗ Frágil
Responde a los clientes de mi tienda con amabilidad y resuelve sus dudas.
✓ Estructurado
CONTEXTO: Tienda de suplementos, ticket promedio R$ 120, entrega en 5 días hábiles, política de cambios dentro de 7 días. OBJETIVO: resolver la duda en la 1.ª respuesta siempre que sea posible; el éxito significa que el cliente no necesita repetir la pregunta. REGLAS: nunca prometer un plazo menor que 5 días; nunca ofrecer descuentos sin aprobación; si la duda es sobre un reembolso, derivar a una persona. MEMORIA: las 10 dudas más frecuentes y las respuestas aprobadas. VALIDACIÓN: toda respuesta debe indicar el plazo correcto y mantener un tono cordial; si no lo sabes, di que lo vas a verificar — nunca inventes.
Por qué cambia: El prompt suelto define el tono, pero no controla el plazo, el descuento ni el reembolso: cada respuesta es una ruleta. La versión de sistema fija qué significa tener éxito, qué está prohibido y cómo comprobarlo, así que funciona igual con cualquier agente de atención y cualquier día. Se vuelve repetible, confiable y alineada.
✓ Qué HACER
- ✓Escribir los 5 pilares en un lugar persistente que la IA lea en cada ejecución (prompt del sistema, documento de contexto, base de conocimientos).
- ✓Conectar los pilares en una cadena explícita: qué alimenta, qué orienta, qué limita y qué valida.
- ✓Aplicar la prueba del tercero antes de darlo por terminado.
✗ Qué EVITAR
- ✗Tratar el pedido del día como si fuera el sistema: el pedido es la punta, no el motor.
- ✗Dejar la regla o el objetivo solo en tu cabeza y escribirlo de memoria cada vez.
- ✗Creer que un prompt largo y atractivo ya es un sistema; sin validación ni persistencia, sigue siendo una ejecución única.
💡Consejo práctico
Haz la prueba del sobre: escribe tu sistema, cierra la computadora y pídele a otra persona que lo ejecute solo con lo que está escrito. Todo lo que tenga que preguntarte es un pilar que todavía está en tu cabeza y debe convertirse en texto.
Conceptos clave
Entorno, no ejecución puntual
Un sistema es el entorno de información que existe ANTES del pedido. El prompt pasa a ser la parte pequeña; el entorno carga con el peso de la calidad.
La calidad deja de depender de tu cabeza
Las reglas, el objetivo y el criterio deben estar escritos y ser persistentes. Si solo existen cuando los recuerdas, el sistema eres tú, y tú no escalas.
La cadena conecta las piezas
Intención → Contexto → Proceso → Resultado. Los 5 pilares solo se convierten en un sistema cuando se conectan en esta cadena; quita un eslabón y todo vuelve a depender de la suerte.
Prueba del tercero
Si otra persona lo ejecuta y obtiene un resultado equivalente sin que tengas que explicárselo en vivo, es un sistema. Si depende de que tú lo narres, todavía son piezas sueltas.
⚙️ Los engranajes
Si el sistema es un motor, sus engranajes tienen nombre. El framework es el diseño del motor. El flujo es el orden en que se mueven las piezas. El agente es la pieza que actúa por su cuenta dentro del flujo. La memoria es lo que el motor recuerda entre una vuelta y otra. No necesitas programar ninguno de ellos para entender cómo encajan, y quien entiende ese encaje elige mejor las herramientas.
Framework es la estructura de pensamiento que organiza el sistema. Los 5 pilares son un framework. La cadena Intención → Contexto → Proceso → Resultado es otro. Un framework no es una herramienta: es el molde mental que indica qué debe existir y en qué orden. Cambia la herramienta y el framework sigue en pie.
Flujo es la secuencia de etapas que lleva de la intención al resultado. Ej.: recibe el mensaje del cliente → clasifica el tipo de duda → busca la respuesta aprobada en la memoria → redacta → valida según las reglas → envía o deriva a una persona. El flujo transforma una solicitud vaga en una línea de producción con etapas definidas.
Agente es la parte del sistema que ejecuta ciclos sin que tengas que operar cada paso: escribe, prueba, ve el error, lo corrige y entrega. El día 1 era la capa 3 de la pirámide. Dentro de un sistema, el agente es un engranaje que ejecuta una parte del flujo de forma autónoma, pero siempre dentro de las reglas y con una validación al final.
Memoria es lo que persiste entre ejecuciones: patrones aprobados, decisiones anteriores, tono de la marca, errores que no deben repetirse. Sin memoria, cada día es el primer día y la IA vuelve a aprender desde cero. Con memoria, el sistema mejora con cada vuelta porque conserva lo que ya funcionó.
O encaje es este: el framework define qué existe, el flujo define el orden, el agente ejecuta las partes autónomas y la memoria alimenta todo con lo que ya se sabe. Diseñas el framework y el flujo; decides dónde cabe un agente y eliges qué va a la memoria. Las herramientas solo cumplen esos roles.
No todos los sistemas necesitan un agente. Un sistema de generación de contenido puede ser un framework + flujo + memoria, sin ninguna autonomía en ciclo. Empieza por el mínimo: agrega un agente solo cuando una etapa requiera iterar (intentar, fallar, corregir) sin que tú intervengas. La complejidad es un costo, no un trofeo.
Ejemplo listo — Contenido de marca: pedido vago vs. flujo diseñado
La creadora quiere un sistema que produzca posts semanales con el tono de su marca.
✗ Frágil
Escríbeme 5 publicaciones para esta semana con mi estilo.
✓ Estructurado
FRAMEWORK: 5 pilares. FLUJO: (1) extraer el tema de la semana y el objetivo de cada publicación; (2) buscar en la MEMORIA la guía de voz y 3 publicaciones que tuvieron buen rendimiento; (3) redactar el borrador siguiendo la guía; (4) VALIDAR con la lista de verificación (tono, gancho en los 2 primeros segundos, 1 CTA, sin jerga prohibida); (5) marcar las que pasan y devolver las reprobadas con el motivo. AGENTE: en las etapas 3-4, iterar hasta que el borrador pase la lista de verificación o, después de 2 intentos, derivarlo a la creadora.
Por qué cambia: Un pedido vago te entrega 5 textos genéricos que tienes que reescribir desde cero. El flujo diseñado nombra cada etapa, recupera la memoria de voz, valida según criterios y usa la autonomía solo donde tiene sentido (iterar el borrador). El resultado llega validado y con el tono adecuado, y mejora porque la memoria guarda lo que funcionó.
✓ Qué HACER
- ✓Diseñar el flujo como una secuencia de etapas con nombre antes de pensar en cualquier herramienta.
- ✓Decidir conscientemente qué se incluye en la memoria: patrones aprobados y errores que no hay que repetir.
- ✓Incorporar un agente solo en las etapas que exigen iterar sin que estés en medio.
✗ Qué EVITAR
- ✗Confundir framework (molde mental) con herramienta (la app que abres).
- ✗Acumular agentes e integraciones por estatus; la complejidad innecesaria cuesta y crea puntos de falla.
- ✗Ejecutar sin memoria y quejarte de que la IA lo olvida todo: no le diste nada que recordar.
💡Consejo práctico
Dibuja tu flujo en recuadros numerados en una hoja antes de abrir cualquier app. Para cada recuadro, pregúntate: ¿necesita memoria aquí? ¿necesita iterar aquí (agente)? ¿cuál es la regla que lo limita? Esa hoja vale más que la elección de la herramienta.
Conceptos clave
Framework = el molde mental
La estructura que indica qué debe existir y en qué orden. Los 5 pilares son un framework. No depende de ninguna herramienta: cambia la tool y se mantiene en pie.
Flujo = la línea de producción
La secuencia de etapas que lleva de la intención al resultado: recibir → clasificar → buscar → redactar → validar → entregar. Transforma una solicitud vaga en un proceso.
Agente = autonomía en ciclo
El mecanismo que escribe, prueba, corrige y entrega por sí solo una parte del flujo. Siempre dentro de las reglas y con validación al final. Úsalo solo cuando la etapa requiera iterar.
Memoria = lo que persiste
Patrones, decisiones y errores que no pueden repetirse. Sin ella, todos los días son el primer día. Con ella, el sistema mejora con cada vuelta.
🔄 El ciclo de operación
Un buen sistema no nace listo: nace para ejecutarse. La primera versión siempre tiene fallas; la diferencia de quien realmente lo opera está en tener un ciclo que convierte cada falla en una mejora. Ejecutar, validar, ajustar y mejorar no es una serie de pasos que haces una sola vez: es la rutina que mantiene vivo el sistema y lo vuelve cada vez más confiable.
Ejecutar es ejecutar el sistema con un caso real, no hipotético. Toma un mensaje real de un cliente, un tema real para una publicación, una decisión concreta que tengas que tomar. Un caso real deja al descubierto los huecos que el caso ideal oculta.
Validar es comprobar el resultado según los criterios que definiste en el pilar Validación, no según lo que te guste en ese momento. El criterio es objetivo: ¿mencionó el plazo correcto? ¿respetó la regla de descuento? ¿cumplió el objetivo? La validación sin criterios escritos se convierte en una ilusión de productividad: parece estar bien, pero no sabes si lo está.
Ajustar es corregir la CAUSA, no el síntoma. Si la IA prometió un plazo equivocado, no reescribas la respuesta a mano: corrige la regla o el contexto que permitió que pasara el error. Si ajustas el síntoma, tendrás que hacerlo cada vez; si ajustas la causa, lo corriges para siempre.
Mejorar es elevar el techo del sistema, no solo tapar un agujero. ¿Notaste que las 3 dudas más comunes siempre se derivan a una persona? Agrega respuestas aprobadas para ellas a la memoria. La mejora continua hace que el sistema de la semana 10 sea mejor que el de la semana 1, sin tener que empezar de cero.
El ciclo se cierra sobre sí mismo: cada ejecución validada genera un aprendizaje, el aprendizaje se convierte en un ajuste de raíz o en una mejora de la memoria, y la siguiente ejecución ya parte de un nivel más alto. Así es como el sistema acumula calidad en vez de limitarse a repetir.
Dos trampas matan el ciclo. La primera es no validar: lo ejecutas, te gusta, sigues adelante — y nunca descubres los errores silenciosos. La segunda es validar sin registrar: encuentras el fallo, lo corriges a mano y vuelve a aparecer la semana siguiente porque la causa nunca se convirtió en una regla. Registra lo aprendido o se pierde.
Un sistema no se entrega listo: funciona, valida, ajusta y mejora, siempre.
El loop, paso a paso
Ejecutar con un caso real
Ejecuta con un mensaje, tema o decisión reales. El caso ideal oculta las fallas; el caso real las expone. Un sistema demuestra su valor al funcionar, no en una diapositiva.
Validar según criterios
Compara el resultado con los criterios escritos en el pilar Validación, no con tu gusto del momento. Sin criterios objetivos, validar se vuelve una ilusión.
Ajustar la causa
Un error recurrente se corrige en la regla o en el contexto, no reescribiendo la salida a mano. El síntoma lo repites siempre; la causa la corriges una vez.
Mejorar y volver a ejecutar
Además de corregir las fallas, agrega a la memoria lo que funciona y vuelve al paso 1 desde un nivel más alto. Eso es lo que hace que la semana 10 supere a la semana 1.
Ejemplo listo — Corrección manual vs. ajuste de causa
El asistente de atención al cliente prometió la entrega en 3 días, pero el plazo real es de 5.
✗ Frágil
El responsable ve el error, edita la respuesta al cliente y cambia 3 por 5, y sigue con su día. La semana siguiente, el mismo error aparece con otro cliente.
✓ Estructurado
El responsable registra la falla en el log, identifica la CAUSA (el contexto no incluía el plazo estándar y la IA lo inventó), agrega al Contexto «entrega = 5 días hábiles» y crea la Regla «nunca prometer un plazo menor que el estándar»; agrega un elemento de Validación «verificar el plazo». Vuelve a ejecutar el mismo caso: funciona. El error no se repite.
Por qué cambia: Una corrección manual resuelve el caso de un cliente, pero deja intacta la causa: el error es estructural y se repetirá. Corregir la causa cambia el sistema: se convierte en una regla, en un criterio de validación y desaparece de una vez. Un solo esfuerzo, problema resuelto, sistema más confiable.
✓ Qué HACER
- ✓Ejecutar siempre la primera prueba con un caso real de tu día, nunca con un ejemplo perfecto.
- ✓Validar con la checklist del pilar Validación a la vista, punto por punto.
- ✓Registra cada falla en un registro breve: qué falló, cuál fue la causa y cuál es el ajuste; luego vuelve a ejecutar el mismo caso para confirmar.
✗ Qué EVITAR
- ✗Ejecutar, quedar conforme y seguir sin validar: así sobreviven los errores silenciosos.
- ✗Corregir el síntoma a mano y no tocar la causa; el error vuelve con otra cara.
- ✗Tratar el ciclo como un evento de lanzamiento único, y no como una rutina semanal.
💡Consejo práctico
Adopta la regla del mismo caso: después de ajustar la causa, vuelve a ejecutar exactamente el caso que falló. Si pasa, el ajuste fue a la causa. Si aún falla, corregiste el síntoma. Es la prueba más rápida para saber si la mejora fue real.
Conceptos clave
Ejecutar con un caso real
Ejecuta con un mensaje, tema o decisión reales. El caso ideal oculta las fallas; el caso real las expone. Un sistema demuestra su valor al funcionar, no en una diapositiva.
Validar según criterios, no según gustos
Compara el resultado con los criterios escritos en el pilar Validación. Sin criterios objetivos, validar se vuelve una ilusión de productividad: parece bueno, pero no sabes si lo es.
Ajustar la causa, no el síntoma
Un error recurrente se corrige en la regla o en el contexto, no reescribiendo la salida a mano. El síntoma lo repites siempre; la causa la corriges una vez.
Mejorar eleva el límite
Además de corregir las fallas, agrega a la memoria lo que funciona. Eso hace que el sistema de la semana 10 sea mejor que el de la semana 1 sin tener que rehacerlo desde cero.
🧭 Por encima de las herramientas
Las herramientas cambian de nombre cada trimestre. El modelo de hoy es reemplazado por el de mañana; la app que te encanta desaparece o cambia de precio. Quien solo aprendió a hacer clic en la herramienta empieza de cero cada vez que cambia. Quien aprendió la lógica —los 5 pilares, la cadena, el loop— lleva todo a la nueva herramienta y además la usa mejor que la mayoría.
A lógica es lo que no cambia: siempre necesitarás contexto, objetivo, reglas, memoria y validación, con cualquier herramienta y cualquier modelo. Esto pertenece a la naturaleza del problema, no del software. Por eso la Arquitectura de Intención es duradera: está un nivel por encima de la herramienta.
A herramienta es solo la implementación de la lógica. Dónde escribes el contexto, cómo guardas la memoria, qué botón activa el flujo: eso varía. Pero si sabes QUÉ debe existir, descubrir DÓNDE colocarlo en una herramienta nueva toma minutos, no meses.
Esto cambia quién lleva las riendas de la relación. El usuario superficial depende de la herramienta: espera el tutorial, copia el prompt mágico y se bloquea cuando cambia la interfaz. El arquitecto llega a la nueva herramienta con el sistema en la cabeza y solo pregunta dónde encaja cada pilar. La herramienta le sirve a él, no al revés.
El enfoque del día 1 decía: en la Arquitectura de Intención, el enfoque pasa del agente al sistema que lo guía. Aquí esto se completa: el enfoque también pasa de la herramienta a la lógica que guía cualquier herramienta. Es la misma subida de nivel.
En la práctica, documenta tu sistema sin depender de ninguna herramienta: los 5 pilares en texto plano, el flujo en recuadros numerados, los criterios de validación en una lista de verificación. Ese el documento es portátil. Migrar de una herramienta a otra se convierte en copiar y adaptar, no en empezar de nuevo.
La prueba de portabilidad es directa: si tu herramienta desapareciera mañana, ¿cuánto de tu sistema sobreviviría? Si la respuesta es casi todo, tienes lógica. Si es casi nada, solo tenías clics memorizados — y está a una actualización de distancia de perderlo todo.
Ejemplo listo — Rehén de la tool vs. dueño de la lógica
La herramienta de IA que usaba el equipo canceló el plan gratuito; necesitan migrar.
✗ Frágil
El equipo solo tenía una colección de prompts pegados en esa herramienta específica y un flujo de clics memorizado. Durante la migración, perdieron el contexto, tuvieron que empezar las pruebas desde cero y tardaron semanas en volver al nivel anterior, sin saber por qué algunas cosas volvían a fallar.
✓ Estructurado
El equipo tenía el sistema documentado: 5 pilares en un documento, flujo en recuadros numerados y checklist de validación. En la nueva herramienta, mapearon dónde encajaba cada pilar (contexto en el system, memoria en una base, validación como checklist humano), ejecutaron los mismos casos de prueba de siempre y en un día ya habían validado y puesto todo en marcha.
Por qué cambia: Quien solo tenía memorizados los clics estaba a una actualización de perderlo todo: la herramienta era el sistema. Quien tenía la lógica documentada trató el cambio como una reimplementación rápida, porque lo importante (lo que debe existir) ya estaba escrito y se podía trasladar. La lógica sobrevive; los clics no.
✓ Qué HACER
- ✓Documentar el sistema en un formato independiente de la herramienta: pilares en texto, flujo en cuadros, validación en una lista de verificación.
- ✓Al evaluar una herramienta nueva, pregunta dónde encaja cada pilar, no cómo se usa.
- ✓Mantener un conjunto fijo de casos de prueba para volver a validar el sistema en cualquier herramienta.
✗ Qué EVITAR
- ✗Memorizar prompts mágicos atados a una interfaz específica.
- ✗Tratar el cambio de herramienta como un reinicio; con la lógica documentada, es una reimplementación rápida.
- ✗Confundir saber hacer clic en la tool con entender el sistema: son capas diferentes.
💡Consejo práctico
Haz la prueba de desaparición: si tu principal herramienta desapareciera mañana, ¿cuánto de tu sistema sobreviviría? Anota el porcentaje con honestidad. Todo lo que perderías es lógica que todavía está ligada a la herramienta y debe convertirse en un documento portátil.
Conceptos clave
La lógica está en la naturaleza del problema
Cualquier herramienta y cualquier modelo requieren contexto, objetivos, reglas, memoria y validación. No pertenecen al software: pertenecen al problema. Por eso perduran.
La herramienta es la implementación
Dónde escribir, cómo guardar, qué botón presionar: solo cambia la forma. Si sabes QUÉ debe existir, encontrar DÓNDE en una herramienta nueva toma minutos.
Quien entiende la lógica manda
El usuario superficial depende del tutorial y se bloquea cuando cambia la interfaz. El arquitecto llega a la herramienta nueva y solo pregunta dónde encaja cada pilar.
Documento portátil
5 pilares en texto, flujo en cuadros, validación en checklist — independiente de la herramienta. Migrar pasa a ser copiar y adaptar, no empezar de cero.
💎 Dónde esto se convierte en valor
La Arquitectura de Intención no es teoría de pizarrón: se convierte en algo que genera ingresos, ahorra tiempo o reduce riesgos. Hay cuatro formas concretas de convertir un sistema en valor, y la misma lógica de los 5 pilares sirve para las cuatro. Saber cuál estás construyendo permite tener claro el foco del proyecto desde el primer día.
Asistente especializado es un sistema que hace muy bien una cosa en un contexto específico: el asistente de atención al cliente de tu tienda, el copiloto jurídico que revisa contratos según tus criterios, el asistente de RR. HH. que filtra currículums con tus criterios. Su valor está en la profundidad: conoce tu negocio, no el mundo.
Proceso automatizado es un sistema que ejecuta una cadena de tareas de principio a fin con poca intervención: recibir una solicitud → generar una respuesta → validar → registrar → notificar. Su valor está en el tiempo y la consistencia: lo que tomaba horas de trabajo manual se ejecuta solo, igual cada vez y dentro de las reglas.
Producto digital es un sistema que empaquetas y entregas a otras personas: una app, una herramienta interna que se vuelve externa, un servicio que usan los clientes. Su valor está en la escala: el sistema atiende a muchas personas sin que tengas que esforzarte en cada atención. Aquí la validación y las reglas se vuelven aún más críticas, porque el error llega al cliente final.
Sistema de decisión es un sistema que organiza información para que tú (o tu equipo) puedan decidir mejor: analiza escenarios, compara opciones según criterios y señala riesgos. Su valor está en la calidad de las decisiones y la reducción del riesgo. No decide por ti: estructura la decisión para que sea coherente y fundamentada.
A la misma lógica sirve para las cuatro. En todas, necesitas contexto (lo que sabe la IA), objetivo (qué es el éxito), reglas (límites), memoria (lo que persiste) y validación (cómo saber si está bien). Cambia el empaquetado y quién consume el resultado, no los pilares.
Definir el tipo desde el inicio afina el proyecto. Un asistente especializado prioriza la profundidad del contexto y la memoria; un producto digital prioriza reglas y validación a prueba de errores; un proceso automatizado prioriza el flujo y la validación automática; un sistema de decisión prioriza objetivos y criterios de comparación. Saber el tipo es saber dónde concentrar el esfuerzo.
Ejemplo listo — El mismo problema, cuatro formas de valor
Una clínica usa IA para gestionar la clasificación y las citas de sus pacientes.
✗ Frágil
“Voy a usar IA para ayudar en la clínica.” (Sin definir el tipo de sistema, el proyecto se convierte en un montón de prompts sin enfoque, sin criterios para darlo por listo y sin responsable del resultado.)
✓ Estructurado
Cuatro ejemplos claros: (1) ASISTENTE ESPECIALIZADO: copiloto que responde las consultas de los pacientes según el estándar de la clínica; se enfoca en contexto y memoria. (2) PROCESO AUTOMATIZADO: flujo que confirma citas, reprograma las ausencias y las registra en el sistema; se enfoca en flujo y validación. (3) PRODUCTO DIGITAL: portal de autoservicio al que se suscriben otras clínicas; se enfoca en reglas y validación a prueba de errores. (4) SISTEMA DE DECISIÓN: panel que prioriza la fila por urgencia según criterios clínicos; se enfoca en objetivos y criterios. Cada uno se convierte en un proyecto con un criterio de listo definido.
Por qué cambia: Un enfoque vago no permite concentrar el esfuerzo ni saber si está terminado. Nombrar el tipo le da precisión al proyecto: define qué pilar pesa más, cuál es el criterio de éxito y quién consume el resultado. La misma lógica de 5 pilares, cuatro formas concretas de generar valor.
✓ Qué HACER
- ✓Definir desde el inicio cuál de los cuatro tipos estás construyendo.
- ✓Concentrar el esfuerzo en el pilar que más exige ese tipo (contexto, flujo, reglas u objetivos).
- ✓Definir explícitamente quién consume el resultado y qué significa que esté listo para esa persona.
✗ Qué EVITAR
- ✗Empezar a construir sin decidir el tipo — se convierte en un montón de prompts sin foco.
- ✗Tratar un producto digital con el rigor de un borrador interno; el error llega al cliente.
- ✗Esperar que un sistema de decisión decida por ti; estructura la decisión, no la reemplaza.
💡Consejo práctico
Antes de empezar, completa la frase: "Estoy construyendo un [tipo] que ofrece [resultado] a [quién] y estará listo cuando [criterio]." Si no puedes completar los cuatro corchetes, todavía no sabes qué estás construyendo y el proyecto se desviará.
Conceptos clave
Asistente especializado
Hace una cosa muy bien para un contexto específico. Valor = profundidad: conoce tu negocio, no el mundo. Prioriza el contexto y la memoria.
Proceso automatizado
Ejecuta una cadena de tareas de principio a fin con poca intervención. El valor está en el tiempo y la consistencia. Prioriza el flujo y la validación automática.
Producto digital
Sistema empaquetado y entregado a terceros. El valor está en la escala. Las reglas y la validación se vuelven críticas, porque el error llega al cliente final.
Sistema de decisión
Organiza información para decidir mejor: compara opciones y señala riesgos. El valor está en mejorar la calidad de las decisiones y reducir riesgos. Prioriza objetivos y criterios.
🏁 Proyecto final
Llegó la hora de poner en marcha el motor. Vas a tomar el Canvas de los 5 pilares del día 2 y convertirlo en un sistema que funcione de verdad: definir los componentes, armar el flujo, probarlo con un caso real, validarlo con la lista de verificación y escribir tu plan de mejora continua. Al final de este tema no habrás aprendido sobre Arquitectura de Intención: tendrás un sistema propio en funcionamiento.
Paso 1 — Traduce el Canvas a la Ficha del Sistema. Toma los 5 pilares del día 2 y completa la Ficha del Sistema (la plantilla de hoy): componentes, flujo, criterios de validación y plan de mejora. El Canvas era el diseño; la Ficha es el sistema operativo.
Paso 2 — Define los componentes. Enumera lo que compone el sistema: dónde está el contexto, qué hay en la memoria, cuáles son las reglas activas, cuál es el objetivo y quién consume el resultado. Cada componente debe tener un lugar concreto, no una intención vaga.
Paso 3 — Arma el flujo. Escribe la secuencia de pasos en cuadros numerados: desde la entrada (el pedido o caso) hasta la salida validada. Marca dónde se consulta la memoria, dónde hay autonomía (agente) y dónde se valida.
Paso 4 — Ejecútalo con un caso real. Elige un caso real de tu día y ejecuta el sistema de principio a fin. Anota lo que salió. Un caso real, no ideal: esa es la prueba honesta.
Paso 5 — Valida con la checklist. Compara el resultado punto por punto con los criterios de validación. Marca si cumple o no cada uno. No cuenta el gusto: cuentan los criterios.
Paso 6 — Escribe el plan de mejora continua. Registra las fallas encontradas, la causa de cada una, el ajuste y la frecuencia de revisión (por ejemplo: revisar el registro todos los viernes). Ese plan es lo que mantiene vivo el sistema. Con la Ficha completa, el caso ejecutado, la validación hecha y el plan escrito, terminaste de armarlo: tienes un sistema de Arquitectura de Intención armado, ejecutado y con un ciclo de mejora en marcha.
Los 6 pasos para poner el motor en marcha
Traduce el Canvas a una Ficha
Los 5 pilares del día 2 se convierten en componentes, flujo, criterios y plan. El Canvas era el diseño; la Ficha es lo operativo.
Define los componentes
Dónde está el contexto, qué hay en la memoria, qué reglas están activas, cuál es el objetivo, quién lo usa. Cada cosa en un lugar concreto.
Arma el flujo
Desde la entrada hasta la salida validada, en recuadros numerados. Marca la memoria, el agente y la validación en cada etapa.
Ejecuta con un caso real
Un caso verdadero de tu día a día, de principio a fin. Anota lo que resultó. Un caso real, no ideal: esa es la prueba honesta.
Valida según la checklist
Revisa los criterios uno por uno. Marca aprobado o reprobado en cada uno. No cuenta el gusto: cuentan los criterios.
Escribe el plan de mejora
Fallas, causas, ajustes y frecuencia de revisión. Al dejar todo esto por escrito, terminaste de armarlo: sistema montado, probado y con el loop instalado.
Ejemplo listo — Entrega final: Canvas vago vs. sistema ejecutado
El alumno quiere terminar el curso con un sistema real de atención al cliente.
✗ Frágil
Tengo el Canvas completado con los 5 pilares anotados y un prompt largo listo. (pero nunca se ejecutó con un caso real, nunca se validó y no tiene un plan de mejora: es un diseño, no un sistema).
✓ Estructurado
FICHA completada: componentes definidos (contexto en el system, 10 preguntas en la memoria, 4 reglas activas, objetivo de resolver en la 1.ª respuesta). FLUJO en 5 recuadros. SE EJECUTÓ con 3 mensajes reales de clientes. SE VALIDÓ con 6 criterios — 2 reprobaron (plazo incorrecto, derivó demasiado). SE AJUSTARON las causas (regla de plazo + respuesta sobre reembolsos en la memoria), se volvió a ejecutar y pasó. PLAN: revisar el registro todos los viernes, meta de reducir las derivaciones en un 20% durante el mes.
Por qué cambia: El Canvas impreciso tiene todas las piezas, pero nunca encendió el motor: no se sabe si funciona. La Ficha puesta en marcha probó el sistema con casos reales, encontró y corrigió las fallas de raíz e instaló el ciclo de mejora. Uno es una promesa; el otro, un sistema operativo confiable, repetible y alineado. Eso es lo que completa el curso.
✓ Qué HACER
- ✓Traducir el Canvas del día 2 en la Ficha del Sistema antes de cualquier ejecución.
- ✓Ejecutar obligatoriamente con 2-3 casos reales y validar cada uno con la checklist.
- ✓Ajusta las causas de las fallas, vuelve a ejecutar el mismo caso y solo entonces declara que está listo.
- ✓Escribir el plan de mejora con la causa, el ajuste y la frecuencia de revisión.
✗ Qué EVITAR
- ✗Declarar listo el sistema sin haber ejecutado nunca un caso real.
- ✗Validar según el gusto en vez de la checklist de criterios.
- ✗Salir sin un plan de mejora: el sistema se congela en la primera versión.
- ✗Corregir los errores solo en la salida y no en la causa; el error vuelve la semana siguiente.
💡Consejo práctico
Tu certificado real no es el PDF: es la Ficha completa, con al menos un caso ejecutado, validado y con una falla corregida desde la causa. Guarda esa Ficha: es tu primer sistema y el molde para todos los que hagas después. Cada vez que tengas una idea nueva de IA, empieza por completar una Ficha.
Conceptos clave
Del Canvas a la Ficha
El Canvas del día 2 era el diseño; la Ficha del Sistema es la parte operativa. Traducir uno en la otra es lo que saca la intención del papel y la pone en marcha.
El componente ocupa un lugar concreto
Cada pilar se convierte en un componente con una ubicación real: dónde está el contexto, qué contiene la memoria y qué reglas están activas. Una intención vaga no se ejecuta.
Ejecutar con un caso real cierra el curso
El sistema solo queda probado cuando procesa un caso real de principio a fin y supera la validación. Un caso ideal no cuenta.
El plan de mejora lo mantiene vivo
Fallas, causas, ajustes y frecuencia de revisión por escrito. Sin el plan, el sistema se congela en la v1; con él, mejora cada semana.