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

For decades, communication happened around software development.

Meetings. Slack. Email. Documents. Architecture reviews. Status updates. Another meeting to explain what happened in the previous meeting.

That arrangement was tolerable while implementation was expensive. Writing, testing, and deploying software consumed most of the effort. Communication was overhead, but implementation was still the dominant cost.

AI changes that equation.

As I explored in The Software Engineer’s Multi-Agent Flow, capable engineers can increasingly delegate implementation, testing, review, and documentation across specialized agents. In Looking Ahead: Stronger Models, Better Harnesses, Different Work, I argued that the model is only one part of the system. The harness around it, including tools, permissions, retrieval, memory, validation, and orchestration, determines what useful work the agent can actually perform.

Implementation is getting cheaper.

Context is not.

Engineering 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 does it affect the enterprise?
  • Which architecture document is current?
  • Why does this apparently unnecessary test exist, and what production scar tissue does it represent?

Those are not search problems alone. They are questions about authority, scope, inheritance, and ownership.

I believe this is the next bottleneck in AI-native software delivery. We do not simply need better coding agents. We need an operational architecture for organizational memory.

The broader emerging discipline is often called ContextOps. I call this specific architectural pattern Hierarchical Context.

More Tokens Are Not the Same as Better Context

The tempting response to weak AI output is to provide more information.

Sometimes that works. Sometimes it creates a larger haystack and congratulates the model on receiving more hay.

Research already gives us reason to be careful. The paper Lost in the Middle found that language-model performance can change substantially depending on where relevant information appears inside a long context. Models often performed better when the relevant evidence appeared near the beginning or end than when it was buried in the middle.

The practical lesson is not that long context is useless. It is that context capacity and context usability are different properties.

Experienced engineers understand this intuitively. A senior engineer debugging a billing service does not begin by reading every engineering document the company has produced since the first office coffee machine was installed.

They narrow the problem:

  1. What enterprise constraints always apply?
  2. What architecture does this organization share?
  3. What does this team own?
  4. What is specific to this service and incident?

That is hierarchical context.

The goal is not to make the model read everything. The goal is to make the relevant context easy to inherit, locate, trust, and verify.

From DevOps to ContextOps

DevOps made operational responsibility part of software delivery.

Infrastructure as Code made infrastructure reviewable and repeatable.

GitOps made declared state in Git an operational control point.

Platform Engineering created supported paths through recurring complexity.

ContextOps applies similar discipline to organizational knowledge:

ContextOps is the practice of creating, governing, versioning, assembling, and routing operational context for humans and AI.

This is a proposed framework, not an established industry standard. It is also not a claim to have invented the word.

ContextOps Is an Emerging Term

During research for this article, I found several public uses of ContextOps. Some are very close to the problem described here:

  • CogniSwitch frames ContextOps as making organizational knowledge a first-class, owned, and validated part of enterprise AI.
  • Packmind uses the term for governing, versioning, distributing, and evolving the context supplied to coding agents.
  • Context Stack defines ContextOps as the organizational governance layer for AI-context ownership, freshness, roles, and lifecycle.
  • skillCI uses “Context Ops” for analyzing agent sessions and distributing improvements to shared rules and instruction files.
  • The contextops Python package applies the name to deterministic inspection and CI linting of LLM context payloads.

ContextOps is not yet a widely accepted discipline with one stable definition. These uses overlap around context quality, governance, ownership, and distribution, but differ in scope and implementation.

That convergence is useful evidence that the underlying problem is real. It also means the useful question is not who planted a flag on the noun first. Software engineering has survived several people naming approximately the same thing before breakfast.

The contribution I am proposing is more specific:

Hierarchical ContextOps for the software delivery lifecycle: operational Git hubs organized as enterprise → organization → team → service, with explicit inheritance, contracts, routing, provenance, and deterministic assembly for humans and AI agents.

The surrounding mechanisms are familiar. The claim is that they belong together as a deliberate architecture for AI-native engineering organizations.

Existing pattern What it contributes to ContextOps
Git Version history, review, ownership, rollback, distributed collaboration
DNS Hierarchical naming, delegation, local authority, resolvable addresses
Kubernetes Declarative state, composition, validation, reconciliation
Platform Engineering Golden paths and shared capabilities without centralizing every decision
Context engineering Selecting and assembling evidence for a specific reasoning task

The analogy is not that an enterprise is literally a Kubernetes cluster. Employees generally object when you try to reschedule them after a failed health check.

The analogy is structural: these systems scale by defining boundaries, authority, composition, and protocols.

Communication Needs an Address

Engineering knowledge is often treated like a broadcast message.

An architecture decision appears in Slack. A migration plan lives in a project wiki. A runbook sits in a personal folder. A security rule hides inside a 90-page PDF. Six months later, an engineer asks where the source of truth is and receives three links plus a shrug.

Search can help locate those artifacts. It cannot reliably answer:

  • Which artifact is authoritative?
  • At what organizational scope does it apply?
  • What superseded it?
  • Who must approve a change?
  • Which services inherit it?
  • Which local exception is valid?

DNS is a useful analogy because it was designed around growth, distributed administration, and hierarchy. RFC 1034 describes a tree-structured namespace partitioned into locally administered zones. No single administrator must manage every name, yet the overall system remains addressable.

Context needs a similar 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.

This turns “where did we write that down?” from organizational folklore into a resolvable query.

Hierarchical Context

The hierarchy should mirror the way engineering authority already works:

Enterprise Hub
      ↓
Organization Hub
      ↓
Team Hub
      ↓
Service or Domain Repository

Each level owns a different class of decisions.

Level Owns Examples
Enterprise Constraints that apply broadly Security policy, compliance, engineering principles, AI governance
Organization Shared architecture and execution Platform APIs, reference architectures, roadmaps, migrations
Team Operational practice and ownership Runbooks, recurring incidents, deployment practice, team prompts
Service/domain Implementation truth Code, tests, configuration, specifications, ADRs

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.

Enterprise Hub

The Enterprise Hub contains context that should influence almost every engineering decision:

  • security and privacy requirements,
  • compliance constraints,
  • engineering principles,
  • platform strategy,
  • approved architectural patterns,
  • AI governance,
  • and company-wide coding or operational standards.

This is not onboarding material to read once and forget. It is context every relevant AI workflow should inherit before proposing production changes.

Organization Hub

An Organization Hub owns problems that multiple teams should not repeatedly rediscover:

  • shared platforms,
  • common APIs,
  • reference implementations,
  • migration plans,
  • architectural decisions,
  • operational playbooks,
  • and cross-team roadmaps.

If five teams depend on a capability, the knowledge should not be copied into five repositories and allowed to evolve into five different truths.

Team Hub

The Team Hub is the operational center:

  • service ownership,
  • escalation paths,
  • deployment practice,
  • recurring incidents,
  • dashboards,
  • domain-specific standards,
  • and reusable AI instructions.

This layer connects enterprise intent to daily delivery.

Service and Domain Repositories

Closest to implementation sits the service itself:

  • source code,
  • tests,
  • configuration,
  • deployment definitions,
  • specifications,
  • and Architecture Decision Records.

This is where broad policy becomes concrete behavior.

These Are Not Documentation Repositories

The word hub can sound suspiciously like “we made another wiki.”

That is not the proposal.

A Context Hub is an operational Git repository. Git’s distributed model gives each clone history rather than only the latest snapshot, as described in the official Pro Git explanation of distributed version control. Applied to operational knowledge, that gives us useful properties:

  • changes arrive through pull requests,
  • ownership is reviewable,
  • history is attributable,
  • incompatible changes can be discussed before publication,
  • previous states can be recovered,
  • automation can validate structure and references.

Markdown alone does not create ContextOps. Putting neglected documents in Git merely gives the neglect commit hashes.

The operational part comes from governance and automation:

  • schemas for hub metadata,
  • required owners,
  • context contracts,
  • link and freshness checks,
  • inheritance validation,
  • change notifications,
  • and deterministic context assembly.

Context Inheritance

A service should not redefine enterprise security policy.

A team should not copy organizational architecture into every repository.

An organization should not fork company principles because the original document was inconvenient to find.

Context should flow downward:

Enterprise constraints
        ↓
Organization architecture
        ↓
Team operating practices
        ↓
Service implementation

Each layer extends the context above it. Local context may specialize a rule or declare an approved exception, but it should not silently contradict inherited policy.

Kubernetes offers a useful, limited analogy. Its declarative workflow stores desired object configuration and applies changes through explicit configuration, as documented in the Kubernetes guide to declarative management. ContextOps similarly benefits from declared state: what the organization says should be true becomes reviewable and machine-readable.

But inheritance creates risks:

  • stale parent context can poison every descendant,
  • conflicting rules may be resolved inconsistently,
  • local exceptions may become permanent loopholes,
  • and broad context may overwhelm narrow tasks.

Therefore 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.

Context Contracts

Hierarchy handles inherited knowledge. Cross-team work requires another mechanism.

A context contract defines how operational knowledge crosses a boundary:

  • who produces it,
  • who consumes it,
  • which artifacts are required,
  • how changes are delivered,
  • what compatibility promise exists,
  • and when consumers must act.

For example, a platform API deprecation might require:

Contract field Example
Producer Platform organization
Consumers Checkout, billing, identity teams
Artifacts RFC, migration guide, deprecation notice
Delivery Pull request plus change event
Compatibility Existing version supported for 180 days
Required response Owner acknowledgement and migration plan

That is more precise than posting “FYI, this may affect some teams” in a channel with 600 members and trusting emoji reactions as governance.

The idea connects directly to The AI-Executable Ticket: when work becomes executable by agents, intent, constraints, evidence, and validation criteria become load-bearing inputs rather than administrative decoration.

The companion article Async by Default: A Cross-Team Communication Protocol for the AI-Native SDLC develops this contract into a complete operating protocol: typed changes, routing, acknowledgement, response windows, verification, and synchronous escalation.

Context Routing

Search waits for someone to ask.

Routing acts when context changes.

When an architectural decision lands in an Organization Hub, automation should be able to:

  • identify affected services,
  • suggest accountable reviewers,
  • detect conflicting decisions,
  • create migration tasks,
  • update dependent context indexes,
  • and produce audience-specific summaries.

This does not mean allowing an AI agent to rewrite half the enterprise because someone changed a Markdown heading.

It means treating context changes as events with known consumers.

Routing 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.

AI Should Read Context the Way Engineers Build Understanding

Imagine asking an agent to modify a billing service.

Today, we often provide the repository and hope the code contains enough archaeology to explain itself.

In a ContextOps model, the harness assembles a task-specific bundle:

  1. Enterprise security and compliance constraints.
  2. Organization-level payment architecture.
  3. Team ownership and deployment practice.
  4. Service specifications, ADRs, code, and tests.
  5. Ticket-specific intent and acceptance criteria.
  6. Relevant incidents and recent changes.

This is not “load every hub.” It is a resolution process.

The agent should receive only the applicable artifacts, with provenance and precedence. That supports the layered communication model I described in How Teams Learn to Trust AI: orientation before detail, claims connected to evidence, and visible reasoning inputs rather than private context bundles.

Better context does not guarantee correct output. It narrows ambiguity and makes mistakes easier to audit.

Organizational Memory Becomes Infrastructure

Every consequential engineering event can improve future reasoning:

  • an incident records a failure mode,
  • an ADR records a tradeoff,
  • a migration records a safe sequence,
  • a runbook records a recovery path,
  • a rejected proposal records a boundary,
  • a pull request records how an abstract standard became code.

If those artifacts remain isolated, they decay into history.

If they are owned, linked, versioned, and routable, they become organizational memory.

That memory matters to humans and AI for the same reason: neither can make good decisions from information they cannot find, interpret, or trust.

This is also why ContextOps is not a substitute for teams. In What About Teams?, I argued that teams are systems of trust, context, and resilience, not merely containers for tickets. ContextOps makes part of that shared understanding explicit. It does not replace the judgment and relationships that created it.

A Practical Starting Point

The full vision can become elaborate. Do not begin by building a graph database, seven agents, and a dashboard shaped like an airport control tower.

Start with one path:

  1. Create an enterprise hub with a small set of authoritative principles.
  2. Add one organization hub and one team hub.
  3. Connect a single service repository through explicit parent references.
  4. Define owners and sensitivity for every artifact.
  5. Assemble a deterministic context bundle for one real engineering task.
  6. Validate links, ownership, and inheritance in CI.
  7. Measure whether the bundle improves decisions, review time, or rework.

The companion ContextOps reference repository demonstrates that minimal shape with:

  • hub.yaml manifests,
  • enterprise, organization, team, and service examples,
  • context-contract schemas,
  • ADR and runbook templates,
  • deterministic context assembly,
  • and CI validation.

It is a reference implementation, not proof that the framework works at enterprise scale. The next step is to test the model against real organizational change, especially where ownership is ambiguous and policy conflicts are expensive.

The Real Competitive Advantage

Soon, access to strong models will be common.

Model capability will still matter. Harness quality will matter. But organizations using similar models may produce very different outcomes because their internal context differs.

One organization will give an agent a repository and a vague ticket.

Another will give 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.

That is the central ContextOps thesis:

The quality of AI-assisted engineering will increasingly depend on the quality of the organizational memory available to both humans and machines.

Git transformed how we manage source code.

ContextOps proposes a similar discipline for source context: structured, versioned, inheritable, attributable, and operational.

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.