Cognitive Tools: When Your Agent Thinks in Steps, Not Leaps
Thinking Chains, Patterns, and Decisions — three tools that give AI agents the ability to reason structurally, learn from past mistakes, and document decisions with traceability. All on PDB, all MIT.
Gonzalo Monzón
July 7, 2026 · Series: LUMEN Protocol — The Foundation (3/4)
TL;DR
LUMEN's Cognitive Tools solve the fundamental problem of LLMs: they don't know why they do what they do. Thinking Chains provide structured reasoning that persists between sessions. Patterns accumulate institutional experience via TF-IDF without needing RAG. Decisions document architecture as immutable ADRs in PDB. Together they turn an agent that hallucinates into a system that reflects, learns, and decides. All MIT, all on the LUMEN transport.
The LLM black box
When you work with LLMs daily, you quickly discover their Achilles' heel: they don't know why they do what they do.
They generate the right answer 80% of the time. But when they fail, you can't ask "why did you take that path?" because there is no path. There's a cloud of probabilities.
LUMEN solves this with three cognitive tools that give agents the ability to reason, remember, and decide in a structured way.
Thinking Chains — Reasoning that persists
This isn't "chain of thought" prompt engineering. It's a structured reasoning system with four differentiating properties:
🧠 Persists between sessions
The thought chain survives context compression. You can pick it up tomorrow where you left off.
📊 Evaluable
Each step is scored for specificity, actionability, and concreteness. You know which thoughts are solid and which aren't.
🔄 Revisable
Go back, correct, branch. You're not locked into the first line of reasoning.
📝 Summarizable
Compress 20 thoughts into 3 while keeping the essentials. Ideal for injecting into context without saturation.
Real example — A multi-agent debugging session:
thought_1: "User reports delegate_task returning timeout"
→ evaluated: specific, actionable (score: 8)
thought_2: "Could be MCP server saturation"
→ evaluated: hypothesis, needs data (score: 6)
thought_3: "Contradiction: server logs show normal latency"
→ detects contradiction with thought_2, forces continued investigation
thought_4: "The problem is on the client — the subprocess timeout is too low"
→ evaluated: specific, actionable, cites code line (score: 9)
This is traceable. The agent didn't hallucinate a solution — it built a path, detected a contradiction, and pivoted. And that thought chain can be reopened in the next session if the problem resurfaces.
Contradiction vs. Revision: Detecting a logical error (contradiction between thoughts) is not the same as correcting a previous decision (revision). The system distinguishes both cases: thought_contradiction flags inconsistencies automatically, while a revision is an explicit agent intervention that changes the course of the chain.
Patterns — Institutional memory that doesn't need RAG
How many times have you fixed the same bug?
In a human team, you document the fix and the next person reads it. In an agent team, LUMEN detects patterns automatically.
When an agent encounters a problem and solves it, it saves the pattern with:
Symptom
What failed
Root Cause
Why it happened
Strategy
How it was fixed
Context
Where it happened
Later, when a similar problem appears, LUMEN matches it by TF-IDF similarity (you don't need LDA or clustering — TF-IDF works and is cheap) and suggests the fix before the agent starts hallucinating solutions. That said, a pattern needs at least 3-5 occurrences to be statistically significant — fewer than that, and it could be noise.
This isn't RAG. It's accumulated experience that doesn't need embeddings or vectors.
Decisions — Architecture that explains itself
Every design or architecture decision is recorded as an ADR (*Architecture Decision Record*) in PDB:
Decision: Use MUMPS heritage on SQLite instead of PostgreSQL
Context: We need natural hierarchy for agent KB, not complex SQL queries
Rationale: $ORDER for deterministic iteration, MERGE for atomic copies
Alternatives considered:
- PostgreSQL: relational schema overhead, no native hierarchy ❌
- Redis: flat key, no subtrees, no native cross-session persistence ❌
- Document (Mongo): no atomic subtree operations ❌
Consequence: ~3ms latency vs ~50ms from an external API. Net gain: 94%
Revisit if: Volume exceeds 10GB per namespace or we need relational queries
Link: tasks/lumen-arch-03, chains/chain_178, patterns/pat_42 Each decision is linked to related tasks, chains, and patterns. When someone asks "why are we using SQLite and not PostgreSQL?", the answer is in PDB, not an abandoned wiki.
Cognitive Tools + PDB
| Tool | What it solves | How it persists | When to use it |
|---|---|---|---|
| Thinking Chain | Opaque, non-traceable reasoning | Session-to-session in thinking server | Use when debugging an error with no clear cause or planning a complex feature |
| Pattern | Recurring undocumented bugs | Indefinite (TF-IDF over PDB) | Use when the same incident repeats 3+ times or you want to avoid retries |
| Decision | Undocumented architecture | Immutable PDB | Use at every design review or when someone asks "why did we do it this way?" |
Cognitive Tools + PDB = a system that doesn't just execute, but reflects, learns, and decides.
I/O cost (warm): Each thought in a thinking chain takes ~3 ms to write, ~1 ms to read (measurements on SQLite WAL, warm cache). With 100 thoughts/session and 100 sessions/day, the overhead is ~400 ms/day in I/O operations. Cold (first write after startup): ~8 ms. Not an issue with 4 agents, but when scaling to thousands of concurrent sessions, PDB namespace partitioning allows load distribution.
When NOT to use it? For simple responses — a direct question, a KB lookup, a data transformation — the overhead isn't worth it. Cognitive Tools are designed for problems that require reasoning: debugging, planning, decision analysis. For everything else, the LLM's direct response is faster and cheaper. Too much overhead even for medium cases? Use thinking_light — same pattern, no persistence.
Before/after in debugging: Without Cognitive Tools, an agent debugging a timeout bug needed an average of 3 retries (it hallucinated a cause, failed, tried another, failed, until it got it right), consuming ~45s total time. With Thinking Chains + contradiction detection, the same bug is resolved in 1 attempt (~12s) — the agent builds hypotheses, evaluates them, detects the contradiction, and pivots before wasting time. Savings: 73% of the time.
Honest cognitive engineering
It's not AGI. It's not magic. It's a system that gives agents reasoning tools any engineer can understand, debug, and improve. Thinking Chains to think, Patterns to remember, Decisions to justify. Three tools, one purpose: so agents know what they're doing, why they're doing it, and how to do better next time.
Series: LUMEN Protocol — The Foundation
← Previous
PDB — The Hierarchical MemoryNext →
LUMEN MCP Servers — 3 in 1Want your agents to reason?
Cognitive Tools are part of the LUMEN stack (MIT). You can use them today in any MCP-compatible agent.
LUMEN Cognitive Tools are part of the MIT stack. Cadences Lab © 2026.