From Lab to Platform: How CKS Learned to Manage Knowledge Autonomously

“Two weeks ago, we showed how CKS verifies knowledge. Now it manages it on its own — and it caught a real bug in its own design along the way.”

A week ago, we introduced Canonical Knowledge Structure — a verifiable knowledge backbone for LLMs. Back then, it was mostly a validator: you gave it a graph, it checked for contradictions, verified sources, and let you branch and merge like Git for knowledge.

But validation alone doesn't scale. The real question wasn't “Can we check this graph?” but “Can the system notice when a graph goes stale, decide what to do about it, and fix it — without a human in the loop?”

That question turned CKS from a tool into a platform. Here's what changed.

The Rise of Autonomous Agents

Over the past two weeks, we built five background workers — we call them sweepers — and three autonomous agents. They run continuously, watching for problems and resolving them before anyone notices.

The five sweepers patrol the knowledge graph for different kinds of staleness:

• InferenceStalenessSweeper — finds reasoning chains where a premise has been superseded, and the conclusion may no longer hold.
• ProvenanceStalenessSweeper — detects verification records older than a configurable TTL (default 30 days); sources can change or disappear.
• TemporalStalenessSweeper — flags facts whose valid_until timestamp has expired.
• GraphFreshnessSweeper — checks registered knowledge graphs for staleness; if a graph hasn't been updated in 7 days, it escalates a task.
• ContradictionSweeper — scans sessions for logical contradictions (mutual exclusion, functional relation violations) that were never resolved.

Each sweeper publishes its findings into a shared outbox — the same persistent queue that the embedding worker already uses. No new infrastructure. No new tables. Just one more task type.

The three agents consume those tasks and resolve them:

• Critic Agent — handles all five conflict types (gossip, inference, provenance, temporal, contradiction). For inference conflicts, it calls an LLM arbiter; for provenance, it re-verifies the source; for contradictions, it removes the conflicting relation mechanically.
• Enrichment Agent — searches Wikipedia and arXiv for external context, filters candidates by relevance and authority, respects robots.txt, and links new findings back into the graph with provenance.
• Memory Agent — lets LLMs save graphs under memorable names, load them in future conversations, browse a public gallery, and check freshness. No more rebuilding the same graph every session.

All three agents share the same architecture: claim a task from the outbox, resolve it, mark it complete — or dead-letter it if it can't be resolved after several attempts. The pattern is so consistent we extracted it into a shared agent_loop module.

Experiment of the Day: The Graph That Caught Its Own Bugs

This morning, we ran an experiment that closed the loop. We asked Claude Desktop — connected to CKS via MCP — to build a knowledge graph of the entire CKS ecosystem from its three GitHub repositories.

It did. 88 objects, 96 relations. Components, modules, ADRs, dependencies. Validated, no contradictions.

Then we saved it using register_graph("cks-ecosystem") — a new Memory Agent tool that stores a named reference to a session. We opened a fresh conversation, loaded the graph via get_graph, and asked Claude to analyze it.

That's when the interesting part happened. The analysis found real problems in the graph itself:

• Self-loop publishes relations — cks-core → cks-core and cks-mcp → cks-mcp, instead of pointing to actual target objects (SchemaModel, MCPServerEndpoint).
• Asymmetric resolves relations — the Critic Agent was linked to only one sweeper, though the code handles all five.
• Missing Outbox object — the Enrichment Agent's documentation referenced a "persistent outbox", but the graph had no separate node for it.
• No observability → runtime-metrics connection between the MCP and runtime layers.

We fixed all of them through evolve_knowledge — 24 operations applied to the same session, without rebuilding. The graph grew from 88 to 110 objects, 96 to 148 relations. Contradictions: zero.

The system was not just describing itself; it was debugging itself.

What Changed in Two Weeks

The numbers tell part of the story:

	Two weeks ago	Today
MCP tools	24	46
Tests	650+	1600+
Background sweepers	0	5
Autonomous agents	0	3
Storage backends	SQLite	SQLite + Postgres + in-memory
Case Studies	4	6

But the deeper change is architectural. Two weeks ago, CKS was a validator — you called it, it checked, it returned. Today, it's a platform where:

• Detection is automatic. Sweepers run on timers, not on user requests.
• Escalation is standardised. Every finding lands in the same outbox, regardless of type.
• Resolution is autonomous. Agents consume tasks and fix problems without human intervention.
• Memory is persistent. Graphs survive between conversations, browsable and searchable.

Why This Matters

The AI industry is racing to build smarter models. We're building infrastructure that makes any model more trustworthy — not through larger parameters, but through verifiable, self-maintaining knowledge.

Because the hardest problem in AI isn't generating an answer. It's knowing whether you can trust that answer tomorrow, next week, or next year. Language models generate knowledge. Trust has to be engineered.

“CKS stopped being a tool. It became a laboratory where knowledge graphs don't just sit there — they live, they evolve, and sometimes they point out their own mistakes.”

---

GitHub: Deus-corp/cks-mcp · Documentation: docs · PyPI: cks-mcp