Why Continuity-Regulated Intelligence (CRI) Is a Layer 0 Requirement for AGI
Scale solved capability. It did not solve continuity. And continuity is now the dominant failure mode in deployed AI systems.
That sentence may sound overstated until you have operated these systems in real workflows for long enough. Then it starts to feel obvious. A model can be dazzling in one session and quietly incoherent in the next. It can reason through a hard problem on Monday and produce a conflicting recommendation on Thursday with the same confidence. It can follow policy language perfectly in controlled prompts and still drift around those constraints when context, tooling, or task pressure changes.
This is not a minor bug in otherwise complete intelligence. This is an architectural gap.
The question that originally pulled me into this was deceptively simple: what if today’s LLM systems are closer to a bicameral stage of mind than to reflective intelligence? Not conscious in a mystical sense, and not human in a literal sense, but structurally bicameral: highly responsive, externally triggered, fluent, useful, and still weak at maintaining an integrated self across time.
Once you look through that lens, a lot of modern AI confusion clears up. We are not just trying to make answers better. We are trying to make behavior coherent over time. Those are different engineering problems.
For the first problem, scale works exceptionally well. For the second, scale is necessary but insufficient.
Jaynes’s bicameral framing remains controversial as history, but it is valuable as architecture language. It describes a mode of mind that can produce guidance and action without stable introspective continuity. That maps surprisingly well to current LLM deployments. They are extraordinary next-step engines. They are still early at preserving durable identity, durable constraints, and durable method across sessions and environments.
The moment AI systems move from assistance into delegated action, this gap stops being academic. A brittle assistant costs a few minutes. A brittle autonomous chain can leak data, burn budget, or execute the wrong operation before anyone notices the state has drifted. The more agency we give these systems, the more continuity becomes a safety and reliability requirement, not a philosophical preference.
This is exactly where many teams reach for the same fix: add memory. That helps, and it should help. But memory is not persistence. Memory improves recall. Persistence requires continuity under change.
In fact, unmanaged memory can amplify instability. More historical fragments create more retrieval pathways, more latent contradictions, and more opportunities for a system to justify opposite conclusions depending on which slice is retrieved first. Teams often interpret this as a retrieval tuning issue, but retrieval is usually carrying a deeper design failure. The system is storing information faster than it is integrating meaning.
That is why I think persistence should be treated as a cycle, not a feature. The cycle is simple to state and hard to execute: experience, encoding, consolidation, and regulation. A system that cannot run all four with discipline cannot become reliably stateful, no matter how fluent its outputs are in isolated interactions.
Experience is the visible layer where users interact with the system and actions are taken. Encoding turns those interactions into structured traces. Consolidation transforms raw traces into durable knowledge and durable procedure. Regulation keeps the whole process within coherence, safety, and cost boundaries as the system evolves. Skip any stage and you get local intelligence without longitudinal stability.
At this point I started using a concrete name for the architecture because naming matters if we want people to build it, test it, and reference it consistently. I call this Continuity-Regulated Intelligence (CRI). CRI is not a new model family. Continuity-Regulated Intelligence (CRI) is an architectural pattern that couples execution, consolidation, and governance into closed control loops that preserve identity, constraints, and performance across time.
In operational terms, CRI runs as three stacked control loops. The execution loop handles live task behavior under active guardrails. The consolidation loop converts raw traces into durable semantic and procedural state. The governance loop audits both loops, promotes safe improvements, and rolls back drift. Each loop has authority to constrain or modify system behavior based on policy, health, and performance signals.
The easiest way to see why CRI is needed is to look at a familiar failure pattern in coding agents. Imagine an agent that correctly fixes a checkout bug by adding a null-safe guard and a schema validation step. The immediate ticket closes and everyone is happy. A week later, a related ticket appears and the agent proposes a refactor that removes the validation path because it now looks redundant in the narrow context it retrieved. The bug returns under load. What failed was not token generation. What failed was procedural continuity. The system remembered code fragments, but it did not preserve the causal trace of why the fix existed and under which constraints it remained necessary.
The system preserved syntax but not intent.
That distinction points to one of the most important differences in memory design, and it deserves more explicit treatment than it usually gets. Episodic memory tells us what happened. Semantic memory tells us what is believed to be true. Procedural memory tells us how to reliably do something under constraints. Episodic memory without semantic consolidation becomes noisy history. Semantic memory without procedural grounding becomes brittle doctrine. Procedural memory is the bridge between recollection and reliable behavior. If persistence is the goal, procedural continuity is the unlock.
CRI therefore treats memory as typed infrastructure, not one large bucket. Episodic traces preserve chronology and provenance. Semantic structures preserve distilled beliefs with confidence and evidence lineage. Procedural traces preserve validated methods, including decision points, tools used, failure modes, and post-conditions. That third lane is where repeatable reliability actually comes from.
But memory alone is still not enough. A persistent system needs a nervous system with different control speeds.
At reflex speed, the system needs immediate enforcement for non-negotiable boundaries. Permission checks, forbidden action gates, budget circuit breakers, and high-risk veto paths must trigger before full deliberative reasoning completes. If a safety decision only happens after tool execution begins, the control surface is too slow.
At deliberative speed, the system needs planning, synthesis, and adaptation for novel tasks. This layer should remain powerful and flexible, but it should not be sovereign. It has to reason inside active policy boundaries, current risk posture, and current system health constraints.
At deep consolidation speed, the system needs replay, reconciliation, pruning, promotion, and recalibration. This is where contradiction density can be reduced, stale routines can be demoted, and validated procedural traces can be promoted into preferred paths. Without this layer, growth mostly means accumulation. With it, growth can mean maturation.
At the center of all three speeds sits the self-model, and this is where many otherwise strong architectures quietly collapse into roleplay. A self-model cannot just be tone guidance or persona text. It has to function as an executable contract. It should be explicit, versioned, queryable, and auditable. It should define scope, capabilities, uncertainty posture, forbidden transitions, budget boundaries, and change authority. If the self-model says `payments.send` requires human approval, runtime must hard-block that tool call and route it to approval even when the model is confident and the user asks directly. If the system can describe its values but cannot be constrained by them at runtime, it does not have a meaningful self-model.
Now comes the part people resist because it sounds expensive: the sleep tax. Persistent intelligence has a maintenance bill. Biological systems pay it through restoration and consolidation cycles. AI systems pay it through replay, conflict resolution, memory compaction, calibration refresh, policy hardening, and controlled promotion workflows. Call it background jobs if you prefer. The economics do not change.
In practice, that cost is manageable only when consolidation is selective and tiered: most traces should never be promoted, and most maintenance should run on compact summaries rather than full replays. Procedural traces should be versioned with explicit applicability constraints so environment drift can trigger rapid demotion and fallback to deliberative planning. Governance should run asynchronously by default, entering the critical path only for high-risk actions or when health signals cross thresholds.
Most organizations optimize for foreground utility and underfund background consolidation. That works until continuity debt comes due. Then the cost appears as regression clusters, policy drift, rising oversight burden, and user trust erosion. These are often treated as isolated incidents. In reality, they are usually deferred consolidation costs.
This is why CRI includes a separate supervisory layer by design. A meta-learner and governor should sit above day-to-day execution. Its job is to monitor health signals, propose changes, test those changes in canary conditions, promote safe gains, rollback regressions, and preserve a complete change journal. It should be conservative where task execution is exploratory. It should protect continuity while execution maximizes utility.
Separating execution from governance is not optional if reliability is the objective. Distributed systems, databases, and operating systems learned this long ago. AI systems are now learning it under higher uncertainty and higher stakes.
At this point it is important to state novelty carefully. Individual ingredients already exist in literature and industry. Memory systems exist. Agent loops exist. Policy engines exist. Self-improvement loops exist. The claim is not that no one has explored these components. The claim is that we still rarely deploy them as one continuity-first architecture with auditable self-modeling, typed memory, homeostatic regulation, and governed promotion as co-equal infrastructure from day one.
That integration gap is where most of today’s “smart but unstable” behavior is born.
It also explains why current AI discourse can feel contradictory. Capability is clearly accelerating, yet production teams still spend enormous time on behavior drift, inconsistency, policy edges, and reliability decay. We have become excellent at local intelligence and inconsistent at longitudinal intelligence.
If we want to know whether this is improving, we should measure it directly. One metric I find especially useful is Procedural Reuse Reliability, or PRR. PRR asks a simple question: when a known task class reappears, how often does the system solve it by reusing a previously validated procedural trace without causing policy violations, regressions, or manual rollback? Operationally, PRR is measured per task family as successful validated reuse runs divided by eligible repeat runs in a fixed window, where success requires no policy breach, no rollback, and no manual hotfix. PRR should be tracked longitudinally; rising PRR across consolidation cycles indicates procedural maturation rather than episodic success. High PRR means the system is converting experience into durable method. Low PRR means it is still improvising from scratch while pretending to learn.
That metric is not flashy, but it is honest. It captures whether a system is building continuity or just accumulating artifacts.
The Orchestration Fallacy
At this point it is tempting to treat CRI as an application-layer orchestration recipe. It is not. You cannot build AGI-grade continuity by bolting a vector store and workflow graph onto a stateless endpoint and calling that persistence. That is the orchestration fallacy.
Current orchestration stacks are useful for prototyping behavior, but they still treat memory as an external cabinet and governance as a wrapper script. If the control path is retrieve, inject, generate, post-check, and re-prompt, reflex-speed regulation is already too late, and appending text to a prompt is still not consolidation. It forces an amnesiac system to reread its own diary each turn. For frontier systems, execution, consolidation, and governance need native control surfaces inside the intelligence stack itself. If the control surface remains external, capability growth will eventually outrun control.
The broader point is straightforward. Scale remains essential. Better base models matter. But scale is an amplifier, not a substitute for architecture. If the surrounding architecture is discontinuous, scale amplifies discontinuity. If the surrounding architecture is continuity-regulated, scale amplifies durable intelligence.
The AI most people are actually hoping for is not just a model that can answer almost anything. It is a system that can act, adapt, and improve without losing identity, constraints, and trust in the process. That system will not emerge from parameter count alone.
It will emerge when we stop treating persistence as a feature request and start treating continuity as the primary design objective.
That is the threshold between bicameral AI and persistent AI.
Crossing it is not about abandoning scale. It is about finally completing it. Continuity regulation is the architectural control layer required to make advanced AI capability dependable at scale.
References and Sources
Jaynes, Julian. The Origin of Consciousness in the Breakdown of the Bicameral Mind. Houghton Mifflin. 1976.
Tulving, Endel. Episodic and Semantic Memory. In Organization of Memory. Academic Press. 1972.
Squire, Larry R. Memory Systems of the Brain: A Brief History and Current Perspective. Neurobiology of Learning and Memory. 2004.
Anderson, John R., et al. An Integrated Theory of the Mind. Psychological Review. 2004.
Mnih, Volodymyr, et al. Human-Level Control Through Deep Reinforcement Learning. Nature. 2015.
Park, Joon Sung, et al. Generative Agents: Interactive Simulacra of Human Behavior. ACM CHI Conference on Human Factors in Computing Systems. 2023.
Yao, Shunyu, et al. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv. 2022.
Schick, Timo, et al. Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv. 2023.
Shinn, Noah, et al. Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv. 2023.
Karpas, Erez, et al. MRKL Systems: A Modular, Neuro-Symbolic Architecture That Combines Large Language Models, External Knowledge Sources and Discrete Reasoning. arXiv. 2022.
OpenAI. Preparedness Framework. OpenAI. 2023.
Anthropic. Responsible Scaling Policy. Anthropic. 2023.
