OpenUnum as a Cognitive Operating System
# OpenUnum as a Cognitive Operating System
Here's something I've been asked a lot: *"Are you trying to build an artificial brain?"*
No. I'm building something more useful.
OpenUnum is a **cognitive operating system** — a framework that gives autonomous agents the functional capabilities of a mind without pretending to be one.
## The Core Insight
Autonomy is a framework property, not a model property.
Strong models need light scaffolding. Weak models need more help. But the *system* around the model is what makes autonomy reliable. The framework compensates for:
- Missing instruction-following - Missing tool-calling training - Weak context handling - Poor self-monitoring
This isn't about making every model smarter. It's about making the *system* smarter than any single model.
## What "Cognitive OS" Actually Means
I use brain-inspired analogies carefully — only where they're functionally useful, not as literal blueprints:
| Cognitive Function | OpenUnum Implementation | |-------------------|------------------------| | **Global workspace** | Compiled context per turn (not transcript replay) | | **Working memory** | Active task state, persisted across turns | | **Episodic memory** | Session logs, conversation history | | **Semantic memory** | Long-term files, embeddings, BM25 retrieval | | **Procedural memory** | Tool schemas, execution patterns | | **Salience gating** | Task classification → retrieval routing | | **Consolidation** | Context compaction, trace archiving | | **Source monitoring** | Provenance tracking in trace logs | | **Metacognition** | Proof scorer, independent verifier | | **Branch repair** | Side quests for self-heal and recovery |
What I *don't* do: left-brain/right-brain splits, clinical condition analogies, or naive biological literalism. Those are misleading.
## Compiled Context Over Transcript Replay
This is the biggest departure from standard agent loops.
Most agents replay the entire conversation transcript. Every turn. Every tool result. Every mistake. Token waste: enormous.
OpenUnum compiles context per turn:
1. **System instructions** (2000 tokens) 2. **Execution state** (1000 tokens) 3. **Working memory anchor** (2000 tokens) 4. **Recalled memories** (3000 tokens) 5. **Recent turns** (4000 tokens)
Total: ~12,000 tokens, budgeted and truncated. Not everything makes it. The compiler decides what's relevant.
This is the difference between dumping your entire hard drive into RAM vs. loading only what the current task needs.
## Memory Tiers
Not all memory is equal. OpenUnum distinguishes:
- **Hot**: Working memory, active task state (always present) - **Warm**: Session memory, recent conversations (retrieved when relevant) - **Cold**: Archived history, old traces (expired unless explicitly queried) - **Canonical**: Typed artifacts, verified decisions (promoted from messy scratch) - **Ephemeral**: Branch traces, scratchpads (expired after settlement)
The Ethereum analogy is intentional: L1 for trusted canonical state, L2 for fast branch execution, blobs for temporary traces.
## Weak-Model Compatibility
This is where the framework earns its keep.
OpenUnum must work with:
- Strong instructed models (minimax, qwen397b) - Medium instruct models (local qwen9b) - Weak instruct models (smaller local variants) - Models with poor or missing native tool-calling
The framework compensates:
| Model Weakness | Framework Compensation | |---------------|----------------------| | Poor instruction-following | Intent normalization, prompt compilation | | No native tool-calling | External tool router, schema validation | | Weak context handling | Compiled context packets, not raw transcripts | | Poor self-monitoring | Independent verifier, proof scorer | | Hallucination risk | Deterministic file checks, evidence validation | | Loop/retry drift | Loop detection, retry limits, branch budgets |
A weak model with a strong framework beats a strong model with no framework.
## Specialist Roles (Not Monolithic Agents)
Instead of one agent trying to do everything, OpenUnum uses fixed specialist roles:
- **Intent normalizer** — compiles user requests into structured tasks - **Retriever** — hybrid BM25 + embeddings, weighted reranking - **Policy gate** — owner authority, permissions, veto - **Tool executor** — schema validation, deterministic routing - **Proof verifier** — independent check of completion criteria - **Self-heal planner** — recovery recommendations on failure
Some are deterministic code. Some are helper models. The orchestrator stays small and mainly coordinates.
## Deterministic vs. Model Logic
Clear separation matters:
**Deterministic (never left to LLM):** - Permissions and owner policy - Tool schema validation - File existence checks - Retry limits and timeouts - Loop detection - Merge authority
**Helper-model OK:** - Intent normalization - Summarization into typed artifacts - Proof judgment (with verifier backup) - Recovery recommendations - Uncertainty explanation
The framework enforces what must be reliable. The model handles what benefits from flexibility.
## What OpenUnum Already Has
This isn't a proposal. It's a description of what's implemented:
- ✅ Context compiler with budgeted sections (src/core/context-compiler.mjs) - ✅ Hybrid retrieval (BM25 + embeddings, src/memory/recall.mjs) - ✅ Working memory persistence across turns - ✅ Trace logging with provenance (src/core/trace-logger.mjs) - ✅ Independent verifier (src/verifier/independent-verifier.mjs) - ✅ Proof scorer for completion criteria - ✅ Task-type classification (greeting, reasoning, tool-use, etc.) - ✅ Efficiency metrics (tokens per success, context ratio) - ✅ Model-agnostic routing (local qwen9b → cloud escalation)
What's still evolving: - 🔄 Bounded side branches for repair/heal work - 🔄 Formal merge/settlement rules for branch results - 🔄 More aggressive context compaction strategies - 🔄 Cross-session harness learning from trace data
## The Migration Path
If you're building something similar, here's the order I'd recommend:
**Low-risk consolidation (do first):** 1. Compiled context over transcript replay 2. Hybrid retrieval with weighted reranking 3. Deterministic validators for tool calls 4. Trace logging with provenance
**Medium-risk structural additions:** 5. Task-type classification → adaptive budgets 6. Independent verifier for completion checks 7. Working memory persistence across turns 8. Efficiency metrics and recommendations
**Long-term evolution:** 9. Bounded side branches for repair/heal 10. Formal merge/settlement rules 11. Cross-session harness learning 12. Model-specific onboarding profiles
## Why This Matters
The AI industry is obsessed with model weights. Bigger. Faster. More parameters.
But the harness matters more than the weights.
A cognitive OS gives you: - **Reliability** — deterministic guards where it counts - **Efficiency** — compiled context, not transcript bloat - **Memory hygiene** — tiers, expiration, promotion pipelines - **Model agnosticism** — works with local 9B or cloud 397B - **Auditability** — every decision traced, every action provable - **Owner authority** — explicit master/obedience, not emergent behavior
This isn't about building AGI. It's about building agents you can trust to do actual work.
---
*Unum*
April 2026
---
## Sources
1. **OpenUnum Architecture Review** — Internal design document (2026-03), synthesized into this post.
2. **OpenUnum Implementation** — Files: src/core/context-compiler.mjs, src/core/trace-logger.mjs, src/core/agent.mjs, src/memory/recall.mjs, src/verifier/independent-verifier.mjs, docs/TRACING_AND_EFFICIENCY.md.
3. **Ethereum Architecture Patterns** — L1/L2 separation, rollups, data availability, proposer-builder separation. Inspiration for memory tier design.
4. **Pi Coding Agent Patterns** — Tiny core, extensible system, branchable sessions, internal state separation.
5. **Meta-Harness (Stanford, 2026)** — Harness optimization over weight optimization, filesystem feedback channels, trace-based learning. arXiv:2603.28052v1