Proposal: claude-eng — Persistent Cognitive Memory & Behavioral Governance for Autonomous Software Engineering

Summary

This proposal outlines a plan to integrate MDEMG (Multi-Dimensional Emergent Memory Graph) into the Claude ecosystem as a new service called claude-eng — a deterministic, stateful behavioral governance layer purpose-built for fully automated software engineering workflows. It also proposes Anthropic fund LLM interaction training for a local model optimized for MDEMG's cognitive memory and retrieval pipeline.

---

The Problem: Stateless Sessions at Production Scale

Claude Code is extraordinarily capable within a single session. But production software engineering requires continuity across sessions — and that is where the current architecture breaks down.

Documented failure modes (see also #14227, #29990):

| Failure | Root Cause | Impact |
|---------|-----------|--------|
| Session A reintroduces bugs Session B fixed weeks prior | No cross-session learning | 50+ git reverts over months of production use |
| Identical corrections re-issued across sessions | Corrections don't persist structurally | Developer fatigue, lost trust |
| Governance degrades with context length | MEMORY.md is flat text, keyword-matched, 200-line cap | Rules disappear mid-session under compaction |
| Parallel sessions contradict each other | No shared state between agents | Conflicting changes, merge thrash |
| 0.8% test coverage in a 171K-line AI-built system | "Governance doesn't write tests" | Silent regression, production incidents |

The community has responded with workarounds — memory-ts, claude-graph-memory, memsearch, custom hooks — but these are fragmented, incomplete, and unsupported. Meanwhile, Anthropic's own leaked roadmap features (KAIROS, autoDream) remain feature-flagged off, and Conway is in limited testing.

The gap is clear: Claude Code needs a persistent cognitive substrate — not just a bigger context window or better memory.md, but a learning system that accumulates institutional knowledge, enforces behavioral governance, and improves with use.

---

The Proposal: claude-eng

claude-eng is a new service in the Claude ecosystem that provides the deterministic, stateful behavior layer necessary for consistent, fully automated software engineering. It is built on MDEMG — a production-ready cognitive memory system with 105 completed development phases, 2,381+ tests, and demonstrated +58.4% retrieval quality improvement on a 507K LOC TypeScript codebase.

Architecture

┌─────────────────────────────────────────────────┐
│                  Claude Code CLI                 │
│            (Existing — no changes)               │
├─────────────────────────────────────────────────┤
│              claude-eng Service                  │
│  ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│  │ Cognitive │ │ Jiminy   │ │ RSIC Self-       │ │
│  │ Memory   │ │ Guidance │ │ Improvement      │ │
│  │ System   │ │ Engine   │ │ Engine           │ │
│  └──────────┘ └──────────┘ └──────────────────┘ │
│  ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│  │ UxTS     │ │ Signal   │ │ Training Data    │ │
│  │ Govern.  │ │ Learner  │ │ Pipeline         │ │
│  └──────────┘ └──────────┘ └──────────────────┘ │
├─────────────────────────────────────────────────┤
│  Neo4j (Graph)  │  TimescaleDB  │  Neural Sidecar│
└─────────────────────────────────────────────────┘

What claude-eng Provides

1. Persistent Cognitive Memory (CMS)

A 5-layer emergent memory hierarchy (observations → hidden aggregators → domain concepts → abstract concepts → emergent concepts) built on Neo4j with native vector indexes. Unlike flat-file memory:

• Surprise-weighted persistence — novel information persists longer than redundant
• Hebbian learning — frequently co-activated concepts strengthen automatically (10 neural-inspired optimizations: tanh soft-capping, squared activation, multi-rate learning, time-based LR schedule, cautious decay, local-first spreading, value residual bypass, L0 skip connections, negative result tracking, frontier detection)
• Context compaction survival — 95% decision persistence at 5+ compactions vs. 0% baseline
• Graph-native retrieval — BM25 + vector similarity + RRF fusion + graph traversal + activation spreading + LLM re-ranking
• Multi-agent coordination — space isolation, agent identity, private/team/global visibility

2. Proactive Behavioral Guidance (Jiminy)

A conscience-like system injected before every agent action via hooks. Jiminy doesn't wait to be asked — it speaks before the agent acts:

• 5 parallel knowledge sources (constraints, correction vectors, contradiction edges, frontier detection, trust-scored history) with 6-second timeout
• 11 guidance types with follow-up feedback loops (followed → partial → ignored → contradicted)
• 6-level escalation system for ignored constraints
• J17 AI-to-AI communication protocol with 3-tier encoding (coded/telegraphic/full NL), up to 5.2x token compression, ML-powered tier prediction
• Session tickets persist trust and escalation state across context compaction

3. Recursive Self-Improvement (RSIC)

A 5-stage autonomous feedback loop (Assess → Reflect → Plan → Execute → Validate) operating at 3 temporal scales:

• Micro (minutes): Per-session health pulse
• Meso (hours): Full assessment + remediation
• Macro (daily): Topology optimization + hidden layer re-consolidation

Safety mechanisms: dry-run mode, rollback snapshots, blast-radius estimation, protected spaces, max 5% nodes / 10% edges pruned per cycle.

4. Signal Learner

Tracks the effectiveness of meta-cognitive signals using Hebbian learning. Signals that agents consistently respond to grow stronger and are prioritized. Signals consistently ignored weaken. The system learns which guidance actually works for each team and project.

---

UxTS: Behavioral Governance Through Declarative Contracts

UxTS (Universal-x Test Specification) is a framework for organizing programmatic verification into domain-specific specifications sharing a common four-layer architecture: Schema → Specs → Runner → CI Gate.

UxTS solves three problems that plague AI-generated code:

| Problem | Description | UxTS Solution |
|---------|-------------|---------------|
| Silent Drift | AI modifies behavior without visible contract changes | Hash-backed change detection catches unreviewed modifications immediately |
| False Confidence (0/0 problem) | Tests that assert nothing pass vacuously | A spec with zero executable assertions MUST fail, not pass |
| Reinvention Tax | Every project builds ad-hoc verification from scratch | 12 reusable frameworks with shared architecture |

The 12 UxTS Frameworks

| Framework | Domain | Example |
|-----------|--------|---------|
| UATS | API contracts | 129+ specs validating HTTP endpoints |
| UPTS | Parser conformance | 27 language parsers with SHA256 fixture verification |
| UBTS | Benchmarks | Latency thresholds, throughput gates |
| USTS | Security | OWASP Top 10 mapped security tests |
| UOBS | Observability | Metrics, health, tracing, alerting validation |
| ULTS | LLM task quality | 16 LLM task quality specifications |
| UTDS | Training data | Export/import schema validation |
| UNTS | Hash verification | File integrity tracking |
| UOTS | Observability topology | Grafana dashboard governance |
| UETS | Emergence quality | LLM concept naming evaluation |
| UICS | Comprehension encoding | Iterative improvement encoding |
| UGTS | gRPC contracts | Space transfer protocol validation |

How UxTS constrains AI behavior: Specs are declarative JSON — machine-readable, diffable, schema-governed. An AI agent can:

1. Discover existing specs before modifying code
2. Validate changes against specs before committing
3. Generate new specs for new functionality
4. Fail deterministically when contracts are violated

This transforms "trust but verify" into "verify then trust." The CI gate ensures no spec-violating code reaches production, regardless of which agent (or human) wrote it.

---

Proposal: Anthropic-Funded Local Model Training

What MDEMG Already Achieves With Minimal Compute

MDEMG currently runs all 16 of its LLM task types through gpt-4.1-nano — the smallest available OpenAI model — on a single developer workstation. With this minimal compute baseline:

• +58.4% retrieval quality improvement on a 507K LOC codebase (0.567 → 0.898)
• 95% decision persistence across 5+ context compactions (vs. 0% baseline)
• 105 development phases completed — the system built and governed itself through its own memory
• 50+ git reverts eliminated — corrections persist structurally, not as flat text

These results come from architecture, not brute-force model capability. But every one of MDEMG's 16 LLM tasks is currently constrained by using a general-purpose nano model that was never optimized for cognitive memory operations. The ceiling is visible.

Why a Small, Dedicated Model Changes Everything

MDEMG's LLM tasks are narrow, structured, and short-context by design:

| Task Category | Count | Typical Input | Max Output | Nature |
|---------------|-------|---------------|------------|--------|
| Classification (query type, constraint type, outcome) | 4 | 100–500 tokens | 100–500 tokens | Few-shot structured JSON |
| Naming/Labeling (concepts, constraints, codes) | 3 | 200–800 tokens | 100–300 tokens | Short generative + JSON |
| Re-ranking/Scoring | 2 | 500–2,000 tokens | 500–2,000 tokens | Comparative scoring |
| Synthesis (guidance, consulting, summaries) | 5 | 1,000–5,000 tokens | 500–2,000 tokens | Constrained narrative |
| Reflection/Evaluation | 2 | 1,000–3,000 tokens | 500–2,000 tokens | Analytical JSON |

None of these tasks require a frontier model. None require a large context window. An 8B parameter model with a 2–3K context window, fine-tuned specifically on MDEMG's interaction patterns, would be sufficient for every task — and would deliver three transformative advantages:

1. Zero-latency cognitive operations. Local inference eliminates network round-trips. Jiminy guidance generation drops from seconds to milliseconds. RSIC self-assessment runs continuously instead of on cooldown timers. The system thinks at the speed of thought, not the speed of API calls.

1. True behavioral governance. A model trained specifically on MDEMG's constraint detection, outcome classification, and guidance synthesis tasks would produce calibrated, reliable structured output — not best-effort approximations from a general-purpose model. When Jiminy says "this violates constraint X," that judgment would come from a model that has seen thousands of real constraint violations, not one guessing from a system prompt.

1. Cost elimination for cognitive operations. Every query to MDEMG currently generates 3–8 LLM API calls (classify → translate → retrieve → rerank → synthesize → evaluate). At scale across a development team, these cognitive operations dominate cost. A local model reduces this to zero marginal cost, making persistent memory economically viable for every developer, not just those with API budgets.

The Compounding Effect on Emergent Concepts and Relationships

This is where a dedicated model's impact becomes exponential rather than linear. MDEMG's Neo4j knowledge graph is a living structure where LLM quality at any point in the pipeline amplifies through every subsequent cycle:

The Reinforcement Loop:

Better LLM → Better retrieval ranking → Right nodes co-activate
    → Stronger CO_ACTIVATED_WITH edges (Hebbian learning)
    → Higher-quality DBSCAN clusters at consolidation
    → Better concept nodes (L1→L5) with precise LLM-generated names
    → Better message passing (GraphSAGE forward/backward)
    → Better retrieval for the next query → cycle repeats

A general-purpose nano model produces vague concept names like "Code Pattern" where a tuned model would produce "Event-Driven Saga Orchestration." That name becomes the concept node's summary field — which is embedded, indexed, and used for vector similarity search in every future query. One imprecise name degrades retrieval for every query that should have matched that concept. Multiply this across hundreds of concept nodes and the compounding quality loss is substantial.

Specific emergence mechanisms affected:

• Concept naming quality (L1–L5): The LLM generates the name, description, and proposed_label (pattern/principle/bridge/concern/workflow) for every emergent concept. The label controls how the concept is weighted in retrieval and guidance. A miscategorized "principle" that should be a "workflow" gets surfaced in the wrong contexts indefinitely.

• Dynamic reclassification: When a file-type category dominates >25% of nodes, the LLM proposes semantic sub-categories with keywords. Poor keyword proposals cause misclassification that propagates upward through every layer. A model trained on MDEMG's actual taxonomy would produce precise, consistent sub-categories.

• CO_ACTIVATED_WITH edge formation: These Hebbian edges form from retrieval co-occurrence. Better retrieval (from better re-ranking and intent translation) means the right nodes co-activate, forming edges that reflect genuine semantic relationships rather than retrieval noise. Over hundreds of queries, this is the difference between a graph that captures real architectural patterns and one polluted with spurious associations.

• L5 meta-concept emergence: The highest layer synthesizes the "underlying principle that connects" L3+ concepts via ANALOGOUS_TO and BRIDGES edges. This is the most LLM-sensitive operation — it requires genuine understanding of why disparate concepts relate. A tuned model would surface organizational design principles ("all async boundaries use the same retry-with-backoff pattern") that a general model misses entirely.

• Training data contamination: MDEMG collects re-ranking scores as training data for its neural sidecar. Miscalibrated LLM scores contaminate this dataset. A well-calibrated local model produces clean training signal that improves the entire ML pipeline.

The bottom line: Every concept node, every edge weight, every layer of abstraction in the graph is shaped by LLM output quality. A general-purpose model produces a functional graph. A dedicated model produces a graph where emergent concepts genuinely reflect the codebase's architectural reality — and that graph compounds in value with every interaction, every session, every developer who touches the codebase.

What We're Proposing

1. Anthropic funds compute for training an 8B local model optimized for MDEMG's 16 cognitive task types. The training infrastructure already exists — quality filtering (8 gates), RAFT 80/20 context handling, temporal train/test splits, ULTS per-task evaluation, regression gating, and 21 GRPO reward functions for teacher distillation.

1. The training data already exists. MDEMG records every LLM interaction to TimescaleDB with full context (prompt, response, retrieval context, task type, latency, quality scores). Quality filtering removes PII, duplicates, errors, and stale data.

1. The evaluation infrastructure already exists. ULTS provides 16 task-specific quality specifications. The regression gate prevents deployment of models that regress on any task.

1. Benefits to Anthropic:

• Reduces API call volume for cognitive operations (cost savings for users)
• Provides a reference implementation for Claude Code's persistent memory needs
• Generates training data and evaluation methodology applicable to KAIROS/autoDream
• Demonstrates Claude ecosystem extensibility through a production-grade integration
• Addresses the #1 user-requested feature (#14227) with a working solution
• Validates a hybrid architecture: local model for cognition, Claude API for generation

---

Integration Plan: MDEMG → claude-eng

Phase 1: Sidecar Integration (Already Functional)

MDEMG already operates as a sidecar to Claude Code via:

• MCP server registration (.claude/mcp.json)
• Hook-based lifecycle integration (5 hooks: session-start, prompt-context, pre-bash-check, post-tool-observe, pre-compact)
• One-command setup: mdemg sidecar quickstart

This requires zero changes to Claude Code.

Phase 2: First-Party Service

Elevate from third-party sidecar to official claude-eng service:

• Ship as a Claude Code plugin or built-in service
• Native memory API replacing MEMORY.md flat-file approach
• Jiminy guidance integrated into the prompt pipeline (replacing hook-based injection)
• RSIC health metrics surfaced in Claude Code's status/diagnostics
• UxTS specs discoverable via tool search

Phase 3: Shared Cognitive Layer

• Multi-project memory with space isolation
• Team-level knowledge sharing (private → team → global visibility)
• Cross-interface continuity (Claude Code ↔ Claude Desktop ↔ Cowork ↔ Conway)
• Managed cloud option for teams that don't want to self-host

Phase 4: Local Model Deployment

• Anthropic-trained local model for cognitive operations
• Hybrid routing: local model for memory/guidance, Claude API for generation
• Offline-capable development with graceful degradation
• Federated learning from anonymized interaction patterns (opt-in)

---

Evidence: Production Results

| Metric | Baseline (Claude Code alone) | With MDEMG |
|--------|------------------------------|------------|
| Domain-specific retrieval (120Q benchmark, 507K LOC) | 0.567 | 0.898 (+58.4%) |
| Decision persistence at 5 context compactions | ~0% | 95% |
| Development phases completed | N/A | 105 core + 16 sidecar |
| Test coverage | 2,381+ tests | 12 UxTS frameworks |
| Observation types tracked | 0 | 13 types, surprise-weighted |
| Cross-session correction persistence | None | Hebbian-strengthened, escalation-backed |

---

Why This Matters for Anthropic's Vision

Anthropic's published research on agent autonomy identifies five escalating levels: operator → collaborator → consultant → approver → observer. Moving up this ladder requires the agent to be trustworthy — and trust requires:

1. Memory — the agent must not repeat past mistakes
2. Governance — behavior must be bounded by verifiable contracts
3. Self-improvement — the system must get better with use, not just bigger
4. Transparency — decisions must be auditable and explainable

MDEMG provides all four. It is the missing infrastructure layer between Claude's raw intelligence and the deterministic, stateful behavior required for enterprise-grade autonomous software engineering.

The enterprise market is asking for this. Spotify ships 650+ AI-generated code changes per month but needs governance. Staff engineers report "the first attempt will be 95% garbage" because there's no institutional memory. Issue #29990 documents 50+ git reverts in production. These are not model capability problems — they are statefulness and governance problems.

claude-eng transforms Claude Code from a brilliant amnesiac into a learning colleague.

---

Next Steps

1. Technical review of MDEMG architecture and codebase (github.com/reh3376/mdemg)
2. Discussion on integration approach (sidecar vs. native vs. hybrid)
3. Pilot program for local model training with MDEMG's existing training pipeline
4. Metrics agreement on what "success" looks like for claude-eng

I welcome feedback from the Anthropic team and the community. Happy to provide demos, architecture walkthroughs, or access to the benchmark suite.

---

This proposal is based on public Anthropic documentation, published research, Claude Code's open-source repository, and production experience operating MDEMG across 105+ development phases.