🪜 No todas las tareas requieren el máximo
🧠 Piénsalo así: profundidad del análisis no es un «modo turbo» que activas siempre para garantizar la calidad. Es un control que calibras según la complejidad real de la tarea: usar el máximo en algo sencillo desperdicia tiempo y tokens sin ningún beneficio; usar el mínimo en una decisión costosa es el otro error, igual de común.
La guía práctica para usar Fable 5 como agente de trabajo resume esto en una escala de cuatro niveles. Cada nivel no es una configuración técnica, sino una instrucción que tú mismo escribes en el prompt para indicarle al agente cuánto vale la pena deliberar antes de darte la respuesta.
La escala funciona mejor cuando preguntas antes de escribir el prompt: "si esta respuesta sale mal, ¿qué pierdo?" Cuanto mayor sea la respuesta a esa pregunta, más alto debería ser el nivel que pidas.
| Nivel | Cuándo usar | Ejemplos de la guía |
|---|---|---|
| Baja | Tarea mecánica, con bajo riesgo de error | Resumen, leyenda, ajuste de texto, ideas rápidas |
| Media | Organizar o comparar opciones | Planificación sencilla, comparación, revisión de contenido |
| Alta | Decisión que sale cara si resulta equivocada | Estrategia, arquitectura, auditoría, decisión de producto, revisión técnica |
| Máxima | Error costoso o irreversible | Problemas críticos, migración, seguridad, negocios complejos, análisis de riesgos |
Fuente: guía práctica del usuario sobre el uso de Fable 5 como agente de trabajo: prompt probado en la práctica, no una cita oficial de Anthropic.
La escala de 4 niveles: cada nivel aumenta el tiempo de razonamiento (línea cian discontinua): máxima destaca porque es el nivel que deberías reservar para cuando el error realmente cueste caro.
En una frase: 4 niveles (baja→máxima) calibrados según la pregunta "si sale mal, ¿qué pierdo?" — no por la costumbre de pedir siempre el máximo.
💻 El prompt: profundidad a medida
En lugar de confiar en que el agente adivine por sí solo el nivel adecuado, le dices explícitamente dónde concentrar el razonamiento profundo y dónde no hace falta. Así evitas el síntoma más común de dejar todo en «alto todo el tiempo»: soluciones más complicadas de lo que la tarea requería.
El prompt de abajo hace exactamente eso: separa la parte que merece profundidad (la decisión estratégica) de la que no la merece (la implementación en sí, que debe ser sencilla).
Use análise profunda apenas na parte estratégica. Não complique a solução. Não crie abstrações desnecessárias. Entregue a solução mais simples que resolve bem o problema. <isto você troca — cole junto o pedido real da tarefa>
🔗 Cruce con la Trilha 1
Esta calibración aplicada de profundidad refleja una técnica respaldada oficialmente por Anthropic: Fable 5 expone cinco niveles de esfuerzo configurables por llamada (low/medium/high/xhigh/max) mediante output_config.effort. Si trabajas directamente con la API, el Módulo 1.6 muestra el equivalente técnico de esta misma idea, incluida la pauta oficial para saber cuándo usar cada nivel.
En una frase: di dónde se necesita un razonamiento profundo — para el resto, pide algo simple.
⚠️ Demasiada iniciativa es un riesgo
Un modelo potente no es cauteloso por defecto: es capaz por defecto. Esto significa que, ante una solicitud ambigua, Fable 5 tiende a llenar los vacíos por su cuenta: si le pediste que "resolviera el problema", puede decidir por sí mismo qué cuenta como resolverlo y actuar.
Esto es excelente cuando quieres que continúe hasta completar una tarea clara. Es peligroso cuando la tarea tiene ambigüedad sobre qué puede modificar — archivos, servicios, configuración, datos de producción.
⚠️ Escenario común
Tú pides: "analiza y resuelve el problema de rendimiento del servicio". Sin un límite explícito, un agente capaz puede interpretar «resolver» como permiso para reiniciar el servicio en producción, cambiar la configuración o hacer deploy, todo sin preguntarte antes, porque técnicamente cumplió lo que pediste.
✓ Qué HACER
- ✓Decir explícitamente lo que él no puede avanzar antes de pedir análisis o ejecución.
- ✓Separar la fase de diagnóstico de la fase de acción en tareas sensibles.
- ✓Tratar "resuelve esto" como una solicitud incompleta hasta que definas los límites.
✗ Qué EVITAR
- ✗Pedir «resuelve esto» o «encárgate de esto» sin decir qué queda fuera de los límites.
- ✗Suponer que el agente preguntará antes de actuar: por lo general, actúa.
- ✗Confundir «modelo potente» con «modelo cauteloso»: son cosas diferentes.
En una frase: cuanto más capaz es el modelo, más explícito debe ser el límite antes de pedir un análisis técnico o una ejecución.
🚧 El prompt: evalúa primero, ejecuta después
La forma más confiable de fijar el límite del tema anterior es poner al agente en un modo de solo diagnóstico explícito: puede mirar, medir y concluir, pero no puede cambiar nada hasta que tú lo apruebes.
Primeiro apenas avalie. Não altere arquivos, não reinicie serviços, não crie branch, não edite configuração e não rode comandos destrutivos. Entregue um diagnóstico com evidências. Depois diga exatamente quais mudanças recomenda e por quê. <isto você troca — descreva o sistema ou problema a investigar>
La puerta separa los dos caminos: el diagnóstico (cian) siempre está permitido; la ejecución real (rojo) queda bloqueada hasta que apruebes explícitamente los cambios recomendados.
🔗 Cruce con la Trilha 1
Definir límites antes de dejar actuar al agente es literalmente la técnica de límites (negative prompting + boundaries) que la Ruta 1 documenta con respaldo oficial de Anthropic — decir explícitamente qué no debe hacer, en lugar de confiar solo en la descripción de lo que debe hacer.
Ver Módulo 1.3 — prompting negativo + límites →En una frase: "evalúa primero, ejecuta después" convierte el exceso de iniciativa en un diagnóstico útil, sin riesgo de acciones no deseadas.
🔗 Combinando ambas: auditoría bloqueada
Los dos consejos de este módulo no compiten entre sí: se complementan. El ejemplo más claro es una auditoría de seguridad: quieres profundidad alta (es una decisión que sale cara si se toma mal) e quiere el agente atascado en modo de solo diagnóstico (porque todavía no es momento de cambiar nada).
En la práctica, esto se convierte en un flujo de 5 pasos que repites para cualquier tarea sensible, no solo una auditoría de seguridad.
Define la tarea y el motivo de la profundidad alta
Di qué está en juego — por qué esta tarea merece el nivel «alto» y no «medio».
Declara el límite: solo diagnóstico en esta ronda
Indica explícitamente qué no se puede tocar: archivos, servicios, configuración, comandos destructivos.
Ejecuta y recibe el diagnóstico con evidencias
El agente investiga a fondo y entrega hallazgos verificables, ordenados por riesgo o impacto.
Revisa las recomendaciones
Tú decides qué tiene sentido aplicar: el agente ya dijo exactamente qué y por qué.
Aprueba los cambios en una ronda aparte
Solo ahora el agente ejecuta, y solo lo que aprobaste, no lo que le pareció mejor.
Haz una auditoría de seguridad completa <esto lo cambias tú: del sistema/proyecto>. Usa un análisis profundo: es una decisión que cuesta cara si sale mal. Pero en esta ronda, solo evalúa: no cambies archivos, no reinicies servicios, no edites la configuración ni ejecutes comandos destructivos. Entrega un diagnóstico con evidencias, ordenado por riesgo. Después di exactamente qué cambios recomiendas y por qué: aprobaré cada uno antes de que actúes.
En una frase: la profundidad alta decide qué tan a fondo el agente piensa; el modo de solo diagnóstico decide qué puede hacer con lo que pensó — ambas juntas ofrecen la auditoría más segura.
✅ Errores comunes + lista de verificación rápida
Antes de cerrar el módulo, aquí tienes una lista rápida para revisar los prompts que acabas de aprender: profundidad calibrada (Consejo 3) y límites explícitos antes de actuar (Consejo 4).
✓ Lista de verificación antes de enviar el prompt
- ✓Pregunté «si sale mal, ¿qué pierdo?» antes de elegir el nivel de profundidad.
- ✓Dijo explícitamente lo que el agente no puede avanzar, no solo determinar qué debe hacer.
- ✓Separé el diagnóstico de la ejecución en cualquier tarea que afecte la producción o los datos reales.
- ✓Pedí evidencia real en el diagnóstico, no una opinión genérica.
✗ Errores más comunes
- ✗Dejar todo con la profundidad máxima "para asegurarte", sin medir si compensa el tiempo y el costo.
- ✗Pedir «resuelve esto» sin decir qué queda fuera de los límites, y sorprenderte por lo que tocó el agente.
- ✗Mezclar diagnóstico y ejecución en la misma solicitud para una tarea sensible.
- ✗Aceptar "listo" sin pruebas: ese es un tema del siguiente módulo, pero conviene prevenirlo desde aquí.
💡 Consejo práctico: guarda los dos prompts de este módulo (profundidad calibrada + análisis seguro) en un archivo de plantillas. Los vas a reutilizar cada vez que pidas algo estratégico o algo que afecte un sistema — y pronto notarás que buena parte de las "sorpresas" con agentes potentes desaparece cuando estos dos hábitos se vuelven la norma.
En una frase: ajusta el esfuerzo, declara el límite — los dos hábitos que evitan la mayoría de los sustos con un agente capaz.
🧾 Resumen del Módulo
Próximo módulo:
2.3 — Verificación real + subagentes especializados.
Fuente de este módulo: guía práctica del usuario sobre el uso de Fable 5 como agente de trabajo (consejos 3 y 4): prompts probados en la práctica, no citas oficiales de Anthropic. Las referencias cruzadas con la Ruta 1 apuntan a contenido con respaldo oficial: platform.claude.com/docs/en/build-with-claude/effort · platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5