Build a governed
context supply chain.
Agents often fail not because the model is incapable, but because it uses the wrong, stale, or unauthorized context at the wrong time. DHF does not try to make an agent know everything. It supplies the smallest trustworthy state the current work needs—and makes clear what that state permits.
Context is a finite workspace
Every instruction loaded up front consumes room the task could use for reasoning, evidence, and decisions.
Capacity is finite
A longer prompt does not create a larger working space. Upfront content occupies the same finite box the active task needs.
Relevance protects quality
Irrelevant material weakens retrieval and decision quality, even when every individual fact is correct.
Three inputs make context useful
Useful context combines reach, organization-specific knowledge, and a just-in-time delivery mechanism.
Access
What repositories, systems, files, and services the agent can reach—and where access must stop.
Institutional Knowledge
What the organization knows that the model does not naturally know: terminology, decisions, ownership, and operating constraints.
Tooling
How the right information enters at the right event or task stage instead of occupying every prompt.
Information enters action, then returns as fact
Select trustworthy facts, recover position, shape by need, observe pressure, constrain action, and preserve actual results.
- Trusted SourcesRules, maps, ADRs, source, and state
- Session BearingRecover current position
- Prompt ShapingLoad by stage and risk
- Context PressureObserve compaction and capacity
- PreTool GuardTurn context into permission
- PostTool EvidenceRecord what happened
- CheckpointForm the next context
Use the smallest primitive that delivers context on time
Choose by trigger and context cost, not by novelty.
| Primitive | Use when | Context cost | DHF role |
|---|---|---|---|
| Hook | An event should decide whether information is relevant | Pay only when relevant | Guard, Evidence, Bearing |
| Skill | The task needs complete specialist guidance | Description stays resident; body loads on demand | Specialist workflow |
| Sub-agent | Work needs an independent reasoning window | Parent receives a compact result | Isolated research or review |
| MCP/Tool | Work needs an external capability | Names and schemas consume context | Permission-governed execution |
Memory is not governed context
Historical clues become useful only after source, timing, freshness, and permission select them for the current task.
Memory
Model-curated historical clues. Useful for search, but not an authority surface.
Context
Task-relevant information selected by source, timing, freshness, and permission.
Checkpoint
Durable, recoverable task state with boundaries and a next safe action.
Evidence
The recorded outcome of actual execution, with enough detail to verify the claim.
Define what counts as context
Information with different stability, purpose, and trust levels should not be mixed into one ever-growing prompt.
| Context type | Primary carrier | Question answered |
|---|---|---|
| Stable rules | AGENTS.md | What must the agent obey? |
| Repository map | docs/repo-index.md | Where should facts be found? |
| Business language | CONTEXT.md | What do shared terms mean? |
| Current state | Harness state | Where is the task now? |
| Decision basis | Requirements, ADRs, contracts | Why was this path chosen? |
| Real implementation | Git, source, tests | What exists now? |
| Execution evidence | Local evidence | What actually happened? |
| Chat history | Lowest-priority hint | Where should we look next? |
Order the sources
Repository rules → low-token map → terminology contract → current state → decision contracts → source and Git → local evidence → chat history.
Preserve conflicts
When durable sources disagree, do not pick the plausible one. Conflicts affecting architecture, data, security, or release enter an ADR or architecture checkpoint.
Session Bearing is a business navigation card
After interruption, the dangerous loss is not a paragraph. It is the loss of stage, boundary, ownership, and next-step orientation.
phase
Research, planning, development, verification, release, or handoff.
next_safe_task
The next action that does not require guessing.
boundary_verdict
Whether current state and evidence are sufficient to continue.
dirty_status
Whether the workspace contains unowned or unverified changes.
Do not guess missing state
Missing state, damaged format, unknown verification time, or indeterminate workspace state returns unknown. When authority is required, unknown is unsafe.
Small and trustworthy
Inject only the current phase, confirmed facts, blockers, and next safe action—not the full conversation or state log.
Context is a control input, not just a reference
Task phase, execution lane, scope, risk, and authorization jointly decide whether a tool call is allowed or blocked.
Prompt Shaping
light keeps simple work lean; standard adds normal recovery and verification; governed covers privacy, architecture conflict, remote, or destructive work.
Context Pressure
Observe compaction the host actually reports. If token data is unavailable, report unknown rather than inventing remaining capacity.
PreTool Guard
Before execution, read phase, lane, scope, risk, and authorization, then turn context into executable permission.
PostTool Evidence
After execution, record the actual result and distinguish decision evidence from routine evidence.
Actual results must leave the chat
Verified stage, change, blocker, and next safe task become a checkpoint. The next session recovers from durable fact, not old conversation.
Checkpoint
Preserve phase, verification evidence, remaining risk, and next safe action. A checkpoint is recovery input, not another name for a commit.
Multi-agent isolation
Each agent needs explicit ownership, scope, and evidence boundaries. A shared repository does not imply shared write authority.
Freshness
A new commit, relevant source change, or external-state change can expire evidence. Historical green cannot support a new completion claim.
Closed loop
Sources → Bearing → Guard → execution → Evidence → Checkpoint → new Bearing.
Current capability and roadmap stay separate
This page explains the design; it does not prove current source, runtime, or production state. Use the status page and fresh verification for that.
Current supply chain
- Source ordering
- Session Bearing
- Prompt Shaping
- PreTool Guard
- PostTool Evidence
- Checkpoint / Recovery
Next-stage capabilities
- Tighter immediate feedback loops
- Context budgets
- Access catalogs
- Fleet and attention views