Sovereign Context & Safe Mutation Architecture for Coding Agents: Decoupling Tool Density, Stratified Decay, and Transactional State

1. The Three Tiers of Enterprise Agent Systems

In 2026, the term "Enterprise MCP Hub" is frequently misapplied to describe three entirely different architectural concerns. Enterprise architects must separate them cleanly:

Tier 1 (The Access Gateway): Governs privileged tool access and authentication. It exchanges developer OIDC identity tokens for short-lived downstream credentials, enforces Data Loss Prevention (DLP), and logs audit traces. Krusch does not attempt to reinvent this enterprise gateway layer; it integrates cleanly downstream of existing enterprise proxies (Kong, Envoy, Cloudflare, Obot).

Tier 2 (The Sovereign Context Plane — krusch-context-mcp): Solves context density and working-memory durability. It ensures coding agents do not suffer from amnesia across multi-day tasks, while strictly pruning tool catalog and prompt bloat down to an ~890-token footprint.

Tier 3A (The Execution Harness — krusch): Solves safe codebase mutation. It stages proposed code edits in PostgreSQL, validates them inside unprivileged sandboxes with network isolation and scrubbed credentials, and writes to physical disk only upon passing verification and receiving operator approval.

Tier 3B (Systems of Record Integration): Provides read-only schema reflection and client-side pre-flight steering. Krusch provides the context agents need to write correct enterprise integration code; direct agent writes to live ERP/CRM databases are strictly forbidden and must execute through governed corporate CI/CD pipelines.

2. Attention Bloat vs. Agent Amnesia

Frontier foundation models are stateless probabilistic samplers. In complex enterprise engineering environments, this creates two symmetrical failure modes:

• Agent Amnesia: When an IDE session ends or a CI/CD job terminates, all accumulated in-flight context—architectural decisions, edge cases, active sprint conventions, and dependency graphs—is wiped clean. Developers are forced to repetitively re-explain domain architecture at the start of each task.
• Context Window Bloat & Tool Selection Entropy: The naive countermeasure—stuffing 50+ tool schemas, raw database DDL, and unpruned documentation into system prompts—degrades reasoning. Exposing dozens of overlapping tool definitions induces parameter hallucination, triggers the "Lost in the Middle" attention penalty, and burns 14,000+ tokens on every single turn.

3. Product Family: Context Broker vs. Apply Harness

A common source of confusion in agentic architectures is conflating memory retrieval with code execution. In the Krusch sovereign architecture, these are two decoupled, specialized open-source systems:

The sequence diagram below illustrates how the two components compose cleanly without conflating memory with execution authority:

3.1 Sandbox Isolation Matrix & Platform Portability

Safe verification requires running test runners inside an unprivileged jail that prevents both system tampering and data exfiltration:

4. Pillar I: 2026 Streamable HTTP & Profile Projection

By 2026, enterprise MCP deployments have standardized on Streamable HTTP (chunked JSON-RPC over HTTP/2 and HTTP/3) alongside local Stdio IPC:

Dynamic Tool Profile Projection (Core 13 vs Extended)

To eliminate tool selection entropy, krusch-context-mcp projects **curated profiles** (configured via KRUSCH_PROFILE):

• Core Profile (Default — 13 Tools, ~890 Prompt Tokens): High-signal daily drivers: compound retrieval (krusch_context_retrieve), episodic memory with active superseding, state compilation (krusch_context_compile_state), steering nuggets, structural symbol search, 2-hop graph walks, and proactive guardrails.
• Extended Profile (26 Tools, ~1,800 Prompt Tokens): Administrative memory inspection, Git tree/blob inspection, and alignment feedback.
• Modular Companion Extensions (On-Demand): Specialized domain connectors run as decoupled companion processes or load dynamically via --extensions=... only during tasks requiring them.

5. Pillar II: Stratified Temporal Recency ($\lambda$-Matrix)

Standard vector search is temporally blind: an obsolete 2-year-old API guide can easily outrank an active commit if their semantic embeddings share a high cosine similarity. However, applying a single global exponential decay to all data is equally disastrous: authoritative business invariants (e.g., "GL accounts must be 10 digits") must never decay.

The Stratified $\lambda$-Decay Formulation

The system replaces monolithic decay with a **Domain-Stratified Temporal Prior**:

5.2 Invariant Promotion & Lifecycle Governance

A critical failure mode in self-updating agent memory is poisoning Class 0: if an agent can autonomously register a rule with $\lambda = 0.000$, a hallucinated requirement or temporary debugging workaround becomes an immortal constraint that distorts future sessions.

To prevent invariant pollution, the architecture enforces Tiered Memory Promotion:

By decoupling agent observation (Class 2/3) from architectural authority (Class 0), the system prevents local folklore from achieving immortality without human verification.

6. Pillar III: Declarative Steering & Workspace Cache

System prompts fail to enforce engineering standards over long planning horizons due to instruction drift. The architecture replaces prompt stuffing with Declarative Steering Nuggets: atomic micro-invariants dynamically injected into the immediate prompt context only when relevant to the active subtask.

Workspace Compute Cache Pattern (Local SQLite)

To ensure agents experience zero network latency on tool turns:

1. Local Workspace Cache (.agent/memory.db): An embedded SQLite database inside the repository checkout. Reads from nugget_nudges execute locally in < 2 milliseconds, returning ~150 tokens of top-3 matched constraints.
2. Asynchronous Write-Behind: When an agent registers a new invariant via nugget_remember, it commits locally immediately, and an asynchronous worker synchronizes the record and vector embedding to central PostgreSQL.

Pre-Flight Trajectory Auditing (proactive_nudge)

Before code diffs are staged, the background Proactive Auditor evaluates planned modifications against active Class 0 invariants:

[TRAJECTORY GUARDRAIL INTERCEPT]
Violation of Invariant 'sap-gl-account-pad':
Found unpadded GL string `account_id.toString()` in src/sap/invoice.ts:42.
Required: `account_id.toString().padStart(10, '0')`.
Staged diff rejected. Auto-correction queued for sandbox verification.

7. Pillar IV: Sovereign PostgreSQL 16 + pgvector

Enterprise data sovereignty demands that corporate code, symbols, and working memory never leave the client's tenancy perimeter. The architecture standardizes on PostgreSQL 16 with pgvector and full-text GIN indexing.

Reciprocal Rank Fusion (RRF) Hybrid Search

Exact code symbols require lexical exact-match indexing, while natural language queries require semantic vector embeddings. The Hub merges dense HNSW vector search with sparse tsvector keyword search using SQL-native Reciprocal Rank Fusion ($k=60$):

-- Production PostgreSQL 16 Hybrid Retrieval (RRF)
WITH dense_matches AS (
    SELECT id, RANK() OVER (ORDER BY embedding <=> $1::vector) AS r_dense
    FROM code_symbols
    WHERE repository_id = $2
    LIMIT 30
),
sparse_matches AS (
    SELECT id, RANK() OVER (ORDER BY ts_rank_cd(tsv, plainto_tsquery('simple', $3)) DESC) AS r_sparse
    FROM code_symbols
    WHERE repository_id = $2 AND tsv @@ plainto_tsquery('simple', $3)
    LIMIT 30
)
SELECT 
    cs.id, cs.symbol_name, cs.file_path, cs.signature,
    COALESCE(1.0 / (60 + dm.r_dense), 0.0) + 
    COALESCE(1.0 / (60 + sm.r_sparse), 0.0) AS rrf_score
FROM dense_matches dm
FULL OUTER JOIN sparse_matches sm ON dm.id = sm.id
JOIN code_symbols cs ON cs.id = COALESCE(dm.id, sm.id)
ORDER BY rrf_score DESC
LIMIT $4;

In frozen in-corpus benchmark evaluations, hybrid RRF achieved 0.964 Mean Reciprocal Rank (MRR), outperforming dense-only cosine search (0.881 MRR) by eliminating false positives on similarly named structural functions.

8. Privileged Systems-of-Record (SoR) Threat Model

Enterprise architects must maintain a strict security boundary between code generation and privileged enterprise data mutations:

Krusch is not an Enterprise Service Bus (ESB) executing direct unmediated writes to ERP general ledgers. It is the context and execution plane for software engineering agents that build, refactor, and maintain those enterprise integrations. The agent reads schema DDL and invariants from Krusch to write correct integration code; production data mutations remain guarded by corporate change-control gateways.

9. Empirical Measurements & Micro-Benchmarks

To evaluate retrieval performance with engineering rigor rather than marketing theater, the hybrid retrieval engine was evaluated using frozen query fixtures across both in-corpus and public foreign codebases. With sample sizes of $n=14$ and $n=10$, these measurements are directional IR micro-benchmarks designed to isolate the mechanics of hybrid reciprocal rank fusion on structural code symbols. Reproducible test scripts (npm run eval:accuracy and npm run eval:foreign) and fixtures are versioned under evals/fixtures/.

Benchmark 1: In-Corpus Architecture Ablation ($N=14$ Queries)

Evaluated on the Sovereign Core repository stack (190 content-addressed blobs, 14 benchmark queries: 6 exact code identifiers + 8 semantic architectural concepts):

Benchmark 2: Foreign Public Codebase Benchmark: expressjs/express ($N=10$ Queries)

Evaluated on expressjs/express (206 files, 167 indexed blobs, 3,354 symbols, 10 benchmark queries: 5 exact code identifiers + 5 semantic concepts):

Latency & Token Footprint Profile

Standardized Evaluation Protocol Specification

To measure autonomous agent reliability across complex engineering tasks without marketing theater, the platform defines a formalized three-part testing protocol:

1. Tool Parameter Confusion Suite: Measures error rates in tool invocation as the active catalog scales from 13 to 26 tools.
2. Invariant Ingestion Benchmark: Measures whether Class 0 invariants (e.g., zero-padded GL accounts) successfully override conflicting model priors during code synthesis.
3. Sandbox Recovery Suite: Measures the percentage of failed verification runs in isolated containers that converge to passing code within a capped revisit budget.

10. Production Deployment Topologies

The platform supports two deployment topologies depending on organizational compliance requirements:

Topology A: 100% Air-Gapped / Sovereign Stack

For defense, healthcare, and financial environments where zero network egress is permitted:

• Database: PostgreSQL 16 + pgvector containerized on private infrastructure.
• Embeddings: Local Ollama container serving bge-large-en-v1.5 over an internal Docker network.
• Transport: Stdio for local workstations; internal mTLS Streamable HTTP for CI/CD workers.

Topology B: Elastic Hybrid Cloud Stack

For distributed engineering teams seeking zero local GPU maintenance:

• Database: Managed PostgreSQL (e.g. AWS RDS Aurora with pgvector or Polygres Cloud).
• Embeddings: Enterprise-peered endpoints (OpenRouter, AWS Bedrock, or GCP Vertex AI).
• Transport: Authenticated Streamable HTTP via enterprise reverse proxy / API gateway.