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.
The maintainer had tried using a general-purpose AI assistant to help answer issues. It worked for isolated questions. It failed completely for anything that required knowing project history.
How kx stores context
kx uses kernex-memory to persist facts across sessions. The maintainer ran kx in their project directory and stored decisions as they made 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."
Three weeks later, when a user filed an issue about AsyncProvider being missing, kx surfaced the stored fact unprompted when asked about the provider trait.
What changed
The bot doesn’t 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, are now retrievable.
Response time dropped because the maintainer stopped re-reading issue threads to reconstruct context. kx had it.
Stack
kxCLI running locally, one session per project- Facts stored via
/facts addduring normal work sessions - No external services, no subscription beyond Claude Max
- Total setup time: under 10 minutes