Knowledge upkeep is the problem
Tom & Jakub · Tue, 27 Oct 2026
The knowledge graph, the search index, the MCP endpoint — all replaceable. The durable work is keeping an organisation's knowledge true, in a corpus the organisation owns.
Everyone building agent context is selling retrieval — a graph, an index, an endpoint. We think retrieval is the replaceable part. The durable problem is deciding what is still true: weighing evidence, reconciling contradictions, keeping derived knowledge aligned with the sources it came from. That work has to run continuously, and its output has to land somewhere the organisation owns. The corpus is not the product. Knowledge management is.
An agent working inside a real engineering organisation depends on knowledge from two kinds of sources. The first is the code. Codebases are dense with patterns that encode past decisions: how services authenticate, how errors propagate, where the boundaries between systems actually sit. This knowledge exists even when nobody has written it down. An agent can inspect the code in front of it, but it cannot reliably know which patterns are deliberate, which are shared across the company, and which are merely legacy. Something needs to identify those patterns, distil them, and preserve pointers to the code that supports them so they can be surfaced later.
The second source is the wider organisation: Linear tickets and pull requests, Confluence and Notion pages, Slack threads, PagerDuty incidents, and decisions distributed across many systems. Together, the code and these external systems contain most of the context an agent needs. They just do not form a coherent body of knowledge.
Access is useful, but it is not coherence
We can connect an agent directly to Jira, Confluence, Notion, Backstage, and every other source through MCP tools. The agent still has to guess where an answer might live, search each system independently, and join the results during every run. It often cannot know what it failed to search. Connecting agents to every source gives them access, not coherence.
Local memory has a similar problem. Markdown files are a good primitive: they are readable, portable, and easy for both people and agents to edit. But as they accumulate, they contradict one another, drift away from the code, and become difficult to navigate. Manually maintained index files eventually fall behind too — we made the longer argument in AGENTS.md is the wrong conversation.
The natural response is to reach for a more sophisticated store. A vector database can find similar text. A graph can traverse relationships. Both can improve retrieval, but neither decides which claim is still current, reconciles contradictions, or keeps derived knowledge aligned with its sources. Without maintenance, a better index only provides faster access to the same memory soup.
A corpus the organisation owns
Our approach is to bring useful knowledge from these sources into a structured, Git-backed corpus. Code-derived patterns can live alongside knowledge pulled from tickets, pull requests, documentation, incidents, and other systems, with links back to the supporting evidence.
Git is deliberately unremarkable. It is versioned, shared, access-controlled, reviewable, and already understood by engineering teams. Automatic updates land as small, visible commits that people can inspect, correct, or revert. Edits proposed in ctxpipe's chat, and changes to what the corpus draws from, arrive as pull requests and go through the review process the team already trusts.
Even without specialised retrieval, the corpus remains useful. Point Claude, Codex, Cursor, or another agent at the repository and ask it to navigate the files. Open it in Obsidian. Add a custom agent or cron job. Ask an agent to change a document, review the diff, and commit it.
The corpus is not the product. It is the organisation's knowledge, and the value should remain with the organisation. ctxpipe is the management layer around it.
The job is continuous maintenance
Simply copying everything into Git would move the mess rather than solve it. The actual work happens continuously in the background. ctxpipe observes the underlying sources, extracts useful knowledge, connects related material, maintains navigation, revises claims when their evidence changes, and retires them when the evidence is gone. When it derives something new, it writes the result back into the corpus with its provenance rather than keeping it in a private internal store.
Claims age. Evidence moves.
Maintenance also means accounting for confidence and time. A current implementation may be strong evidence for how a system behaves. An old Confluence page may be weaker. A recently approved architectural decision may accurately describe intent without describing what is already deployed. Something confidently true five years ago may no longer be useful today. The system needs to preserve where a claim came from, when it was valid, and what newer evidence supports or contradicts it.
Take a concrete case. An agent asks how payments-service handles retries. The code says three attempts with exponential backoff. A runbook from 2021 says five attempts at a fixed interval. An ADR accepted last month says the service is moving to idempotency keys with two attempts. All three are documentation. Only one describes production today, and only one describes where it is heading. In the corpus, the service's knowledge file is extracted from the code, and its claims point back to the files they came from, at the commit that was read. The ADR becomes a decision file with its declared status and date, linked to the service it influences. The runbook is mirrored as it is, and counts for less: older evidence loses weight, and code outranks a wiki page. An agent reading the corpus sees all three, each with its source and date, instead of three equally confident answers. When the change lands in code, the next push re-reads it, and the service file is revised in a commit anyone can review.
This maintenance layer is the core of ctxpipe. The knowledge graph, search indexes, MCP interface, and other retrieval mechanisms help deliver the result, but they are not the system's durable source of truth.
Retrieval should remain replaceable
As the corpus grows, agents need better ways to retrieve the small part that matters. A knowledge graph can expose relationships across repositories. Semantic and code search can find relevant evidence. An MCP interface can deliver the result inside an agent's existing workflow.
In our model, these are projections over the corpus. The graph should be a view, not a vault. It can be rebuilt. Search indexes can be replaced. Teams can build their own retrieval or maintenance jobs without asking permission from ctxpipe.
In Specificity compounds. Generality dilutes. we argued the graph compounds with every commit and every agent run. That still holds — but the compounding happens in the corpus, not the projection. Capturing context is the slow, accumulating work: ingestion from the underlying sources, local memory hooks on agent sessions, claims revised, stale facts retired. Generating a graph over the result is the cheap part — a deterministic build that can be rerun in minutes. That asymmetry is the point. It is what makes the graph safe to rebuild, and the Git-backed corpus the thing worth owning: portable, inspectable, and open regardless of what sits on top of it.
Inside out
We call this approach inside out. The default architecture for context products runs outside in: the vendor ingests your knowledge into their system, and that system becomes the only useful interface to it. The longer you use it, the deeper your knowledge sinks into someone else's product. Inside out inverts the arrangement. The knowledge stays inside your boundary — a Git repository you own, in a format anything can read — and ctxpipe operates around it as the maintenance layer. The product wraps the asset. It never contains it.
If ctxpipe stops working for a team, they can turn it off. Their knowledge remains in Git, in an open and inspectable form. They can point another agent at it, build another graph over it, or continue managing it themselves.
The context belongs to the organisation. ctxpipe's job is to keep it useful.
ctxpipe is the open-source context layer for engineering teams. It keeps what your team knows in a git repository you own: current, reviewable, and the same for every engineer and every agent. Self-host it, or request early access to the hosted version.