Hierarchical Context

Software engineering has source code. AI-native engineering needs source context.

When implementation accelerates, the cost of finding and resolving context can become more visible. The balance varies by task and organization; the design problem remains when agents and people cannot identify the governing information. Organizations still spend enormous energy answering basic questions: has another team solved this, which standard applies, who owns this capability, is this decision local or enterprise-wide, why does this apparently unnecessary test exist?

Those are not search problems. They are questions about authority, scope, inheritance, and ownership. I believe this is the next bottleneck in AI-native delivery. We do not simply need better coding agents. We need an operational architecture for organizational memory. I call that architecture Hierarchical Context.

More tokens is not better context

The tempting response to weak AI output is to provide more information. Sometimes that works. Sometimes it just builds a larger haystack and congratulates the model on receiving more hay. Research on Lost in the Middle found that model performance changes depending on where relevant information sits in a long context, often worse when the evidence is buried in the middle.

The lesson is that context capacity and context usability are different properties. A senior engineer debugging a billing service does not read every document the company has produced. They narrow: what enterprise constraints always apply, what architecture this organization shares, what this team owns, what is specific to this service. That is hierarchical context. The goal is not to make the model read everything. It is to make the relevant context easy to inherit, locate, trust, and verify.

Communication needs an address

Engineering knowledge is usually treated like a broadcast. A decision appears in Slack, a migration plan in a wiki, a security rule inside a 90-page PDF. Search can locate those artifacts but cannot reliably answer which one is authoritative, at what scope it applies, what superseded it, or who must approve a change.

DNS is the useful analogy: RFC 1034 describes a tree-structured namespace partitioned into locally administered zones. No single administrator manages every name, yet the whole system stays addressable. Context needs the same property. Every durable piece of operational knowledge should have a stable address, an accountable owner, a declared scope, a lifecycle, a sensitivity classification, and explicit relationships to the context above and below it. That turns “where did we write that down?” from folklore into a resolvable query.

The hierarchy

The hierarchy should mirror the organization’s actual decision rights. The four levels below are a proposed pattern, not a requirement to create four management layers.

OpenAI’s harness-engineering account describes a short instruction map pointing into maintained repository knowledge. Anthropic’s context-engineering guidance supports selective retrieval and deliberate context management. Both inform the design here; neither validates this particular enterprise hierarchy.

The repository still answers how the service works. The hubs explain why it works that way, what constrains it, and who can change the rules. Context flows downward: enterprise constraints, then organization architecture, then team practices, then service implementation. Each layer extends the one above it. Local context may specialize a rule or declare an approved exception, but it must not silently contradict inherited policy.

Hubs are operational, not another wiki

The word “hub” can sound like “we made another wiki.” It is not. A Context Hub is an operational Git repository. Changes arrive through pull requests, ownership is reviewable, history is attributable, incompatible changes can be discussed before publication, and automation can validate structure and references.

The operational part comes from governance and automation: schemas for hub metadata, required owners, link and freshness checks, inheritance validation, change notifications, and deterministic context assembly. This is the discipline I call Context as Infrastructure: treating organizational knowledge as a maintained system rather than a pile of documents.

The team hub matters more once agents act on the team’s behalf. As a proposal, it would record what such an agent needs to stay within the team’s intent: the team’s responsibilities, the roles assigned to agents, their permissions and budgets, and the durable lessons the team has accepted. Fast-changing execution state, such as task status, locks, and event streams, stays in the operational systems that own it; the hub links to those systems rather than copying them. Personnel detail, private conversations, and assumptions nobody has approved stay out entirely. A hub that absorbs them becomes harder to trust and harder to correct.

Inheritance has risks

Inheritance is powerful and dangerous. Stale parent context can poison every descendant. Conflicting rules may be resolved inconsistently. Local exceptions can become permanent loopholes. Broad context can overwhelm a narrow task. So inheritance must be selective, traceable, and testable. An assembled context bundle should show where every rule came from, which version supplied it, and whether a local exception changed it.

Routing acts when context changes

Search waits for someone to ask. Routing acts when context changes. When a decision lands in an Organization Hub, automation can identify affected services, suggest reviewers, detect conflicting decisions, and create migration tasks. This depends on a context graph connecting hubs, teams, services, owners, APIs, decisions, incidents, and contracts. The hierarchy tells us where authority lives. The graph tells us what a change affects. Turning those change events into a full protocol, typed, routed, acknowledged, and verified, is the subject of Async by Default.

The real competitive advantage

Soon, access to strong models will be common. Organizations using similar models will produce very different outcomes because their internal context differs. One gives an agent a repository and a vague ticket. Another gives it inherited policy, architecture, ownership, evidence, operational history, and explicit validation. The difference will look like model intelligence. Much of it will actually be organizational intelligence. Better context also changes the unit of work: when the governing decisions are easy to inherit, the largest task an agent can reliably complete grows, as The AI-Executable Ticket describes.

The organizations that move fastest may not be the ones generating the most code. They may be the ones whose collective knowledge is organized well enough that every engineer and every agent can build on what the organization already knows.

This context architecture also determines whether the operating model can be applied to a specific company. Applying the Book: From Operating Model to Company Playbook defines the readiness assessment and mapping process. When company state is not sufficiently authoritative, current, or traceable, building hierarchical context becomes the first playbook.

Assemble the evidence for one run

In the fictional Northstar case, CTX-42 resolves five sources: the enterprise access policy, the Orders owner map, accepted ADR-17, the repository’s transaction guidance, and ORD-42. Each is pinned to a revision. The agent receives synthetic reports and approved code context, not an unrestricted copy of internal systems.

An old proposal recommends an email-scoped key. The current accepted record requires an authenticated account boundary. The bundle preserves the old proposal as superseded background if it is useful at all. Retrieval relevance does not give it authority.

An exception is a separate record: scope, rationale, approving owner, expiry or review trigger, and the rule it changes. A service team cannot create an enterprise-policy exception merely by putting it in a local instruction file. If two apparently valid authorities conflict, the run pauses the affected action and requests resolution.

The hierarchy establishes authority; a graph describes relationships and impact. Neither grants access. A consumer must be entitled to each retrieved source and any derived summary. Broad parent context should not cause sensitive material to flow into every descendant.

The Git hub described here is one implementation of those requirements. A different system can work if it provides comparable ownership, versioning, access control, and review. The organizational design is an inference from engineering needs, not a conclusion established by the long-context study cited earlier.

To begin, assemble a manifest for one task and include one deliberately stale source. Check that the consumer can identify the governing revision and explain the conflict. Context as Infrastructure supplies the maintenance and evaluation loop.