Four places context can land
Each of the four answers a different question, which is why using only one of them would not be enough.1
Session start
Everything standing that governs where the agent is about to work: the active projects, any open handoffs, files that have gone stale, and whatever signals are worth knowing before the first prompt.
2
At the prompt
Whatever bears on the thing that was just asked for. base matches the text against your domain triggers and returns the rules, prior decisions and notes attached to the domains that matched.
3
Before a tool runs
The shape of the file about to be touched — the entities inside it, what it imports, and what depends on it — placed before the agent reads a single line of it.
4
After it returns
What the result means in this codebase. For the exact lines just read, that means the call chain they sit in, delivered while it is still the thing being thought about.
How it decides what is relevant
What arrives is chosen by what is happening at that moment, which is what keeps it short. Opening a billing file returns the billing rules and the decision that governs them. It does not return the auth rules, the deployment notes, or a summary of the project. This matters for two reasons that pull in the same direction. Nobody is paying to send a model everything it might conceivably need. And a model given a briefing it did not ask for tends to hedge its way through the parts that do not apply. You can see exactly what a given piece of text would pull before you send it:domains.toml; the rules, decisions and notes attached to the domain live in the graph.
You can also just ask, and the answer comes out of the same place:
What base is holding
Four kinds of thing, all in one graph, all connected to each other. Your code. Every function, struct, class, import and call relationship, extracted by tree-sitter across more than thirty-five languages. “What calls this?” is a query rather than a search across files. Your work. Projects with their milestones and tasks. Decisions with the reasoning that produced them. Rules that fire when the context matches. This is the material that otherwise lives in somebody’s head, or in a wiki that was last accurate in March. Your documents. Markdown with frontmatter becomes connected nodes — headings, links, wikilinks and tags all become edges. When an agent writes markdown, the hook teaches it the extraction contract at the moment of writing, so new documents are structured correctly as they are created rather than cleaned up afterwards. Your operations. Which domains are active, what changed since the last session, what has gone stale, what is still open. All of it is stored as plain-text NQuads files that live in your repository and diff in git. Queries run through SPARQL against an embedded Oxigraph instance loaded from disk per invocation, so nothing base needs is behind a network call.Sessions that carry over
Work does not usually finish inside one session, so base treats the seam between sessions as something to manage rather than something to survive. Four star commands cover it, typed straight into the chat:
Open handoffs resurface on their own at the next session start. Star commands are defined in
commands.toml and are fully customizable — run base commands list to see what is currently loaded.
When several sessions are running at once, they coordinate through the relay. It gives each session a stable title, instant pings between them, task hand-offs that fire inside the receiving session’s hooks, and a board showing who is alive and what is pending.
When a hook fails
The hooks are designed to fail open. If base cannot answer, the turn proceeds without the injection rather than blocking on it. A session that loses its briefing is worse off than one that never had it; a session that cannot start at all is worse than both. To check the health of the graph itself, runbase doctor. It reports across both tiers and exits nonzero when something is wrong.