Cognitive Tools: Cuando tu Agente Piensa en Pasos, no en Saltos
Thinking Chains, Patterns y Decisions — tres herramientas que dan a los agentes de IA la capacidad de razonar de forma estructurada, aprender de errores pasados y documentar decisiones con trazabilidad. Todo sobre PDB, todo MIT.
Gonzalo Monzón
7 julio, 2026 · Serie: LUMEN Protocol — La Fundación (3/4)
TL;DR
Las Cognitive Tools de LUMEN resuelven el problema fundamental de los LLMs: no saben por qué hacen lo que hacen. Thinking Chains proporcionan razonamiento estructurado que persiste entre sesiones. Patterns acumulan experiencia institucional mediante TF-IDF sin necesidad de RAG. Decisions documentan la arquitectura como ADRs inmutables en PDB. Juntas convierten un agente que alucina en un sistema que reflexiona, aprende y decide. Todo MIT, todo sobre el transporte LUMEN.
La caja negra de los LLMs
Cuando trabajas con LLMs a diario, pronto descubres su talón de Aquiles: no saben por qué hacen lo que hacen.
Generan la respuesta correcta el 80% de las veces. Pero cuando fallan, no puedes preguntarles "¿por qué tomaste ese camino?" porque no hay camino. Hay una nube de probabilidades.
LUMEN resuelve esto con tres herramientas cognitivas que dan a los agentes la capacidad de razonar, recordar y decidir de forma estructurada.
Thinking Chains — Razonamiento que persiste
No es "chain of thought" prompt engineering. Es un sistema de razonamiento estructurado con cuatro propiedades que lo diferencian:
🧠 Persiste entre sesiones
La cadena de pensamiento sobrevive a la compresión de contexto. Puedes retomarla mañana desde donde la dejaste.
📊 Se puede evaluar
Cada paso se puntúa por especificidad, acción y concreción. Sabes qué pensamientos son sólidos y cuáles no.
🔄 Se puede revisar
Vuelves atrás, corriges, ramificas. No estás atado a la primera línea de razonamiento.
📝 Se puede resumir
Comprime 20 pensamientos en 3 manteniendo lo esencial. Ideal para inyectar en contexto sin saturar.
Ejemplo real — Una sesión de debugging multi-agente:
thought_1: "El usuario reporta que delegate_task devuelve timeout"
→ evaluado: específico, accionable (score: 8)
thought_2: "Puede ser por saturación del servidor MCP"
→ evaluado: hipótesis, necesita datos (score: 6)
thought_3: "Contradicción: los logs del servidor muestran latencia normal"
→ detecta contradicción con thought_2, fuerza a seguir buscando
thought_4: "El problema está en el cliente — el timeout del subproceso es demasiado bajo"
→ evaluado: específico, accionable, cita línea de código (score: 9)
Esto es trazable. El agente no alucinó una solución, construyó un camino, detectó una contradicción y pivotó. Y esa cadena de pensamiento se puede reabrir en la siguiente sesión si el problema reaparece.
Contradicción vs. Revisión: No es lo mismo detectar un error lógico (contradicción entre pensamientos) que corregir una decisión previa (revisión). El sistema distingue ambos casos: thought_contradiction señala inconsistencias automáticamente, mientras que una revisión es una intervención explícita del agente que cambia el curso de la cadena.
Patterns — Memoria institucional que no necesita RAG
¿Cuántas veces has resuelto el mismo bug?
En un equipo humano, documentas el fix y el siguiente lo lee. En un equipo de agentes, LUMEN detecta patrones automáticamente.
Cuando un agente encuentra un problema y lo resuelve, guarda el patrón con:
Síntoma
Qué falló
Causa raíz
Por qué pasó
Estrategia
Cómo se arregló
Contexto
Dónde ocurrió
Después, cuando un problema similar aparece, LUMEN lo empareja por similitud TF-IDF (no necesitas LDA ni clustering — TF-IDF funciona y es barato) y sugiere el fix antes de que el agente empiece a alucinar soluciones. Eso sí, un patrón necesita al menos 3-5 ocurrencias para ser estadísticamente significativo — con menos, podría ser ruido.
No es RAG. Es experiencia acumulada que no necesita embeddings ni vectores.
Decisions — Arquitectura que se explica sola
Cada decisión de diseño o arquitectura se registra como un ADR (*Architecture Decision Record*) en PDB:
Decisión: Usar MUMPS heritage sobre SQLite en lugar de PostgreSQL
Contexto: Necesitamos jerarquía natural para KB de agente, no queries SQL complejas
Rationale: $ORDER para iteración determinista, MERGE para copias atómicas
Alternativas consideradas:
- PostgreSQL: sobrecarga de esquema relacional, sin jerarquía nativa ❌
- Redis: clave plana, sin subárboles, sin persistencia cross-session nativa ❌
- Documentos (Mongo): sin operaciones atómicas sobre subárboles ❌
Consecuencia: Latencia de ~3ms vs ~50ms de una API externa. Ganancia neta: 94%
Revisitar si: El volumen supera 10GB por namespace o necesitamos queries relacionales
Link: tasks/lumen-arch-03, chains/chain_178, patterns/pat_42 Cada decisión se linka a las tareas, chains y patrones relacionados. Cuando alguien pregunta "¿por qué usamos SQLite y no PostgreSQL?", la respuesta está en PDB, no en una wiki abandonada.
Cognitive Tools + PDB
| Herramienta | Qué resuelve | Cómo persiste | Cuándo usarla |
|---|---|---|---|
| Thinking Chain | Razonamiento opaco y no trazable | Sesión a sesión en servidor de pensamiento | Úsala cuando depures un error sin causa clara o planifiques una feature compleja |
| Pattern | Bugs recurrentes no documentados | Indefinido (TF-IDF sobre PDB) | Úsalo cuando el mismo incidente se repita 3+ veces o quieras evitar reintentos |
| Decision | Arquitectura no documentada | PDB inmutable | Úsala en cada design review o cuando alguien pregunte "¿por qué lo hicimos así?" |
Cognitive Tools + PDB = un sistema que no solo ejecuta, sino que reflexiona, aprende y decide.
Costo I/O (en caliente): Cada pensamiento en una thinking chain tiene ~3 ms en escritura, ~1 ms en lectura (mediciones sobre SQLite WAL, warm cache). Con 100 pensamientos/sesión y 100 sesiones/día, el overhead es de ~400 ms/día en operaciones de E/S. En frío (primera escritura tras arranque): ~8 ms. No es un problema con 4 agentes, pero al escalar a miles de sesiones concurrentes, el particionado de namespaces PDB permite distribuir la carga.
¿Cuándo NO usarlo? Para respuestas simples — una pregunta directa, un lookup en KB, una transformación de datos — el overhead no compensa. Cognitive Tools están diseñadas para problemas que requieren razonamiento: debugging, planificación, análisis de decisiones. Para el resto, la respuesta directa del LLM es más rápida y barata. ¿Demasiado overhead incluso para casos medios? Usa thinking_light — mismo patrón, sin persistencia.
Antes/después en debugging: Sin Cognitive Tools, un agente resolviendo un bug de timeout necesitaba una media de 3 reintentos (alucinaba una causa, fallaba, probaba otra, fallaba, hasta acertar), consumiendo ~45s de tiempo total. Con Thinking Chains + detección de contradicciones, el mismo bug se resuelve en 1 intento (~12s) — el agente construye hipótesis, las evalúa, detecta la contradicción, y pivota antes de perder el tiempo. Ahorro: 73% del tiempo.
Ingeniería cognitiva honesta
No es AGI. No es magia. Es un sistema que dota a los agentes de herramientas de razonamiento que cualquier ingeniero puede entender, depurar y mejorar. Thinking Chains para pensar, Patterns para recordar, Decisions para justificar. Tres herramientas, un propósito: que los agentes sepan lo que hacen, por qué lo hacen, y cómo mejorar la próxima vez.
Serie: LUMEN Protocol — La Fundación
← Anterior
PDB — La Memoria JerárquicaSiguiente →
LUMEN MCP Servers — 3 en 1¿Quieres que tus agentes razonen?
Las Cognitive Tools son parte del stack LUMEN (MIT). Puedes usarlas hoy en cualquier agente compatible con MCP.
Cognitive Tools de LUMEN son parte del stack MIT. Cadences Lab © 2026.