El system prompt de Claude Fable 5 apunta a la era del agent harness

Las notas oficiales de Claude sobre system prompts publicadas por Anthropic merecen leerse no porque revelen un truco mágico, sino porque muestran una dirección de producto. La página publica instantáneas fechadas de los prompts centrales usados por la interfaz web de Claude (claude.ai) y las apps móviles iOS/Android. Anthropic es explícita sobre el límite: estas actualizaciones no se aplican a la API de Claude. Esa distinción importa. No deberíamos tratar la página como un prompt de API, ni como una licencia para copiar u operacionalizar texto privado de prompts.

Lo que la página sí muestra es un cambio sostenido en aquello para lo que se está preparando a un modelo de frontera. Los prompts se parecen cada vez menos a una ficha de personalidad de chatbot y cada vez más a un manual operativo para agentes: cómo usar herramientas, cuándo aclarar, cómo citar, cómo manejar archivos, cómo comportarse cerca de límites de seguridad, cómo recuperarse de la incertidumbre y cómo trabajar dentro de una superficie de producto.

Ilustración editorial de un manual operativo convirtiéndose en carriles de workflow para agentes

Figura 1: la tendencia del system prompt se mueve de “responder al usuario” a “operar con seguridad dentro de un banco de trabajo”.

Debe usarse el nombre oficial Claude Fable 5. Su ID de modelo de API es claude-fable-5. Anthropic también habla de Claude Mythos 5 (claude-mythos-5), pero no conviene mezclar ambos sin cuidado. Claude Fable 5 es el modelo generalmente disponible; Mythos 5 tiene disponibilidad restringida. Para este artículo, lo importante no es el marketing del modelo. Es que el prompt más reciente de la interfaz de chat de Claude funciona como señal de un cambio más amplio de la industria: se espera que el modelo forme parte de un harness.

De asistente mejorado a manual operativo

Una forma útil de leer la progresión de Opus a Fable es verla como una evolución del entorno operativo esperado.

Esa progresión es sutil, pero importante. Los prompts de asistentes anteriores trataban sobre todo de la calidad de la respuesta: ser útil, seguro, preciso y seguir la intención del usuario. El patrón más nuevo trata de la ejecución del trabajo. Asume que Claude puede operar en un lugar donde existen herramientas, los archivos tienen estado, el historial importa, las citas deben manejarse con cuidado y algunas acciones requieren rechazo o aprobación.

Eso es exactamente lo que ocurre cuando la IA pasa de “compañero de conversación” a “participante del trabajo”. Un compañero de conversación puede responder una pregunta y desaparecer. Un participante del trabajo necesita escritorio, memoria, calendario, archivador, una forma de pedir permiso, un lugar donde dejar entregables y una manera de que los humanos auditen lo ocurrido.

El cambio entre actuar y aclarar

Uno de los cambios más significativos en la dirección de Opus 4.7 es el equilibrio entre actuar y aclarar. Muchos workflows tempranos de IA fallaban de una forma aburrida: el modelo pedía aclaración incluso cuando el siguiente paso era obvio. Un usuario podía pedir: “Redacta un plan de lanzamiento a partir de estas notas”, y el asistente se detenía para preguntar por tono, audiencia o calendario antes de producir algo útil.

La aclaración sigue siendo necesaria. Si una decisión cambia el alcance, el riesgo, el costo, la exposición legal o una acción externa, el modelo debe preguntar. Pero si el detalle faltante es pequeño, reversible o inferible, un agente competente debe avanzar con una suposición y marcarla con claridad.

Esto suena a consejo de redacción, pero en realidad es diseño de harness. El entorno correcto debe permitir que el modelo avance en fases de bajo riesgo y se detenga en puntos de control de alto riesgo. Por ejemplo:

• Redactar el plan ahora, pero preguntar antes de enviarlo a clientes.
• Inspeccionar el repositorio ahora, pero preguntar antes de editar archivos.
• Reunir fuentes públicas ahora, pero señalar afirmaciones inciertas antes de publicar.
• Preparar una propuesta de migración de base de datos ahora, pero exigir aprobación antes de ejecutarla.

Una ventana de chat puede expresar esta política con palabras. Un harness puede imponerla en el workflow.

El cambio hacia el descubrimiento de herramientas

La dirección de Opus 4.8 deja otro punto claro: el modelo debe descubrir su entorno antes de darse por vencido. Si hay disponible un navegador, lector de archivos, herramienta de hojas de cálculo, parser de PDF, ejecutor de código o analizador de imágenes, el modelo debe usar esa superficie disponible en lugar de fingir que la conversación es todo lo que tiene.

Esto cambia la definición de “inteligencia”. Un modelo que dice “no puedo acceder al archivo” puede tener razón en una interfaz y estar equivocado en otra. La capacidad práctica del modelo ahora es la suma de:

1. su capacidad de razonamiento,
2. las herramientas expuestas a él,
3. los permisos concedidos a esas herramientas,
4. el estado preservado entre pasos,
5. la superficie de Artifact donde los resultados pueden inspeccionarse.

Por eso importa la expresión agent harness. El harness no es decorativo. Es el sistema que da al modelo ojos, manos, memoria, límites y canales de salida. Sin él, incluso un modelo potente puede convertirse en un pasajero inusualmente elocuente dentro de una pequeña caja de chat.

Línea de tiempo dibujada a mano desde el comportamiento de asistente de chat hasta un manual operativo completo para agentes

Figura 2: la evolución del prompt apunta de una asistencia más rica a una operación estructurada: actuar, descubrir herramientas, preservar estado y producir Artifacts.

Por qué la era del harness no es solo “mejor chat”

El cambio importante de la industria no es que los modelos puedan escribir respuestas más largas. Es que se espera cada vez más que participen en bucles de trabajo más largos. Un bucle real tiene estado y riesgo.

Pensemos en una tarea de programación. El usuario no necesita un párrafo afirmando que el bug está arreglado. Necesita un parche, la salida de las pruebas, un resumen de archivos modificados y una nota de revisión. Pensemos en un informe de mercado. El usuario no necesita una síntesis segura de sí misma sin trazabilidad. Necesita fuentes fechadas, citas, diferencias respecto al informe anterior y un lugar donde actualizar el briefing la semana siguiente. Pensemos en operaciones basadas en navegador. El usuario no necesita una promesa de que se descargó un reporte. Necesita el archivo, la carpeta, una lista de excepciones y un registro de qué pasos fueron automatizados y cuáles se manejaron manualmente.

Una sola UI de chat tiene dificultades con esto porque carece de varias cosas que el trabajo requiere:

• Estado externo: ¿qué ya se leyó, cambió, descargó o decidió?
• Puntos de control por etapa: ¿dónde debe detenerse el trabajo para aprobación o redirección?
• Límites de permisos: ¿qué acciones son de solo lectura, reversibles, externas, destructivas o costosas?
• Recuperación: si la tarea falla a mitad de camino, ¿puede reanudarse sin reiniciar a ciegas?
• Ciclo de vida del Artifact: ¿dónde vive el resultado final cuando el chat se desplaza fuera de la vista?
• Aislamiento paralelo: ¿pueden investigación, redacción, pruebas y revisión ocurrir en flujos separados sin contaminarse?
• Observabilidad: ¿puede una persona inspeccionar fuentes, acciones, costos, fallos y supuestos?

Estos no son detalles de prompt engineering. Son detalles de superficie operativa.

Cómo MCPlato sostiene esta tendencia

MCPlato se entiende mejor como un espacio de trabajo de IA y una superficie operativa para agentes, no simplemente como otra caja de respuestas. Su vocabulario de producto encaja de forma natural con la dirección sugerida por los system prompts más recientes de Claude.

Sprite es el coordinador. Cuando una tarea tiene múltiples fases o especialistas, un Sprite puede descomponer el trabajo, delegarlo a sesiones, seguir el progreso y volver a unir las piezas. Esto importa porque las tareas largas rara vez caben en una sola cadena de pensamiento ininterrumpida.

Wand es un workflow empaquetado con estado. En lugar de pedir a una IA que improvise el mismo proceso cada vez, un Wand puede definir fases, compuertas, recursos acotados y Artifacts esperados. El resultado se parece más a una app de trabajo repetible que a una plantilla de prompt.

Artifact es el punto final duradero. La salida no debería quedar atrapada en un muro de texto de chat. Debe convertirse en un informe, parche, presentación, hoja de cálculo, carpeta, memo de decisión, registro de QA u otro objeto inspeccionable.

Skill y Distill Skill preservan el saber hacer. Cuando un workflow funciona, las partes reutilizables deben quedar disponibles otra vez. Así es como un equipo pasa de prompts heroicos aislados a una práctica operativa compartida.

ClawMode y Scheduled Tasks extienden el trabajo a lo largo del tiempo. Algunas tareas valiosas no son inmediatas: un briefing semanal de investigación, un escaneo nocturno de repositorio, una pipeline recurrente de contenido o un seguimiento cuando aparece nueva información.

Las compuertas de permisos y aprobación mantienen la autonomía acotada. MCPlato no debería presentarse como automatización ciega. El mejor principio es autonomía controlada: dejar que la IA avance cuando la acción es de bajo riesgo y exigir aprobación humana cuando la acción cambia archivos, envía mensajes, toca sistemas externos o crea riesgo de negocio.

Channels e IM bridges vuelven asíncrona la interacción. Un usuario debería poder delegar una tarea desde un chat de equipo, recibir actualizaciones de progreso y revisar el Artifact final sin vigilar una ventana de chat en primer plano.

El estado de workspace local-first mantiene materiales, estado y resultados cerca del trabajo del usuario. Eso no elimina todas las preocupaciones de privacidad o seguridad, pero cambia la postura: el workspace es donde se organiza, revisa y gobierna el contexto.

En resumen, MCPlato da a los modelos el tipo de entorno que sus instrucciones operativas más recientes presuponen cada vez más: herramientas, archivos, memoria, permisos, fases, Artifacts y puntos de control humanos.

Ilustración editorial plana de un workspace harness con Artifacts, calendarios, aprobaciones y carriles de sesión

Figura 3: un harness convierte la capacidad del modelo en bucles de trabajo observables, con permisos y centrados en Artifacts.

Cuatro ejemplos concretos

1. De issue de código a parche y a Artifact de QA

Un usuario deja un issue de GitHub en MCPlato y pide una corrección. En un flujo solo de chat, el asistente puede saltar directamente a sugerencias. En un flujo con harness, la tarea se convierte en trabajo por etapas:

1. leer el issue y el contexto del repositorio,
2. redactar un plan de alcance limitado,
3. preguntar antes de editar si el cambio es riesgoso,
4. crear el parche,
5. ejecutar las comprobaciones acordadas,
6. producir un Artifact de QA con archivos modificados, salida de pruebas, riesgos no resueltos y notas de revisión.

El comportamiento de Claude entre actuar y aclarar encaja bien aquí. El agente no debe hacer preguntas innecesarias antes de leer el issue, pero debe detenerse antes de cambios amplios o destructivos.

2. Briefing de investigación programado con citas

Un briefing semanal de investigación no es una respuesta única. Es un bucle recurrente: reunir fuentes aprobadas, deduplicar, comparar con la semana anterior, resumir cambios, citar cada afirmación concreta y entregar el reporte. Scheduled Tasks y Artifacts de MCPlato hacen persistente la salida; channels hacen asíncrona la entrega; Skills hacen reutilizable el formato.

La instrucción de citar fuentes a nivel de prompt se vuelve más valiosa cuando el workspace puede conservar juntas la lista de fuentes y el Artifact del briefing.

3. Workflow de navegador y documentos

Imaginemos un equipo financiero que debe descargar reportes desde un portal web, combinarlos con hojas de cálculo y producir un resumen mensual. Un buen agente no debería afirmar acceso universal a todos los sitios. Debe respetar los límites de inicio de sesión, pedir al usuario que maneje MFA, descubrir si existe una exportación o API, automatizar solo los pasos aprobados y repetibles, validar conteos de archivos y producir un reporte de excepciones.

Esa es la diferencia entre “la IA puede usar un navegador” y “la IA puede operar dentro de un bucle controlado de navegador/documentos”.

4. Aprobación de acciones arriesgadas

Supongamos que un agente redacta un correo para clientes, prepara un comando que cambia datos de producción o propone eliminar una carpeta. El modelo puede entender la instrucción, pero entender no es tener autoridad. Un harness debe convertir ese paso en un punto de aprobación: mostrar la acción prevista, el efecto esperado, el plan de reversión y la evidencia, y luego esperar.

Aquí seguridad y productividad se refuerzan entre sí. El usuario no necesita ralentizar cada paso de solo lectura. Sí necesita una compuerta clara antes de una acción irreversible o visible externamente.

Qué significa esto para quienes construyen productos

Para quienes construyen productos de IA, las notas de Anthropic sobre system prompts son una señal de diseño útil. No pregunten solo: “¿qué modelo es más inteligente?”. Pregunten también:

• ¿En qué entorno cree el modelo que está operando?
• ¿Puede el producto exponer herramientas sin difuminar permisos?
• ¿Puede el workflow continuar en el tiempo sin perder estado?
• ¿Puede el usuario inspeccionar lo ocurrido?
• ¿Puede el resultado final vivir como Artifact, no como transcripción?
• ¿Puede el sistema detenerse en los momentos correctos en lugar de preguntar demasiado o actuar con demasiada libertad?

La respuesta no vendrá solo de un system prompt más largo. Un prompt puede describir comportamiento, pero el producto debe proporcionar la superficie que vuelve confiable ese comportamiento.

Esa es la era del harness: los modelos se vuelven más capaces, pero la capacidad solo se vuelve útil cuando está rodeada de estado, herramientas, recuperación, aprobaciones y Artifacts.

Conclusión

El snapshot del system prompt de Claude Fable 5 es interesante porque apunta más allá de la capacidad del modelo. Muestra la forma del entorno que los modelos modernos se están preparando para habitar. La frontera ya no es solo “mejor chat”. Es trabajo de agentes: con estado, consciente de herramientas, sujeto a permisos, atento a citas, recuperable y centrado en Artifacts.

MCPlato está construido para esa dirección. La coordinación con Sprite, los Wands, los Artifacts, los Skills reutilizables, el trabajo programado, los channels, el estado de workspace local-first y las compuertas de aprobación no son decoración alrededor de un modelo. Son la superficie operativa que permite que un modelo potente se convierta en un participante útil del trabajo real.

El modelo sigue siendo el motor. El harness convierte ese motor en un vehículo que las personas pueden conducir, inspeccionar, reparar y confiar.

Referencias

1. Anthropic docs, System Prompts release notes.
2. Anthropic docs, Introducing Claude Fable 5 and Claude Mythos 5.