> ## Documentation Index > Fetch the complete documentation index at: https://docs.basemode.ai/llms.txt > Use this file to discover all available pages before exploring further. # How it works > There are four points inside a single agent turn where base can place context, and it uses all of them. This page covers what gets placed at each one, how it decides what is relevant, and what base is holding that it can draw on. base wires into every hook your agent host exposes. Each one is a question asked at a specific moment, not a document loaded at the start and hoped over, so what arrives is picked for the situation the agent is actually in. ## 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. 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. 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. 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. 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. Every agent you run inherits this. The main session, subagents, explore agents: same hooks, same graph, same briefing. ## 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: ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} base context "touching the billing module" base context --list ``` Domains are what make this work. A domain is a named subject with triggers attached: keywords that match against prompts, paths that match against files. The triggers live in `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: ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}} base recall --keyword "auth" base decision search --keyword "database" ``` There is no second system for asking. It is the same content, reached deliberately instead of automatically. ## 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, and 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: | Command | What it does | | ---------- | ------------------------------------------------------------------- | | `*handoff` | Ends a session so the next one can resume where this one stopped | | `*fork` | Parks side-work that came up, without derailing what you are doing | | `*base` | Sweeps this session's decisions, tasks and learnings into the graph | | `*end` | All three at once, to close out cleanly | 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, run `base doctor`. It reports across both tiers and exits nonzero when something is wrong.