The problem with stateless assistants
Open source maintainers answer the same questions repeatedly. Not because the documentation is bad, but because context accumulates in ways that static docs cannot capture: a decision made in a GitHub issue, a workaround mentioned in a Discord thread, a breaking change rationale that never made it into CHANGELOG.
A general-purpose AI assistant works for isolated questions. It fails for anything that requires knowing project history. This reference architecture describes how kx is designed to fill that gap for a solo maintainer with, say, 40k lines of Rust across 15 repos.
How kx stores context
kx uses kernex-memory to persist facts across sessions. The maintainer runs kx in the project directory and stores decisions as they make them:
> /facts add breaking-change-v3 "Removed AsyncProvider trait in 0.3.0. Reason: tokio 1.0 upgrade made the abstraction redundant. Migration: replace AsyncProvider with Provider + async_trait."Weeks later, when a user files an issue about AsyncProvider being missing, kx surfaces the stored fact when asked about the provider trait: the March decision answers the April question.
What this changes
The bot does not replace documentation. It fills the gap between documentation and institutional memory. Decisions that would normally live in the maintainer’s head, or be buried in a closed GitHub issue, become retrievable.
The time win comes from not re-reading issue threads to reconstruct context. The assistant has it.
Stack
kxCLI running locally, one session per project- Facts stored via
/facts addduring normal work sessions - No external services, no subscription beyond the model provider
- Setup time: under 10 minutes