Ledger: knowledge our agents can be audited on

Teams can trace an agent's prompts, tools, and guardrails — but when an auditor asks "what did this agent know on July 12, and where did that fact come from?", most architectures have no answer.

An agent your organization can govern requires knowledge it can audit: knowledge compiled into a versioned, certified artifact — treated with the same rigor as code.

At Alquimia we build a Low-Code / No-Code platform for AI agents that organizations run in production. Running agents in production means every layer of the stack has to be governable — and in our experience, the weakest layer today is knowledge. Teams can trace an agent's prompts, tools, and guardrails, but when an auditor asks "what did this agent know on July 12, and where did that fact come from?", most architectures have no answer. The knowledge lives inside a retrieval index that changes silently and was never designed to be inspected.

We are building Ledger, a new module in the Alquimia stack that closes that gap. Ledger compiles curated sources into versioned, certifiable knowledge bundles that agents consume through MCP — so an agent's knowledge becomes an artifact you can check out, diff, and audit, the same way you audit its code. We are building it in the open, and this post shares why we started, what it does, and the design decisions we have made so far.

01Retrieval alone cannot tell you what your agent knows

The default way to give an agent knowledge is retrieval-augmented generation: chunk documents, embed them, retrieve the top fragments at query time. It works for many cases, and it stays part of our reference architecture for volatile data. Its limits, however, are now well documented.

Chunking breaks the relationships between concepts that multi-hop questions depend on — surveys of graph-based retrieval describe this as a structural limitation of flat chunk stores (arXiv 2501.13958). Position matters more than it should: Liu et al. measured accuracy drops of more than 30% in multi-document QA simply by moving the relevant document from the first position to the middle of the context (TACL 2024, DOI 10.1162/tacl_a_00638). And piling more into the context window makes things worse in unpredictable ways: Chroma's 2025 "context rot" study across 18 frontier models found performance degrades non-uniformly as input grows, with a full conversation history (~113k tokens) scoring roughly 30% below a focused 300-token version of the same information (Chroma Research, 2025).

For us the deciding issue is governance. A retrieval index is a moving target: re-embedding and re-indexing change what the agent can see, nothing records what it saw at a given moment, and every query starts from zero — nothing accumulates. You can log what an agent retrieved; you cannot state what it knew. For the organizations we work with — regulated industries, public-sector operators — that is a gap an audit will eventually find.

02The industry is converging on compiled knowledge

Two milestones this year confirmed a direction we had been exploring. In April 2026, Andrej Karpathy published his "LLM wiki" pattern: instead of retrieving fragments per query, the model incrementally builds and maintains a persistent, interconnected wiki of markdown pages — his analogy is compilation, where source documents are the code and the wiki is the binary (karpathy/llm-wiki). In June, Google Cloud formalized the pattern as the Open Knowledge Format (OKF) v0.1: an open, vendor-neutral spec where a "knowledge bundle" is a directory of markdown files with YAML frontmatter — readable with cat, distributable with git clone (OKF spec).

We think the direction is right, and we also think the pattern is incomplete for production use. OKF v0.1 explicitly leaves per-concept versioning, verification status, and provenance guarantees out of scope — its own issue tracker flags trust and freshness as open design space. And practitioners running the wiki pattern at scale report that the number-one failure mode is drift: the knowledge base silently diverging from its sources as cross-references go stale. One team running 4,000+ interconnected concepts in production put it plainly — the lint pass is not optional; they run it on a timer.

Those gaps are exactly where an agent platform built for governance has something to contribute.

03What Ledger does: compile, certify, serve

Ledger is two components separated by one artifact. The artifact — the knowledge bundle — is the contract between them.

The compiler is where humans and agents collaborate on knowledge. The division of labor is the core design idea: the agent is the librarian, the human is the curator. Curators feed sources and validate what matters; the agent writes concept pages, maintains cross-references, detects contradictions, and keeps the index current. Four operations cover the lifecycle: ingest (a source comes in, the agent synthesizes it into concept pages), lint (scheduled health checks for broken references, contradictions, and stale claims — run in CI, because drift is the documented failure mode), certify (more on this below), and package (export as a git repo, tarball, or OCI artifact).

The runtime is deliberately thin. It takes a compiled bundle and serves it to agents over MCP with progressive disclosure — index first, targeted pages on demand, never the whole bundle into the context window. When a bundle outgrows direct navigation (in community experience, around 50–100k tokens), the runtime adds hybrid search over the compiled concepts. It never chunks or embeds the raw sources; the moment it did, we would have rebuilt the retrieval pipeline this design exists to improve on.

Two decisions make Ledger auditable rather than merely convenient:

We extend OKF instead of inventing a format. Bundles are fully OKF v0.1 conformant, so any third-party OKF tooling reads them. Our governance layer lives in frontmatter extension keys the spec explicitly permits: a per-concept version, a confidence lifecycle state (draft, reviewed, verified), and verified_at / verified_against fields that record when a concept was last checked against its source. Interoperability comes free; the governance travels with the file.

Every bundle carries a certification manifest. The lint results serialize into a dated, signed report: no orphaned pages, no detected contradictions, the share of concepts verified against source, average freshness. Technically it is a small artifact. Functionally it changes the audit conversation — the team that builds an agent's knowledge generates the manifest, and the team that audits the agent requires it. "What did this agent know on date D?" becomes one git checkout plus one manifest read.

04How we are building it

Ledger follows the same principles as the rest of the Alquimia stack.

Files over infrastructure. A bundle is markdown, YAML, and git — no schema registry, no required backend. That keeps the whole system runnable on the infrastructure your organization controls, including fully air-gapped environments. For teams with data-residency and sovereignty requirements, knowledge that lives in plain files under their own version control is the difference between a system they can adopt and one they cannot.

Git provides the collaboration layer. Multiple curators work on a shared repository; access control, attribution, and review come from branches and pull requests. We decided early not to reimplement any of that inside Ledger — composable architectures mean using the primitives teams already trust.

Explicit non-goals. Ledger targets stable, high-value knowledge that benefits from compression and synthesis. Fast-changing operational data stays in retrieval systems, and the two coexist in a hybrid architecture. We are also deliberately keeping the bundle format aligned with the open spec rather than forking it — if the OKF community resolves typed relationships or provenance upstream, we want to inherit that, and to contribute what we learn.

We are dogfooding from day one. The first Ledger bundle documents the construction of Ledger itself: the research behind it, the design decisions, the spec. It meets the test we would give any candidate domain — knowledge dispersed across many sources, where an agent without the bundle gets definitions wrong. If the tool cannot maintain its own second brain, it is not ready for anyone else's. Our success measure is behavioral, in line with how we approach evals across the platform: an agent mounted on a bundle should stop making the definitional errors it made without it, and we intend to publish that comparison rather than assert it.

05Where this is going

The functional scope is written, the architecture spec is next, and the first bundle is already growing. We will keep sharing design decisions — including the ones we get wrong — as the module takes shape, because inspectable engineering is the standard we hold our own tools to. If your team runs AI agents in production and has felt the gap between what an agent retrieves and what you can prove it knows, we would like to hear how you handle it today — and if you want to see how Ledger fits the broader picture, Alquimia Agentic Platform is where our agents, and soon their knowledge, are built and governed.