Context Hubs

Tiered Context Loading for Agent Systems

Agents should not crawl everything by default. Good runtime design lets them inspect context progressively, loading only what they need.

One of the fastest ways to make an agent slower, more expensive, and less reliable is to give it too much context too early. Tiered context loading turns context discovery into a staged process so the runtime has a navigation system, not just a pile of files.

Key Facts

Context zones: Identity, inbox, areas, projects, knowledge, archive
Loading model: L0 .abstract.md, L1 .overview.md, L2 full files
Primary goal: Progressive inspection instead of blanket retrieval
Common failure: Stale or over-loaded context
Use with: Filesystem hubs, MCP resources, agent memory

What belongs in a context hub for an agent system?

A strong context hub separates who the system is acting for, what arrived recently, what work is underway, what reference knowledge is stable, and what should be archived. One practical pattern is a version-controlled `context-hub/` root with `0-identity`, `1-inbox`, `2-areas`, `3-projects`, `4-knowledge`, and `5-archive`. That makes retrieval inspectable and prevents the runtime from treating every file as equally relevant.

Why does tiered loading matter so much?

Tiered loading protects latency, attention, and judgment. Agents should begin with `L0 .abstract.md` files for fast routing, move into `L1 .overview.md` when a branch becomes relevant, and only open `L2` full files when evidence or action requires the extra detail. MCP can expose these layers as resources or prompts, but the context-hub shape is useful even when the runtime reads straight from a repository or filesystem.

Distribution

Distribute the same doctrine to tools

The public MCP and exports keep the stable doctrine easy to retrieve without forcing full-page crawls.

Open For agents

Examples

Inspect runtime patterns in examples

Implementation examples help teams see how context loading shows up in real retrieval and orchestration code.

Open examples

Build context like a durable operating model

When context has stable zones and loading tiers, agents can reason about what they know, what they have not inspected yet, and what should remain out of scope until a task justifies it.

Context-hub directory shape

One practical filesystem pattern is a version-controlled `context-hub/` root with stable numbered zones for identity, capture, active work, reference knowledge, and completed material.

0-identity: mission, goals, values, and who the work belongs to

1-inbox: unsorted capture, new requests, and interrupts

2-areas / 3-projects / 4-knowledge / 5-archive: ongoing work, time-bound work, reference, and done items

L0 and L1 tiered loading

Use compact `.abstract.md` files for fast routing and `.overview.md` files for structure, status, workflows, and relationships before loading source-heavy branches.

Fast routing first

Keep stale markers visible

Avoid loading large files eagerly

L2 full files only when working

Move from `.overview.md` into full files only after the task, blocker, or evidence requirement makes the expansion necessary.

Overview for situational framing

Full file only for action or verification

Record what was opened for auditability

Continue through the runtime branch

This branch is meant to work as one library. Use the other guides to complete the operating model beyond the current topic.

Execution Layers

Triggers vs Schedules vs Interactive Agents

One of the most common mistakes in agent systems is forcing every task through a conversational interface. A more reliable approach is to separate three execution layers: triggers for event-driven work, schedules for recurring background work, and interactive agents for dynamic tasks that need clarification, judgement, or iteration.

Runtime Safety

Safe Delegation to Heavy Runtimes

Modern agent systems increasingly combine a lightweight tool-using agent with a heavier runtime that can browse, run shell commands, inspect files, or operate more autonomously over many steps. The design question is when delegation is justified, how it is bounded, and how it can be reviewed afterwards.

Why not just use retrieval over everything?

Because unrestricted retrieval can still pull noisy, stale, or irrelevant material. Tiered loading gives the runtime a better inspection path.

Is this only for markdown file systems?

No. The same pattern works for document stores, MCP resources, internal knowledge bases, and structured repositories.

Should agents ever skip the overview layer?

Yes, for very small or very explicit tasks. But as a general runtime rule, overview-first inspection reduces context waste.

Continue through the runtime branch

This branch is meant to work as one library. Use the runtime landing page to recover the full operating picture, then move into principles when you need to reconnect runtime decisions to doctrine.

Back to landing page Open principles