Un buen prompt sigue siendo una instrucción desechable

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

Me pasó durante este experimento. Pedí analizar las métricas del día, recibí una conclusión convincente 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 era que la instrucción dependía de que yo recordara cuatro cosas antes de usarla:

1. Cuándo correspondía ejecutarlo.
2. Qué contexto debía entregarle.
3. Qué decisiones anteriores tenía que respetar.
4. Dónde debía guardar el resultado.

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

Un prompt resuelve el turno que tiene delante

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

Eso mejora la respuesta. No le da continuidad.

En la siguiente conversación hay que volver a explicar el objetivo, el estado actual, las reglas y lo que ya se decidió. Cuando el prompt se hace suficientemente largo para contener todo, aparece otro problema: 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 fue convertir tareas en comandos

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

Por ejemplo, cerrar un día de experimento dejó de ser “mira estos números y dime qué piensas”. 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ó variaciones de proceso. Todavía faltaba algo: el comando sabía cómo trabajar, pero no sabía nada del experimento concreto.

El segundo salto fue 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 un prompt guardado nunca hizo 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. 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. Las revisiones crean historia fechada. Las fuentes canónicas cambian solo cuando cambia un hecho.

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. Un sistema persistente también acumula errores persistentes.

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

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. Un buen prompt sin sistema 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. Un sistema puede mostrar 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 no era el prompt. Era el contexto de decisión que permite ejecutarlo sin reconstruir 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.