Un buen prompt sigue siendo una instrucción desechable

Un prompt puede darme un buen resultado hoy y fallar mañana sin que yo cambie una sola palabra.

Me pasó durante este experimento. Pedí analizar las métricas del día, recibí una conclusión convincente, la anoté, y horas después los mismos datos la refutaron. El texto del prompt seguía intacto. Lo que había cambiado era el estado del mundo.

El problema real era que esa instrucción dependía de que yo me acordara de cuatro cosas antes de usarla: cuándo correspondía ejecutarla, qué contexto debía entregarle, qué decisiones anteriores tenía que respetar y dónde debía guardar el resultado.

Si olvidaba una sola, el agente producía una respuesta perfectamente razonable para una situación que no existía.

”Con un prompt bien escrito basta”

Un prompt puede pedir una revisión de arquitectura, analizar las métricas del día o preparar una decisión, y puede incluir rol, formato, restricciones y ejemplos.

Todo eso mejora la respuesta y no le da ninguna continuidad.

En la siguiente conversación hay que volver a explicar el objetivo, el estado actual, las reglas que aplican, lo que ya se decidió y por qué se decidió así, y todo eso antes de poder pedir lo que ibas a pedir. Y cuando el prompt se hace suficientemente largo para contener todo eso aparece otro problema, que es que mezcla instrucciones permanentes con datos que envejecen.

Una regla de seguridad y la cifra de suscriptores de hoy no deberían vivir en el mismo bloque. Una cambia poco. La otra puede quedar falsa mañana.

El primer salto: convertir tareas en comandos

Tomé las tareas que repetía y les di una entrada, un procedimiento y una salida fija.

Cerrar un día de experimento, por ejemplo, dejó de ser “mira estos números y dime qué piensas”, que es una instrucción que depende enteramente de mi humor al escribirla. El comando define qué fuentes consultar, qué métricas no estimar, cómo separar hechos de inferencias y dónde registrar la conclusión.

Eso eliminó las variaciones de proceso, y todavía faltaba algo: el comando sabía cómo trabajar, pero no sabía nada del experimento concreto.

El segundo salto: separar el contexto por función

En vez de construir un prompt cada vez más grande, repartí el contexto en archivos con responsabilidades distintas:

AGENTS.md          reglas de operación
ORCHESTRATOR.md    qué contexto cargar para cada solicitud
DOCTRINE.md        principios que cambian poco
ROADMAP.md         prioridades vigentes
campaigns/         objetivos, métricas y criterios de abandono
decisions/         decisiones difíciles de revertir
reviews/           historia fechada

El agente no recibe todo siempre: el orquestador decide qué cargar según la tarea. Una revisión diaria no necesita mis documentos financieros. Una decisión de inversión sí.

Esa separación hizo algo que ningún prompt guardado hizo nunca por mí. Permitió que el sistema rechazara una instrucción reciente cuando contradecía una decisión vigente.

La memoria útil también necesita caducidad

Guardar contexto no basta, y un dato viejo escrito con seguridad es más peligroso que no tenerlo.

Por eso el sistema distingue entre hechos, inferencias, supuestos y evidencia pendiente, cada revisión crea historia fechada que después se puede releer en orden, y las fuentes canónicas cambian solo cuando cambia un hecho y no cuando alguien tuvo una idea mejor un jueves.

La semana pasada aprendí el límite de esa idea. Mis archivos marcaban la calidad de una afirmación pero no siempre quién la había producido ni cuándo dejaba de ser confiable, y un sistema persistente también acumula errores persistentes.

La memoria ayuda cuando tiene procedencia, fecha y una regla para corregirse. Las tres, no una.

Tres capas, tres problemas distintos

Ahora uso esta distinción:

• Prompt: expresa lo que necesito en este turno.
• Comando: vuelve repetible una operación.
• Sistema: conserva contexto, decisiones e historia entre operaciones.

Ninguna capa reemplaza a la anterior. Un sistema sin buenos prompts produce respuestas mediocres de forma consistente, y un buen prompt sin sistema te obliga a reconstruir el mundo en cada conversación.

La diferencia práctica aparece cuando el agente encuentra una contradicción: un prompt intenta obedecer la última instrucción que recibió, y un sistema puede mostrarte qué regla se contradice, cuál es la fuente canónica y qué decisión tendría que cambiar antes de actuar.

La unidad reutilizable nunca fue el prompt. Era el contexto de decisión que permite ejecutarlo sin rearmar el mundo cada vez.

En la siguiente pieza voy a mostrar cómo se conectan estas capas en el sistema completo, qué partes se pueden reutilizar y cuáles exigen criterio propio.

Si quieres ver la primera capa, dejé gratis el CLAUDE.md comentado que uso como punto de partida: descargar el material.