Al construir sistemas que utilizan modelos de lenguaje, es tentador resolverlo todo desde el prompt. Pero cuando se trata de reglas de negocio, decisiones repetibles o requisitos de auditoría, lo correcto es separar las responsabilidades: el texto lo maneja el LLM, pero las reglas deben residir fuera.

1. Separación de preocupaciones: texto vs reglas

Los LLMs son excelentes generadores de lenguaje, pero no están diseñados para aplicar lógica de negocio de forma fiable, explicable o reproducible. Por eso, las decisiones que afecten el comportamiento de un sistema deben:

• Usar datos estructurados como fuente de verdad.
• Ser ejecutadas por código determinista (fuera del modelo).
• Ser trazables, testeables y versionadas.

2. Diseño del blackboard / estado

El estado es una estructura persistente, en formato JSON o equivalente, que refleja el contexto actual del usuario o sesión:

• Preferencias declaradas.
• Flags de control.
• Resultados previos.

Debe ser accesible por las herramientas y por el LLM (si es relevante para generar lenguaje), pero siempre manteniendo un contrato explícito.

El estado se consulta, no se reinventa.

3. Algoritmos deterministas como tools

Las decisiones basadas en estado deben implementarse como herramientas externas (tools) con entradas y salidas claras. Ejemplo:

{
  "input": {
    "prefs": {"mode": "safe"},
    "question": "¿Puede el usuario acceder a X?"
  },
  "output": {
    "decision": false,
    "reason_code": "PREF_SAFE_MODE_RESTRICTS"
  }
}

Esto permite:

• Encapsular lógica compleja.
• Validar con tests.
• Justificar decisiones con códigos y trazas.

4. Versionado y trazabilidad

Todo estado debe tener una versión de esquema. Los cambios deben quedar registrados con:

• Timestamp.
• Identificador de cambio.
• Autor (si aplica).

Esto facilita migraciones, debugging y soporte de múltiples versiones.

5. Validación y post-proceso

Al guardar o usar el estado:

• Validar contra un esquema JSON versionado.
• Aplicar normalización o limpieza si es necesario.
• Loguear cambios de forma estructurada.

Tabla de ejemplo: estructura del estado

Campo	Tipo	Origen	Versión	Última actualización
userPrefs.mode	String	Usuario	v1.2	2025-08-28
flags.beta	Boolean	Sistema	v1.0	2025-08-25
history	Array	Interacciones	v1.3	2025-08-27

Checklist técnico

• Esquema versionado y validado.
• Migraciones entre versiones.
• Tests unitarios de herramientas.
• Códigos de decisión justificables.

Preguntas frecuentes

• ¿Cuánto meter en el estado y cuánto dejar en el prompt?

  • Todo lo que sea estructurado, persistente o auditable debe ir al estado. El prompt es solo para comunicar, no para almacenar lógica.