🍳 El framework WAT

WAT es el nombre del curso: Workflow (receta), Agent (cocinero) y Tools (ingredientes/electrodomésticos).

Fija el modelo mental que sustenta todo el curso; sin él, cada ruta siguiente queda suelta.

Workflow, Agent, Tools, funciones distintas.

Una secuencia de pasos en texto simple (markdown) que indica qué hacer y en qué orden.

Es la pieza que guarda la intención: sin ella, el agente reinventa el proceso en cada pedido.

Markdown, paso a paso, no es código.

Claude Code: lee el workflow, elige la herramienta adecuada, la ejecuta y hace ajustes si algo sale diferente.

Es la pieza que aporta criterio al proceso: interpreta la receta en vez de limitarse a repetirla.

Interpretación, elección de tool, corrección.

Las acciones concretas que activa el agente: leer un archivo, ejecutar un comando, enviar un correo electrónico, llamar a una API.

Sin herramientas, el agente solo tendría opiniones — las rutas 2 y 4 se ocupan de proporcionar y conectar tools.

Herramienta, API, ejecución real.

Cada pieza cumple un papel diferente: intención (workflow), criterio (agente) y capacidad (tools).

Separar es lo que hace que el sistema sea predecible y flexible al mismo tiempo.

Separación de responsabilidades.

Un agente sin receta resulta caro e impredecible; una tool sin receta ni cocinero queda parada, inútil.

Entender estos dos fallos evita pedir una automatización sin preparar antes la receta.

Costo, imprevisibilidad, herramienta detenida.

Leer el paso, elegir la tool, ejecutar, observar el resultado, decidir el siguiente paso.

Es este ciclo repetido el que transforma la receta escrita en trabajo real hecho.

Ciclo, bucle, repetición hasta terminar.

El agente identifica en qué punto de la receta está, usando la conversación y los archivos existentes.

Sin saber «dónde está», el agente no puede decidir correctamente el siguiente paso.

Estado, contexto, memoria de la sesión.

Dado el paso y el menú de herramientas disponibles, el agente elige la más adecuada.

Cuanto más claras sean las herramientas disponibles, mejor será la elección: tema de las Trilhas 2 y 3.

Elección de herramienta, menú de opciones.

Después de ejecutar, el agente lee el resultado: salió bien, hubo un error o salió distinto de lo esperado.

Esta lectura es lo que activa la corrección — sin ella, los errores pasarían desapercibidos.

Observación, verificación del resultado.

Repetir para corregir un error temporal es normal; repetir sin cambiar de estrategia es quedarse atascado.

Reconocer la diferencia evita quedar atrapado en un ciclo costoso sin darte cuenta.

Loop saludable, loop bloqueado, costo.

Éxito, pausa para preguntarte algo que solo tú sabes o bloqueo que requiere intervención.

Saber reconocer cuál de los tres está ocurriendo es una habilidad que se desarrolla con la práctica.

Éxito, pausa, bloqueo.

La autocorrección existe, pero se vende como algo más de lo que es: una IA que piensa sola para siempre.

Confundir las dos fases es el origen de la mayoría de las expectativas frustradas sobre la IA.

Autocorrección: exageración de marketing.

En Claude Code, el agente intenta un paso, lee el error, hace un ajuste y vuelve a intentarlo varias veces.

Es la fase que sostiene la fama de la «IA que se corrige sola», y aquí es cierto.

Ensayo-error-corrección, supervisión.

Una vez publicado y programado, el agente ejecuta el workflow definido, como cualquier automatización tradicional.

Es la previsibilidad que quieres en una automatización que se ejecuta sola todos los días.

Determinismo, workflow definido.

Dentro de Claude Code interactivo: flexible. Publicado y programado: fijo.

No se trata de «qué tan inteligente» es el agente: se trata de dónde se está ejecutando.

La publicación como línea divisoria.

Las demostraciones muestran la fase de construcción y dejan implícito que continúa para siempre.

Entender esto evita dos frustraciones: esperar demasiado o desconfiar de todo el curso.

Generalización, expectativa incumplida.

Usa la construcción para que el workflow sea robusto; monitorea en producción, sin esperar que se autocorrija.

Ayuda a planificar el tiempo adecuado de prueba antes de publicar algo de verdad.

Monitoreo, mantenimiento manual.

Workflow que no dice lo suficiente para que el agente decida sin adivinar.

No es que el agente «no haya entendido»: es que las instrucciones no fueron lo bastante claras.

Vaguedad, suposición equivocada.

Las herramientas requieren una clave de API o permiso; sin eso, el paso no se puede ejecutar.

La solución nunca es reescribir el workflow, sino configurar la credencial que falta.

Clave de API, permiso, credencial.

El agente toma una decisión equivocada por falta de contexto: ejemplos y reglas del CLAUDE.md.

El CLAUDE.md existe precisamente para cargar ese contexto de forma persistente.

Contexto, CLAUDE.md, ejemplos.

Las instrucciones que compiten entre sí permiten más de una interpretación razonable.

A diferencia de vago, ambiguo tiene un exceso de reglas contradictorias.

Ambigüedad, prioridad sin definir.

El resultado es diferente, pide una contraseña, se sale del estándar o varía entre sesiones.

Aprender a leer las señales evita «pelear» con el agente sin entender por qué.

Diagnóstico basado en el comportamiento.

¿La receta es clara? ¿La clave está configurada? ¿Hay suficiente contexto? ¿No hay instrucciones que compitan entre sí?

Recorrer la checklist resuelve la mayoría de las fallas antes de volver a escribir todo desde cero.

Lista de verificación, diagnóstico rápido.

Una automatización de newsletter: investiga un tema, redacta un borrador y prepara el envío.

Lo bastante pequeña para caber en una sesión y lo bastante completa para poner todo en práctica.

Investigación, redacción, envío.

Escribir la receta en 5 pasos, evitando el error de una receta vaga.

Es la inversión que más tiempo y tokens ahorra en el resto del build.

Workflow escrito, freno de seguridad.

Un prompt completo, listo para pegar, con las partes variables marcadas.

Copiar y ejecutar de verdad es lo que fija el aprendizaje; no basta con leer sobre ello.

Prompt copy-run, variables marcadas.

Leer el borrador, dar comentarios específicos, pedir que rehaga solo la parte que falló.

Practica en la práctica la fase de construcción del módulo 1.3.

Comentarios específicos, corrección puntual.

Los tres errores del módulo 1.4 aparecen casi siempre en el primer intento de este build.

Reconocer los errores comunes agiliza la solución desde el primer intento.

Errores recurrentes, diagnóstico rápido.

Dar la herramienta de correo electrónico real (Ruta 2) y publicar/programar (Rutas 4 y 6).

Cierra el círculo mostrando hasta dónde llega esta build cuando se incorporan las próximas rutas.

Deploy, programación, próximos pasos.