This article belongs to the repository-tested set. The related public retrieval artifact is Single-threshold versus three-region retrieval; it remains a fixture-level result, not a production benchmark.

Code Review: Is the Memory Kernel Really Framework-Agnostic?

“Framework-agnostic” should be reviewable. I use three tests: no framework types in the kernel API, a neutral interchange format, and a failure path that leaves the host usable.

Test 1: inspect imports and interfaces

The kernel packages define Go interfaces and types for slices, stores, retrieval, injection, and verification. They do not import a named agent framework. That supports source-level independence.

Test 2: inspect the boundary

Ingest accepts Reasonix-style JSONL, but the required concepts—roles, content, and tool calls—are generic enough for adapters. Output is CLI text or JSON rather than an SDK object owned by one framework.

go build -o semantix ./cmd/semantix
go vet ./...
go test ./...

Test 3: remove it

Cache operations are designed to fail open. A harness should be able to skip injection when the process fails and continue its normal loop. If your integration cannot do that, the deployment is coupled even if the source packages are not.

Review finding

The implementation is framework-neutral at the kernel and CLI boundary. The phrase does not mean “zero integration work.” Each harness still needs event mapping, prompt placement, lifecycle handling, and security review. Published repository evidence covers a Reasonix-style path and design notes for others; it is not a compatibility matrix across the market.

For a real adoption review, I would require a second adapter built by someone who did not design the kernel. That exercise would reveal whether the JSONL contract is genuinely sufficient or whether hidden Reasonix assumptions still live in event ordering, tool-call naming, cancellation, or prompt placement. Until that independent adapter exists, “framework-agnostic” is a supported architectural property, not a broad interoperability result.

Review evidence and an adverse result

I ran a broad package check on 2026-08-12 from main e93668e using Go 1.26.5 on Windows/amd64:

go test -count=1 ./kernel/...

Most kernel packages passed, including BM25, cache, embed, event, evolve, ingest, inject, judge, promote, usage, and zone. The run was not all green:

FAIL semantix/kernel/slice
TestFileStoreKeepsPerm0600: store file perm = 666, want 600

That failure is relevant to framework independence because platform behavior is part of the contract. My conclusion remains narrower than the headline: the code is framework-neutral at its Go and file boundaries, while portability still requires OS-specific storage semantics and adapter-level tests. A second independently built adapter would be stronger evidence than another architecture claim.

Sources and limitations

Quickstart — commands and supported release paths.
M0 gate report — what passed, what is conditional, and what remains unverified.
Source and tests — implementation is the final authority.