NAI OS

Context: two axes, not one ranking

Scope and timing decide what loads. Precedence is a separate question, for when what's loaded disagrees.

Context: two axes, not one ranking

Back to the vocabulary, which already said it in passing: “the difference that matters is context.” This page unpacks that. “Context” gets used loosely — CLAUDE.md, skills, commands, subagents, and the data flowing through all of them get flattened into one vague ranking. It reads more clearly split along two separate axes.

Axis 1: scope and loading

Layer	Loaded	Notes
CLAUDE.md	Always	Layered: enterprise, then project (repo), then user — the user layer is effectively your personal profile
Skills	On demand	Pulled in when the description matches the task. Lazy by design
Commands	On invocation	User-invoked prompt templates (`/name`), injected when called
Subagents	Never — own context	The odd one out: they don't load into the running window at all, they run in their own and return only a result
Data	Streamed	Arrives on the fly as input, not as a competing instruction

Axis 2: precedence (when instructions conflict)

System/enterprise, then your explicit instruction, then CLAUDE.md, then skill guidance. Data is not “lower” on this list — it sits outside it. It's input, not an instruction competing for priority.

%%{init: {'theme':'neutral', 'flowchart':{'nodeSpacing':50,'rankSpacing':70}}}%%
flowchart TB
    subgraph CW ["Shared context window (finite token budget)"]
        direction LR
        C["CLAUDE.md<br/>always loaded<br/>enterprise / project / user"]
        S["Skills<br/>lazy, model-decided"]
        CMD["Commands<br/>user-invoked /name"]
        D["Data<br/>streamed on the fly"]
    end

    A["Subagent<br/>own separate context<br/>returns result only"]

    CW -.->|"spawns"| A
    A -.->|"result"| CW

    P["Precedence when conflicting:<br/>system/enterprise > your instruction > CLAUDE.md > skill"]

    classDef always fill:#dbe9fb,stroke:#1f6feb,stroke-width:2px
    classDef lazy fill:#dcefe9,stroke:#0f6f63,stroke-width:2px
    classDef data fill:#ece5f7,stroke:#6b3fa0,stroke-width:2px
    classDef agent fill:#fdf3e0,stroke:#8a5a00,stroke-width:2px
    classDef note fill:#f4f1ea,stroke:#8a7a5a,stroke-width:2px
    class C always
    class S,CMD lazy
    class D data
    class A agent
    class P note

Everything in the top box shares one finite token budget. The subagent is the one exception — it spawns from that budget but answers back with a result, never by sharing the window itself.

Why it's structured this way

Everything except the subagent shares one finite context window. Lazy-loading skills and commands isn't about importance, it's token economy — you keep the always-on layer (CLAUDE.md) small and pull in the rest only when needed. That's also why a subagent's isolation matters beyond tidiness: see why the promise holds for what that isolation buys on the tool-grant side.

The rule this serves

Scope and timing decide what loads. Precedence is a separate axis, for when what's loaded disagrees. Collapsing both into a single chain like CLAUDE.md > skills > data is the mistake — it conflates "how much of the budget this costs" with "who wins an argument," and getting that distinction right is what keeps agent behavior predictable at scale.

Full write-up at docs/context-in-agents.md.

NextOne offline knowledge base, six agents →