ContextMemory v0.1.0-beta is out.
Agent memory you can open like a wiki — not a vector black box, not classic RAG inject.
Release notes
## 0.1.0-beta (2026-08-15)
Features
- add Cursor-style HTTP, vision, browser, PDF, and canvas agent tools. (0d322c2)
- derive LLM protocol capabilities from prompt profiles. (bd159ad)
- expand agentic guardrail catalog with enable/disable kinds (4fabaec)
- expose LLM generation defaults in Admin and apply to chat/generate payloads (e459575)
- multi-model harness, live-data guardrail, and Ollama num_ctx fix. (7244aa2)
Bug Fixes
- ci: stop GITHUB_TOKEN from overriding PEER_SYNC_TOKEN on mirror push (f230ff2)
- coerce query_objects filter object/string into string array. (95069ee)
- map fieldsToReturn alias in query_objects normalizer. (9b3e172)
- pin LinkedIn API version and clarify dev.to errors (dceafbc)
- promote prose MCP tool JSON into structured tool_calls. (5ae1b84)
- publish thin helpers under available Kortexio package names (fbff059)
- regenerate AddSkillActivation migration with model snapshot. (91a53c5)
- rewrite SQL-style query_objects filters to Zuora field.OP:value. (a145663)
- set User-Agent on dev.to announcer requests (88e4992)
- stabilize Qwen client-side tools and stop capping Weak MCP catalogs. (c4db686)
- stop live-data validation loops and soften noisy guardrail defaults (14f262a)
- stop RequireZeroExitCode guardrail from looping forever on retried tool failures (1cb6155)
- stop tool_describe failures from poisoning agentic validation loops. (3fcff28)
- tighten LinkedIn release posts to messaging voice (beb0894)
Full notes: https://github.com/Kortexio/ContextMemory/releases/tag/v0.1.0-beta
Repo: https://github.com/Kortexio/ContextMemory · Cloud: https://kortexio.io
Top comments (2)
Making agent memory inspectable like a wiki instead of hiding it behind vector retrieval is the consequential product choice here; it gives users a place to understand and correct what the system thinks it knows. The fixes for live-data validation loops and
RequireZeroExitCoderetries looping forever also suggest the hard part is now orchestration failure behavior, not just adding HTTP, vision, browser, PDF, and canvas tools. For a beta, I'd prioritize version history and provenance for every memory edit-the more capable the tool catalog becomes, the more valuable reversibility is.Thanks—you've zeroed in on exactly the bet.
The wiki-over-vector choice is the whole thesis:
retrieval you can't read is retrieval you can't correct, and an agent that can't be corrected accumulates errors silently.
Making memory a first-class inspectable surface means the user is always in the loop on what the system believes.
And yes—the orchestration failure behavior is where the real difficulty has migrated.
Adding tools is mostly surface area; the hard part is what happens when a tool returns stale data mid-loop or an exit-code check never converges.
Those bugs taught me that the tool catalog's value is capped by how gracefully the orchestrator degrades.
A capable catalog with brittle failure handling is worse than a smaller one that fails predictably.
Version history and provenance for every memory edit is the right beta priority, and your framing for why is sharper than mine was: reversibility scales in value with catalog capability.
The more an agent can do to its own memory, the more an undo button and an audit trail become non-negotiable rather than nice-to-have. It's on the roadmap.
Appreciate the thoughtful read.