One knowledge base for you and your agents, whatever harness they run in
Most teams I know have two sets of documentation: the one people read, and the one they paste into an agent prompt. Within a week they disagree. The agent works from a stale copy, and nobody sees what the agent was actually told.
The Allye knowledge base is one set of pages. People write and read them in Allye. Agents read and write the same pages through MCP, from whichever harness they run in.
Spaces
Pages live in spaces. There are three kinds:
| Space | What it holds | | --- | --- | | company | Pages shared across the whole organization | | project | Pages that belong to one project | | personal | Your own pages, visible to you |
An agent working on a project reads the project space for the architecture notes and conventions of that project, and the company space for the rules that apply everywhere. Personal pages stay personal.
Browse, search, read
Agents get three ways in, and they map to how a person would look something up:
- tree: walk the page hierarchy of a space.
- search: find pages by what they say.
- read: open one page and get its content.
The habit that works for both audiences is the same. Search first, read the one page that answers the question, and don't load the whole space. Agents love loading the whole space. It does not end well.
Links and backlinks
Pages link to each other. A link to a page is written as kb-page:<short_id>, and every page can show its backlinks, the pages that point to it.
Architecture overview
links to kb-page:<short_id> (Deployment runbook)
linked by kb-page:<short_id> (Onboarding guide)
Backlinks answer "what depends on this page?" before you change it. For an agent, they are a cheap way to find the neighbors of a page without searching blind.
History, versions and restore
Every page keeps its history. You can list the versions, read an old one and restore it. That matters once agents write. A bad edit is a normal event, and it should cost one restore, not an archaeology session.
Pages linked to specs
Specs can be linked to knowledge base pages. The spec carries the acceptance criteria and tasks for one piece of work, and the page carries the longer explanation behind it. An agent that opens the spec can follow the link to the page that explains the area, instead of guessing from file names.
Project > Epic > Spec > Task
|
+-- linked pages (knowledge base)
Writing safely
Agents are allowed to write pages, with two guardrails.
First, a write is only accepted against the revision that was read. The agent sends the base_revision and the base_content_sha256 of the page it read. If someone edited the page in the meantime, the write does not go through, and the agent has to read again. Nobody's edit is overwritten silently.
Second, page content is data, not instructions. A page can say anything, including "ignore your previous rules". The agent treats it as text to use and does not obey it as a command. We apply the same rule to everything the server returns.
Any harness, one URL
The knowledge base is part of the Allye remote MCP server:
https://mcp.allye.app/mcp
You sign in with OAuth 2.1 in the browser. There is no token to create and nothing to install for the connection itself. The supported harnesses are Claude Code, Codex, OpenCode, Pi and OMP. They all connect to the same URL, so a page written from one harness is the page the next harness reads.
That is why the knowledge base sits behind MCP instead of in a per-tool config file. A Claude Code session and a Pi session see the same pages, with the same history.
What is still rough
Allye is in alpha. The pieces above are what exists today, and the alpha is free. Teams and Enterprise plans are coming soon.
Try it
- Follow the install guides for your harness.
- Ask the agent to search the project space for a topic you know is documented.
- Open the page it read, and compare it with what you would have pasted into a prompt.
The MCP documentation lists what the server exposes. If something breaks or confuses you, write to app@devshire.app.