Context as Enterprise Infrastructure

[dkmcintyre]

AI-Assisted Draft | For Discussion

A Framework for Registry, Routing, and Governance

---

Introduction

As AI agents move from experimentation to production, a new category of infrastructure is emerging: context infrastructure. Just as data infrastructure evolved from files to databases to governed data platforms, context is following the same trajectory.

This document proposes a framework for managing context as a first-class enterprise asset, built on three pillars:

1. Registry - The system of record for context assets
2. Routing - The logic that determines what context loads when
3. Governance - The controls that ensure context is secure, compliant, and effective

---

The Context Problem

Current State

Today, context management is artisanal:

├── CLAUDE.md files scattered across repos
├── Prompt libraries in shared drives (unversioned)
├── Tribal knowledge ("ask Sarah, she knows the prompts")
├── Copy-paste workflows (no lineage, no audit trail)
├── Ad-hoc context selection (no routing logic)
└── No quality measurement (is this context even working?)

This approach worked for experimentation. It doesn't work for production.

The Scaling Problem

Scale	What Breaks
1 agent, 1 user	Nothing—manual management works
5 agents, 10 users	Discovery—"where's the prompt for X?"
20 agents, 50 users	Consistency—different versions in use
100 agents, 500 users	Governance—who changed what? who approved it?
Enterprise scale	Everything—context becomes ungovernable

The Consequences

Without context infrastructure:

• Inconsistent outputs - Same query, different context, different results
• Security gaps - Sensitive context loaded inappropriately
• Compliance failures - No audit trail for AI decisions
• Wasted tokens - Suboptimal context selection burns budget
• Knowledge loss - Context expertise leaves with employees
• Slow iteration - No way to test context improvements systematically

---

The Framework

Three Pillars

┌─────────────────────────────────────────────────────────────────┐
│                     CONTEXT INFRASTRUCTURE                      │
│                                                                 │
│  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐       │
│  │   REGISTRY    │  │    ROUTING    │  │  GOVERNANCE   │       │
│  │               │  │               │  │               │       │
│  │  What exists  │  │  What loads   │  │  Who controls │       │
│  │  Where it is  │  │  When & why   │  │  How it's     │       │
│  │  How it       │  │  How it's     │  │  secured      │       │
│  │  relates      │  │  optimized    │  │               │       │
│  └───────────────┘  └───────────────┘  └───────────────┘       │
└─────────────────────────────────────────────────────────────────┘

---

Pillar 1: Context Registry

Purpose

The registry is the system of record for all context assets. It answers:

• What context exists?
• Where is it stored?
• Who owns it?
• What does it depend on?
• What depends on it?
• Is it current or stale?

Asset Types

Type	Description	Examples
Skills	Reusable capabilities with instructions	Code review skill, summarization skill
Prompts	Task-specific instructions	Customer service response template
Policies	Constraints and rules	Brand voice guidelines, compliance rules
Knowledge	Reference information	Product documentation, FAQs
Agent Configs	Complete agent definitions	Customer support agent, code assistant
Examples	Few-shot demonstrations	Input/output pairs for consistency

Registry Architecture

┌─────────────────────────────────────────────────────────────────┐
│                      CONTEXT REGISTRY                           │
│                                                                 │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │  Asset Catalog                                            │  │
│  │                                                           │  │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐         │  │
│  │  │ Skills  │ │ Prompts │ │Policies │ │Knowledge│  ...    │  │
│  │  │         │ │         │ │         │ │         │         │  │
│  │  │ v1.2.3  │ │ v2.1.0  │ │ v1.0.0  │ │ v3.4.1  │         │  │
│  │  └─────────┘ └─────────┘ └─────────┘ └─────────┘         │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                 │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │  Metadata Layer                                           │  │
│  │                                                           │  │
│  │  • Identity: name, version, type, hash                    │  │
│  │  • Ownership: creator, team, steward                      │  │
│  │  • Classification: domain, sensitivity, tags              │  │
│  │  • Relationships: dependencies, dependents                │  │
│  │  • Quality: freshness, usage, effectiveness               │  │
│  │  • Lifecycle: status, promotion date, deprecation         │  │
│  └───────────────────────────────────────────────────────────┘  │
│                                                                 │
│  ┌───────────────────────────────────────────────────────────┐  │
│  │  Lineage Graph                                            │  │
│  │                                                           │  │
│  │     [Policy A]──────┐                                     │  │
│  │                     ▼                                     │  │
│  │     [Skill B]────▶[Agent X]────▶[Output 1]               │  │
│  │                     ▲            [Output 2]               │  │
│  │     [Knowledge C]───┘            [Output 3]               │  │
│  │                                                           │  │
│  └───────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘

Asset Schema

context_asset:
  # Identity
  id: uuid
  name: string
  type: skill | prompt | policy | knowledge | agent-config | example
  version: semver
  content_hash: sha256

  # Content
  content: string | structured
  token_count: int
  format: markdown | yaml | json | text

  # Ownership
  owner: team-id
  steward: user-id
  created_by: user-id
  created_at: timestamp
  updated_at: timestamp

  # Classification
  domain: string[]
  sensitivity: public | internal | confidential | restricted
  tags: string[]
  description: string

  # Relationships
  dependencies:
    - asset_ref: uuid
      relationship: requires | extends | overrides
  dependents: asset-ref[]

  # Lineage
  lineage:
    derived_from: asset-ref[]
    influenced_outputs: output-ref[]
    change_history: change-record[]

  # Quality Metrics
  quality:
    freshness_score: float
    usage_count: int
    usage_trend: increasing | stable | declining
    effectiveness_score: float
    error_rate: float
    token_efficiency: float

  # Lifecycle
  lifecycle:
    status: draft | review | active | deprecated | archived
    promoted_at: timestamp
    review_deadline: timestamp
    deprecation_date: timestamp
    successor: asset-ref

  # Routing Hints
  routing:
    triggers: condition[]
    priority: int
    required: boolean
    conflicts_with: asset-ref[]
    token_budget_min: int

Registry Operations

Operation	Description
Register	Add new asset to catalog
Update	Create new version of existing asset
Deprecate	Mark asset as superseded
Archive	Remove from active use
Search	Find assets by criteria
Resolve	Get asset with all dependencies
Diff	Compare versions
Audit	Review change history

---

Pillar 2: Context Routing

Purpose

The routing engine determines what context loads for what situation. It answers:

• Given this task, what context is relevant?
• Given this user, what context are they allowed to see?
• Given this token budget, what context fits?
• Given multiple options, what's the priority order?

Why Routing Matters

Without routing, context selection is manual and inconsistent:

Manual Approach:
User thinks → "I need the code review prompt"
User searches → Finds 3 versions, picks one
User loads → May or may not be appropriate
Result → Inconsistent, unauditable, error-prone

With routing, context selection is systematic:

Routed Approach:
Signal detected → Task is "code review" + domain is "python"
Router queries → Registry for matching context
Router evaluates → Priority, permissions, token budget
Router returns → Optimized context package
Result → Consistent, auditable, optimized

Routing Architecture

┌─────────────────────────────────────────────────────────────────┐
│                     CONTEXT ROUTING ENGINE                      │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Input Signals                                          │   │
│  │                                                         │   │
│  │  • Task type (code, analysis, writing, support)         │   │
│  │  • Domain (engineering, finance, legal, HR)             │   │
│  │  • User identity and role                               │   │
│  │  • Sensitivity level required                           │   │
│  │  • Token budget available                               │   │
│  │  • Session history / prior context                      │   │
│  └────────────────────────┬────────────────────────────────┘   │
│                           │                                     │
│                           ▼                                     │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Routing Rules Engine                                   │   │
│  │                                                         │   │
│  │  MATCH signals AGAINST rules:                           │   │
│  │                                                         │   │
│  │  IF task = "code_review"                                │   │
│  │     AND domain = "python"                               │   │
│  │     AND user.role IN ["engineer", "lead"]               │   │
│  │  THEN                                                   │   │
│  │     LOAD skill:python-review (priority: 100)            │   │
│  │     LOAD policy:code-standards (priority: 90)           │   │
│  │     LOAD knowledge:style-guide (priority: 50)           │   │
│  │                                                         │   │
│  └────────────────────────┬────────────────────────────────┘   │
│                           │                                     │
│                           ▼                                     │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Context Optimization                                   │   │
│  │                                                         │   │
│  │  Given: Candidate context set + token budget            │   │
│  │                                                         │   │
│  │  1. Sort by priority (descending)                       │   │
│  │  2. Include all "required" context                      │   │
│  │  3. Fill remaining budget by priority                   │   │
│  │  4. Apply freshness weighting                           │   │
│  │  5. Resolve conflicts (mutual exclusions)               │   │
│  │  6. Compact if needed (summarize, truncate)             │   │
│  │                                                         │   │
│  └────────────────────────┬────────────────────────────────┘   │
│                           │                                     │
│                           ▼                                     │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Output: Context Package                                │   │
│  │                                                         │   │
│  │  {                                                      │   │
│  │    assets: [resolved context assets],                   │   │
│  │    total_tokens: 12500,                                 │   │
│  │    budget_used: 0.83,                                   │   │
│  │    routing_trace: [why each asset was included],        │   │
│  │    excluded: [what didn't fit and why]                  │   │
│  │  }                                                      │   │
│  └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

Routing Rules

routing_rule:
  id: uuid
  name: string
  description: string
  priority: int

  conditions:
    - field: task_type
      operator: equals | contains | in | matches
      value: string | string[]
    - field: domain
      operator: equals | contains | in
      value: string | string[]
    - field: user.role
      operator: in
      value: string[]
    - field: sensitivity
      operator: lte | gte | equals
      value: string

  actions:
    - action: load
      asset: asset-ref
      priority: int
      required: boolean
    - action: load_group
      tag: string
      priority: int
    - action: exclude
      asset: asset-ref

  owner: team-id
  active: boolean
  effective_date: timestamp
  expiration_date: timestamp

Routing Strategies

Strategy	Description	Use Case
Rule-based	Explicit IF/THEN logic	Predictable, auditable scenarios
Role-based	User role determines context	Security and appropriateness
Domain-based	Business domain determines context	Specialized knowledge loading
Priority-based	Highest priority wins budget	Resource-constrained environments
Freshness-weighted	Prefer recently updated context	Fast-changing domains
Effectiveness-weighted	Prefer context with good outcomes	Continuous optimization
A/B routing	Split traffic between variants	Testing and experimentation
Fallback chains	Graceful degradation	Reliability and resilience

Optimization Algorithms

Token Budget Fitting:

Given:
  - Candidate assets C = [c1, c2, ..., cn] with tokens [t1, t2, ..., tn]
  - Priorities [p1, p2, ..., pn]
  - Required flags [r1, r2, ..., rn]
  - Budget B

Algorithm:
  1. Separate required (R) from optional (O)
  2. If sum(tokens in R) > B: ERROR (required context exceeds budget)
  3. Remaining = B - sum(tokens in R)
  4. Sort O by priority descending
  5. Greedily add from O while sum <= Remaining
  6. Return R + selected from O

Freshness Decay:

freshness_score = base_score * e^(-λ * days_since_update)

Where:
  - base_score = initial quality (0-1)
  - λ = decay rate (domain-specific)
  - days_since_update = age of content

---

Pillar 3: Context Governance

Purpose

Governance ensures context is secure, compliant, and effective. It answers:

• Who can create, modify, delete context?
• What approval is required for changes?
• How do we track what changed and why?
• How do we ensure context meets quality standards?
• How do we comply with regulations?

Governance Dimensions

┌─────────────────────────────────────────────────────────────────┐
│                     CONTEXT GOVERNANCE                          │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Access Control                                         │   │
│  │                                                         │   │
│  │  WHO can do WHAT to WHICH context?                      │   │
│  │                                                         │   │
│  │  Roles: viewer | contributor | approver | admin         │   │
│  │  Scopes: asset | domain | team | organization           │   │
│  │  Actions: read | create | update | delete | approve     │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Change Management                                      │   │
│  │                                                         │   │
│  │  HOW do changes get approved and tracked?               │   │
│  │                                                         │   │
│  │  Workflows: draft → review → approved → active          │   │
│  │  Approvals: peer review, owner sign-off, automated      │   │
│  │  Rollback: instant revert to any previous version       │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Audit & Compliance                                     │   │
│  │                                                         │   │
│  │  WHAT happened, WHEN, and WHY?                          │   │
│  │                                                         │   │
│  │  Audit log: immutable record of all changes             │   │
│  │  Lineage: what context influenced what output           │   │
│  │  Retention: configurable history preservation           │   │
│  │  Reports: compliance evidence generation                │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Quality Management                                     │   │
│  │                                                         │   │
│  │  HOW do we ensure context is effective?                 │   │
│  │                                                         │   │
│  │  Metrics: freshness, usage, effectiveness, errors       │   │
│  │  Alerts: stale content, declining effectiveness         │   │
│  │  Reviews: periodic quality assessments                  │   │
│  └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

Access Control Model

Role-Based Access Control (RBAC):

Role	Read	Create	Update	Delete	Approve	Admin
Viewer	✓
Contributor	✓	✓	own
Reviewer	✓	✓	own		✓
Owner	✓	✓	✓	✓	✓
Admin	✓	✓	✓	✓	✓	✓

Scope Hierarchy:

Organization
└── Domain (e.g., Engineering)
    └── Team (e.g., Backend)
        └── Asset (e.g., python-review skill)

Change Management Workflow

┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│  DRAFT  │───▶│ REVIEW  │───▶│APPROVED │───▶│ ACTIVE  │
└─────────┘    └─────────┘    └─────────┘    └─────────┘
     │              │              │              │
     │              │              │              ▼
     │              │              │         ┌─────────┐
     │              │              │         │DEPRECATED│
     │              │              │         └─────────┘
     │              │              │              │
     │              ▼              │              ▼
     │         ┌─────────┐        │         ┌─────────┐
     └────────▶│REJECTED │        └────────▶│ARCHIVED │
               └─────────┘                  └─────────┘

Audit Trail

audit_record:
  id: uuid
  timestamp: datetime
  actor: user-id
  action: create | update | delete | approve | reject | load | route
  asset_id: uuid
  asset_version: semver

  changes:
    - field: string
      old_value: any
      new_value: any

  routing_context:
    task_type: string
    signals: object
    rules_matched: rule-id[]
    budget: int
    tokens_used: int

  reason: string
  ticket: string
  ip_address: string
  user_agent: string

Quality Framework

Dimension	Metric	Target	Alert Threshold
Freshness	Days since update	< 90 days	> 180 days
Usage	Loads per week	Depends on asset	Declining trend
Effectiveness	Success rate of outputs	> 90%	< 80%
Error Rate	Failures when loaded	< 5%	> 10%
Token Efficiency	Value per token	Benchmarked	Below baseline
Coverage	% of tasks with context	> 95%	< 90%

---

The Emergent Pattern

How Teams Discover This Structure

When teams iterate toward production agents, they discover these needs organically:

Phase	Pain Point	Discovery
1	"Where's the prompt I wrote?"	Need a registry
2	"Which version should I use?"	Need versioning
3	"Why did the output change?"	Need lineage
4	"Who changed this?"	Need audit trail
5	"Can I trust this prompt?"	Need quality metrics
6	"Why did it load that context?"	Need routing transparency
7	"Who approved this change?"	Need change management
8	"Is this compliant?"	Need governance

The framework doesn't impose structure—it captures the structure that emerges naturally when teams scale AI agents.

The Maturity Model

Level 1: Ad-Hoc
├── Context in code and docs
├── Manual selection
└── No governance

Level 2: Managed
├── Central storage (shared drive, wiki)
├── Informal ownership
└── Basic versioning

Level 3: Defined
├── Registry with metadata
├── Explicit ownership
├── Formal change process

Level 4: Measured
├── Quality metrics
├── Usage tracking
├── Effectiveness measurement

Level 5: Optimized
├── Automated routing
├── Continuous improvement
├── Predictive quality management

---

Integration Points

With AI Agents

Agent Request:
{
  task: "code_review",
  domain: "python",
  user: "engineer-123",
  budget_tokens: 15000
}

Framework Response:
{
  context: [resolved assets],
  routing_trace: [decisions made],
  governance: {
    access_granted: true,
    audit_id: "abc-123"
  }
}

With Existing Systems

System	Integration
Git	Asset storage backend
SSO/LDAP	Identity for access control
CI/CD	Automated testing of context changes
Observability	Metrics export (Prometheus, DataDog)
SIEM	Audit log forwarding
Ticketing	Change request linking

With Model Context Protocol (MCP)

Resources:
  context://registry/assets
  context://registry/assets/{id}
  context://registry/domains/{domain}

Tools:
  context_search     # Find assets by criteria
  context_route      # Get routed context for signals
  context_register   # Add new asset
  context_promote    # Move through lifecycle

Prompts:
  context_audit      # Generate governance report
  context_quality    # Assess health metrics

---

Design Principles

1. Context is an Asset

Treat context with the same rigor as code or data:

• Version everything
• Track ownership
• Measure quality
• Govern changes

2. Routing is Declarative

Define what context should load, not how to load it:

• Rules over imperative code
• Composable conditions
• Transparent decisions

3. Governance is Built-In

Security and compliance from day one:

• Access control by default
• Audit everything
• Approve before production

4. Quality is Measurable

If you can't measure it, you can't improve it:

• Track effectiveness
• Alert on degradation
• Continuous optimization

5. Emergence Over Prescription

Support how teams naturally work:

• Start simple, add structure as needed
• Import existing context
• Gradual adoption path

---

Conclusion

Context infrastructure is the missing layer in production AI systems. Organizations that treat context as a managed asset—with proper registry, routing, and governance—will achieve:

• Consistency - Same context for same situations
• Security - Right context for right users
• Compliance - Auditable AI decisions
• Efficiency - Optimized token usage
• Quality - Measurable, improvable context
• Scale - Hundreds of agents, thousands of users

---

Appendix: Glossary

Term	Definition
Context	Any information loaded into an AI agent's prompt to guide behavior
Asset	A discrete, versioned unit of context (skill, prompt, policy, etc.)
Registry	The catalog and metadata store for all context assets
Routing	The logic that selects what context loads for a given situation
Governance	The controls ensuring context is secure, compliant, and effective
Lineage	The graph of relationships between context and outputs
Freshness	How recently context was updated relative to its domain's change rate
Effectiveness	How well context contributes to successful outcomes
Token Budget	The maximum tokens available for context in a given request

---

Thoughts?