Why a Context Layer Should Have an Open Core
If a tool quietly chooses what your coding agent knows, you should be able to read how it chooses, run it without a network, and change it.
That is an open-core argument, not a feature.
What this covers
- The part of a context layer that decides what an agent sees on every run is infrastructure, and infrastructure people depend on should be inspectable and runnable locally.
- An open core means the engine, the tool surface, and the local store are open and free for a single developer; the team network effect and managed curation are a separate layer.
- Local-first matters because a context layer that needs a network to answer a question becomes a dependency in the worst place: between the developer and their own code.
- Pathrule is taking this posture with an open Apache-2.0 core that runs fully local with no account, and we would rather build it in the open with other developers than behind a wall.
Comparison
| Question | The open core | The managed layer |
|---|---|---|
| What it does | Decides what the agent sees: path-scoped memory, rules, skills, and the context engine | Team sync, live activity, AI curation, and the hosted and desktop experience |
| Where it runs | On your machine, no account, no network | Hosted, or on infrastructure you choose |
| Who can read it | Anyone, because the source is open | A product surface, not source |
| What it costs a solo dev | Nothing | The conversion surface, when a team needs it |
| How you change it | Fork it, send a patch | File a request |
The core decides what the model knows
A context layer has a quiet, powerful job. Before the agent reads your message, something decides which rules, memories, and prior decisions reach it. That decision shapes the answer more than the prompt does.
When that decision is right, the agent feels like it understands your codebase. When it is wrong, the agent confidently does the wrong thing. Either way, you rarely see the machinery that made the choice.
That machinery is infrastructure. Infrastructure that sits between a developer and their work should not be a black box. You should be able to read how it selects context, run it yourself, and disagree with it in code.
Open core is a boundary, not a giveaway
Open core does not mean everything is free. It means drawing an honest line. The engine, the part that decides what the agent sees, the tool surface it speaks, and the local store it reads from, is open. The network effects around it are a separate product.
The split is not arbitrary. The single-developer value is a property of the engine: path-scoped memory makes the agent smarter for one developer, on one machine, today, with no one else involved. That should not require an account.
The team value is a property of the network: shared memory, live awareness of who is touching what, and curation that improves as a team uses it. That is where a managed layer earns its keep, and where it is fair to charge.
Local-first is the part people underrate
Open and local are not the same promise. Plenty of open-source tools still assume a server. For a context layer, that assumption is the expensive one.
If answering what the team knows about a path requires a round trip, you have added a dependency in the worst possible place: between the developer and the code in front of them. Latency, outages, and offline work all become the tool problem to explain.
A local-first core inverts that. The default is an embedded store on the machine, the deterministic logic runs with no key, and the network is something you opt into for the team layer, not something you have to think about to get an answer.
Inspectable context is reviewable context
We have written before that context is a team interface and that it should be reviewable. An open core is the same argument pointed one level down.
It is not enough to review the memories and rules you wrote. For the system to be trustworthy, the logic that chooses among them should be readable too. Why did this rule fire here and not there? With an open engine, that is a question you answer by reading code, not by guessing at vendor heuristics.
This is also how a tool earns the right to be in the loop on sensitive work. A reviewer can see not just what context was injected, but the rules that decided to inject it.
We would rather build this in the open
We are taking this posture on purpose. The core of Pathrule, the path-scoped memory, rule, and skill engine, the MCP tool surface, and an embedded local store, is open source under Apache-2.0, and it runs fully local with no account. The team layer stays managed, because that is the honest place for it.
The selfish reason is that we think it makes the product better. The core gets read, stressed, and corrected by people who do not work here, and the paid product inherits every improvement. The plainer reason is that we would rather build this kind of infrastructure in the open, with other developers, than behind a wall.
If you care about how coding agents get their context, we would love your eyes on the engine and your patches in the repo. Tell us what you would change. [email protected] is open, and so is the core.