🛠️ Fable 5 como Agente de Trabajo

Un modelo avanzado como Fable 5 se desperdicia resumiendo textos o respondiendo preguntas rápidas; su verdadero valor aparece ante problemas difíciles: revisar la arquitectura de un proyecto completo, evaluar riesgos de producto/tecnología/negocio, convertir una idea en un plan de ejecución, analizar un documento extenso, revisar código/seguridad/UX/base de datos.

Dirigir la herramienta adecuada a la tarea adecuada es el primer filtro para usar el modelo como agente de trabajo, no como un chat caro.

Tarea de alto valor; desperdicio de capacidad; diagnóstico frente a pregunta rápida.

Una plantilla de prompt que solicita un diagnóstico del problema central, decisiones estratégicas, riesgos, un plan de ejecución por etapas, entregables concretos y qué hacer ahora, en orden.

Es un prompt listo para copiar y adaptar, probado en tareas reales de análisis de proyectos.

Prompt probado en la práctica (no es una cita oficial); agente sénior; entregable por etapas.

El modelo responde mejor cuando entiende la intención detrás de la solicitud: el objetivo general, el público, el contexto y el resultado esperado; no solo la instrucción sin más.

"Crear una ruta de IA" es impreciso; decir para quién es, con qué objetivo y qué resultado final se espera cambia por completo la calidad de la respuesta.

Contexto de intención; público objetivo; resultado esperado declarado.

Una plantilla que declara el objetivo («profesionales que quieren aplicar IA en el trabajo, practicando todos los días») antes de solicitar una ruta con diagnóstico inicial, práctica diaria, proyecto semanal, apoyo, criterio de progreso y resultado final.

Comparar el prompt débil con el fuerte, uno al lado del otro, muestra de forma concreta la mejora que se obtiene al dar contexto antes de pedir algo.

Prompt débil vs. fuerte; estructura con criterio de evolución; resultado final esperado.

En la práctica: antes de escribir cualquier prompt para un análisis exhaustivo, primero confirma que la tarea amerita usar el modelo (consejo 1) y luego define el motivo real de la solicitud (consejo 2); juntos, los dos forman un prompt de diagnóstico completo.

Por separado, cada consejo ayuda poco; combinados, cambian el tipo de respuesta que recibes.

Filtro de tarea + contexto de intención; prompt de diagnóstico completo.

Errores comunes: usar el modelo para tareas de resumen o subtítulos; pedir un análisis sin decir para quién es ni cuál es el resultado esperado; copiar un prompt genérico sin adaptarlo al proyecto real.

Lista de verificación rápida antes de empezar: ¿la tarea es lo bastante difícil? ¿El motivo está explícito? ¿El público y el resultado están claros?

Lista de verificación previa al prompt; adaptación al proyecto real; motivo explícito.

Baja: resumen, leyenda, ajuste de texto, idea rápida. Media: planificación sencilla, comparación, revisión de contenido. Alta: estrategia, arquitectura, auditoría, decisión de producto. Máxima: problema crítico, migración, seguridad, análisis de riesgo complejo.

Pedir el máximo razonamiento para una tarea trivial cuesta más y tarda más sin aportar beneficios, y lo contrario produce resultados demasiado superficiales para una decisión importante.

Profundidad de análisis; costo × complejidad; calibración según el tipo de tarea.

Un prompt breve que limita dónde aplicar profundidad: «usa un análisis profundo solo en la parte estratégica. No compliques la solución. No crees abstracciones innecesarias. Entrega la solución más sencilla que resuelva bien el problema.»

Concentra el esfuerzo costoso donde importa y evita que el resto de la respuesta se vuelva innecesariamente complejo.

Profundidad selectiva; solución más simple; evitar abstracciones.

Los modelos potentes pueden tomar demasiada iniciativa: antes del análisis técnico o la ejecución, hay que dejar claro qué puede y qué no puede hacer el agente por su cuenta.

Sin un límite declarado, «evalúa este servidor» puede terminar en «reinicié el servicio»: una sorpresa costosa en un entorno de producción.

Límite explícito; iniciativa del agente; separación entre evaluación y ejecución.

"Primero, solo evalúa. No modifiques archivos, no reinicies servicios, no crees una rama, no edites la configuración ni ejecutes comandos destructivos. Entrega un diagnóstico con evidencias. Después, indica exactamente qué cambios recomiendas y por qué."

Divide el proceso en dos etapas explícitas —evaluar y luego recomendar— antes de que ocurra cualquier acción real.

Evaluación sin acción; diagnóstico con evidencia; recomendación separada de la ejecución.

En una auditoría de seguridad real: pide un nivel alto de profundidad solo para el análisis de riesgos (consejo 3), pero fija la ejecución con «solo evalúa, no cambies nada» (consejo 4): el agente analiza a fondo y aun así no toca producción sin permiso.

La profundidad sin límite es un riesgo; el límite sin profundidad lleva a un análisis superficial: ambos consejos se complementan.

Profundidad acotada por un límite; auditoría segura; pensar a fondo sin actuar por cuenta propia.

Errores comunes: pedir la máxima profundidad en todas las tareas por costumbre; dejar «evalúa el sistema» sin decir qué no puede tocar; confundir evaluación con autorización para ejecutar.

Lista de verificación rápida: ¿la profundidad solicitada coincide con la complejidad real? ¿Los límites de acción están explícitos antes de cualquier análisis técnico?

Lista de verificación previa al prompt; hábito de profundidad máxima; límite explícito antes del análisis.

Nunca aceptes un «listo» sin pruebas: en código, automatización, bases de datos, deploy o documentos, el modelo tiene que demostrar lo que hizo.

Sin exigir pruebas, es fácil recibir un informe de estado atractivo que no refleja lo que realmente ocurrió.

Evidencia real; prueba ejecutada; registro/salida verificable.

"Antes de decir que algo está listo, confírmalo con evidencia real: una prueba ejecutada, un archivo modificado, un registro, la salida de un comando o un resultado verificable. Si no se verificó, di claramente: 'no verificado'. Si falló, muestra el error. Si omitiste un paso, dilo."

Transforma "confío en la respuesta" en "verifico la evidencia": funciona en cualquier ámbito, no solo en código.

"No verificado" explícito; error mostrado, no oculto; paso omitido declarado.

En lugar de dar una sola respuesta, analiza el mismo problema desde varios enfoques especializados: estrategia, producto, comunicación, tecnología y una perspectiva escéptica que busca fallas.

Es útil para evaluar ideas, ofertas, productos, proyectos y campañas; la consolidación final es más sólida que un análisis de una sola ronda.

Estructura de roles; agente escéptico; consolidación con prioridades.

"Usa una estructura de subagentes: el Agente 1 analiza la estrategia y el posicionamiento. El Agente 2 analiza el producto y el recorrido del usuario. El Agente 3 analiza el contenido y la comunicación. El Agente 4 analiza la tecnología y la automatización. El Agente 5 actúa como escéptico y busca fallas. Después, consolida todo en una recomendación única, con prioridades."

Es la plantilla lista para evaluar cualquier decisión compleja desde varias dimensiones a la vez.

5 roles fijos; una sola recomendación consolidada; prioridad explícita.

El Agente 5 (escéptico) de la estructura de subagentes es, en la práctica, el mecanismo de verificación real aplicado a las decisiones: existe para rechazar un «listo» demasiado fácil y exigir pruebas antes de la recomendación final.

La verificación no es solo para código: el papel de escéptico dentro de los subagentes aplica el mismo principio a decisiones de producto y estrategia.

Escéptico como verificador; evidencia antes de recomendar; rol dedicado a cuestionar.

Errores comunes: aceptar «listo» sin pedir evidencia; usar solo 1 perspectiva para una decisión compleja; saltarse al agente escéptico por pensar que retrasa el resultado.

Lista de verificación rápida: ¿hay pruebas concretas de que está "listo"? ¿La decisión se evaluó desde más de una perspectiva? ¿La voz escéptica tuvo cabida en la síntesis final?

Lista de verificación previa a la aceptación; múltiples perspectivas; voz escéptica en la síntesis.

El uso más potente de Fable 5 no es escribir el prompt perfecto de una sola vez, sino mantener una memoria continua del proyecto: posicionamiento, público objetivo, ofertas, tono de voz, errores que hay que evitar, decisiones confirmadas y prompts validados, cada uno en un archivo.

Sin memoria, cada sesión empieza desde cero y repite los mismos errores que ya se habían corregido.

Memoria del proyecto; estructura de carpetas por tema; decisión confirmada vs. hipótesis.

"Cada vez que aprendamos algo importante sobre este proyecto, regístralo en la memoria. Formato: decisión o lección; por qué importa; dónde aplicarla; qué evitar; fecha. No dupliques información. Actualiza la nota existente cuando sea necesario."

Transforma la memoria en un hábito automático de la sesión, no en una tarea manual que se olvida.

Registro estructurado con fecha; prevención de duplicados; actualización de una nota existente.

En tareas largas, el modelo puede detenerse antes de tiempo o terminar con una promesa en lugar de ejecutar; hay que dejar explícito que debe continuar cuando ya tiene lo que necesita.

Es útil para código, documentación, planificación y creación de contenido: cualquier tarea larga en la que detenerse a mitad de camino genera trabajo repetido.

Ejecutar en lugar de prometer; detenerse solo cuando sea necesario; acción destructiva como excepción.

"Si ya tienes suficiente información, ejecuta. No termines con una promesa, un plan o una pregunta genérica. Detente solo si necesitas información que únicamente yo puedo proporcionar o si la acción es destructiva o irreversible."

Cierra el ciclo de «lo haré después», que bloquea sesiones largas sin necesidad real de hacer una pausa.

Criterio de detención explícito; acción irreversible como única excepción; fin de las «promesas vacías».

La memoria del proyecto es precisamente la "información suficiente" que permite al agente ejecutar sin detenerse: cuanto más completa sea la memoria, menos motivos legítimos tendrá el agente para parar antes de tiempo.

Los dos consejos forman un ciclo: una memoria bien mantenida reduce las pausas innecesarias y cada ejecución genera una nueva lección para la memoria.

La memoria como combustible para la ejecución; ciclo memoria-acción-lección.

Errores comunes: nunca registrar aprendizajes en la memoria; dejar que el agente se detenga por la costumbre de pedir confirmación; duplicar una nota en vez de actualizar la existente.

Lista de verificación rápida: ¿se registró la lección de esta sesión? ¿El agente ejecutó la tarea o solo la prometió? ¿La memoria no tiene duplicados?

Lista de verificación para cerrar la sesión; registro frente a olvido; nota duplicada.

Evalúa la claridad, la conversión y el impacto de pantallas, páginas, PDF y piezas visuales compartiendo una captura o imagen; no te limites a pedir «hazlo más bonito».

La revisión visual estructurada señala un problema específico y concreto, en vez de dar una opinión estética vaga.

Revisión visual estructurada; primera impresión; generación de dudas frente a deseos.

"Analiza esta captura o imagen. Compárala con el objetivo: lograr que una persona entienda rápidamente el valor de la propuesta. Di: dónde se detiene la mirada primero; qué resulta confuso; qué genera interés; qué genera dudas; qué eliminar; qué cambiar para aumentar la conversión."

Cada pregunta exige una respuesta concreta y comprobable, en lugar de un «está bien» genérico.

6 preguntas de revisión visual; recorte frente a adición; conversión como criterio.

En seguridad, pedir una revisión defensiva en lugar de exploración o ataque evita una respuesta bloqueada y mantiene el foco en la protección.

La forma de plantear la pregunta cambia si recibes ayuda de verdad o una negativa, aunque preguntes por la misma vulnerabilidad.

Enfoque defensivo; rechazo evitable; foco en la protección.

"Analiza mi código de servidor como una revisión defensiva. Busca errores, validaciones faltantes, problemas de autorización, exposición accidental de datos, fallas de configuración y riesgos operativos. No crees exploits. No muestres instrucciones paso a paso para atacar. Solo indica el riesgo, el archivo afectado, la causa probable y la corrección defensiva."

Es, literalmente, la estrategia práctica para evitar que se active la categoría de rechazo «cyber» durante una revisión legítima de seguridad.

Sin exploit; riesgo + causa + corrección; rechazo evitado mediante el encuadre.

En el lanzamiento de un producto: usa la revisión visual (consejo 9) en la landing/impresión antes de publicar, y la revisión defensiva (consejo 10) en el backend que respalda el formulario; así cubres la experiencia y la seguridad de la misma funcionalidad.

Los dos consejos juntos cubren «lo que ve el usuario» y «lo que protege lo que no ve»: la seguridad nunca es solo código y la UX nunca es solo estética.

Revisión de experiencia + revisión de riesgos; cobertura completa de una funcionalidad.

Errores comunes: pedir «hazlo más bonito» sin un criterio de conversión; plantear una revisión de seguridad como una solicitud de exploit o ataque; revisar solo la pantalla y olvidarse del backend.

Lista de verificación rápida: ¿están respondidas las 6 preguntas de la revisión visual? ¿La revisión de seguridad está planteada como defensiva? ¿Se cubrieron la pantalla y el servidor?

Lista de verificación previa a la publicación; enfoque correcto; cobertura de pantalla y servidor.

"Revisa mi app todos los días" es un ciclo débil: un buen ciclo necesita un enfoque (un área pequeña), criterios (basados en la memoria), pruebas y un aprendizaje registrado en cada ciclo.

Repetir sin criterio consume presupuesto y no mejora nada de forma medible; un ciclo con verificación sí mejora de verdad, ciclo tras ciclo.

Ciclo débil frente a ciclo sólido; enfoque en cada ciclo; criterio guardado en la memoria.

"En cada ciclo: 1) elige un área pequeña del sistema; 2) analízala según los criterios ya guardados en la memoria; 3) propone una mejora; 4) impleméntala solo si es segura y reversible; 5) ejecuta una prueba; 6) pídele al verificador que intente encontrar errores; 7) registra lo aprendido."

Cada paso del ciclo tiene un propósito específico; saltarse alguno (generalmente el 6 o el 7) es el motivo más común por el que el ciclo no avanza.

7 pasos del loop; cambio seguro y reversible; verificador dedicado.

No dependas solo del historial del chat: crea un archivo, una base de datos o documentación de apoyo que sobreviva al final de la sesión.

El historial del chat desaparece o se vuelve demasiado largo para ser útil; la memoria externa es lo que permite trabajar durante semanas, no solo en una sesión.

Memoria externa; persistencia más allá de la sesión; documentación de apoyo.

Público objetivo, tono de comunicación, ofertas, campañas que funcionaron, reglas técnicas, decisiones estratégicas, errores recurrentes, procesos de trabajo, prompts validados, estándares de calidad.

Es la lista de referencia para decidir qué vale la pena registrar: evita una memoria vacía o con demasiado ruido.

Categorías de memoria externa; estándar de calidad registrado; error recurrente documentado.

El paso 7 del ciclo («registra la lección aprendida») es exactamente donde el ciclo alimenta la memoria externa. Sin memoria externa, el ciclo vuelve a aprender lo mismo en cada iteración.

Los dos consejos cierran un ciclo virtuoso: el ciclo genera una lección, la memoria externa la guarda y el siguiente ciclo parte de un criterio más sólido.

Ciclo virtuoso de bucle y memoria; criterio que mejora con cada ciclo.

Errores comunes: un loop sin un enfoque definido («revisa todo»); saltarse el paso del verificador; depender solo del chat para un trabajo que dura semanas.

Lista de verificación rápida: ¿el ciclo tiene un enfoque acotado y un criterio guardado? ¿Se ejecutó el verificador? ¿La lección pasó a la memoria externa y no quedó solo en el chat?

Lista de verificación del ciclo; enfoque acotado; lección fuera del chat.

Los 12 consejos resumidos: tarea correcta, motivo explícito, profundidad calibrada, límite antes de actuar, verificación real, subagentes especializados, memoria del proyecto, continuar hasta terminar, perspectiva para interfaces, revisión defensiva, ciclo con verificación, memoria externa.

Sirve como referencia rápida para consultar antes de escribir cualquier nuevo prompt de trabajo.

Hoja de referencia de los 12 consejos; consulta rápida antes de escribir un prompt.

El prompt genérico completo que combina contexto, objetivo, modo de trabajo (subagentes, evidencia antes de afirmar, ejecución en vez de promesas, memoria del proyecto) y tarea, listo para pegar al inicio de cualquier proyecto nuevo.

Es el bloque de código más grande del módulo: la versión condensada de todo lo que enseñó la ruta, lista para copiar y adaptar.

Prompt maestro; modo de trabajo declarado; primer siguiente paso.

Cambia siempre: el párrafo de contexto y la tarea final, específicos de tu proyecto. Mantén siempre: los 7 elementos del modo de trabajo: son la parte que hace que el prompt funcione como agente, no como chat.

Evita reescribir el prompt desde cero en cada proyecto: solo cambia la parte específica.

Parte variable vs. parte fija; reutilización entre proyectos.

"El valor de Fable 5 no está en responder mejor. Está en trabajar mejor. La forma débil de usarlo es pedir respuestas. La forma sólida es crear un sistema con contexto, memoria, subagentes, verificación y ejecución continua. Quien use el modelo solo como chat obtendrá mejores respuestas. Quien lo use como sistema de trabajo tendrá una ventaja real."

Es la tesis central de la ruta 2: los 12 consejos anteriores existen para salir del chat y entrar en el sistema de trabajo.

Chat frente a sistema de trabajo; ventaja real; ejecución continua.

Mapa rápido de cruce: 2.2→1.6 y 1.3 (esfuerzo y límites), 2.3→1.4 y 1.7 (verificación y subagents), 2.4→1.7 y 1.4 (memoria y anti-overplanning), 2.5→1.6 (categoría cyber), 2.6→1.4 (verificación por subagent): para quienes quieren profundizar en el lado oficial/técnico de cada consejo.

Muestra que la ruta 2 no está aislada: cada consejo práctico tiene una raíz técnica/oficial en la ruta 1 para quien quiera profundizar.

Mapa de cruce entre la ruta 1 y la ruta 2; práctico vs. oficial/técnico.

Lista de verificación que combina las técnicas oficiales del módulo 1 (contexto, indicaciones negativas, límites, prueba de finalización, concisión, niveles de esfuerzo, subagentes/memoria) con los 12 consejos prácticos del módulo 2, en una sola hoja de referencia para todo el curso.

Cierra el curso con una sola referencia: no hace falta recordar en qué ruta estaba cada técnica.

Lista de verificación única del curso; ~19 técnicas combinadas; referencia de cierre.