Bifrost: Cross-Session Governance
Governance that survives the session boundary
The blank-slate problem
Session 47 should not start from scratch. But it does.
Every widely used AI coding agent today begins each session with, at best, a static instruction file and a scratchpad of remembered preferences. The architecture decisions you explained on Monday, the naming conventions you established on Tuesday, the two hours you spent walking through a subtle bug on Wednesday — some of that survives as notes, if the tooling is good. What does not survive is the governance state: how reliably the agent has been converging, how many times it has already tried the approach it is about to try again, which escalations fired and why. The model does not forget these things in any meaningful cognitive sense. It was never given them in the first place. Each session is a fresh process with no access to the oversight record of the one before it.
In practice, the workaround is re-briefing. You paste in context. You summarise what happened. You remind the system what it should already know. This works, roughly, until it does not — until the context grows large enough that the re-briefing itself becomes a governance overhead competing for the same finite window the system needs to reason. At that point, the solution to the memory problem has become a new instance of the Governance Paradox.
This is not a minor UX complaint. McKinsey’s 2026 survey of roughly 500 organisations found that security and risk — agents taking unintended actions or operating beyond their guardrails — is now the top barrier to scaling agentic AI, ahead of regulatory uncertainty. An agent that cannot carry its own governance state across sessions is a small instance of that larger problem: its oversight resets to zero every time it starts. The agentic era demands agents that can carry their own oversight record, and virtually none of them do.
What gets lost
The losses are not uniform. Some things matter more than others when a session boundary intervenes.
Trust state. If a system has been converging reliably for twenty sessions, that track record is operationally meaningful. It should inform how much oversight the next session applies. Instead, the new session starts with no behavioural history and defaults to whatever the base governance posture happens to be. Trust Elasticity, described in Article III, depends on iteration history. Without cross-session persistence, that history resets to zero every time.
Iteration context. The Foundation Check — the N=3 halt rule — works within a session because the system can count how many times the same approach has been tried. Across sessions, the counter vanishes. An agent that failed twice in the previous session can try the same approach again in the next one, because nobody told it about the first two attempts. The loop detection mechanism has a built-in blind spot at every session boundary.
Governance decisions. When the system halts, pivots, or escalates, those events carry information about what does and does not work for a given project. They are expensive to reproduce. If the escalation log disappears between sessions, the system will re-encounter the same failure modes as if they were novel — and the operator will re-explain the same constraints as if they had never been stated.
Progress state. What was done, what remains, and what was explicitly deferred. Without this, the agent either asks again (wasting time) or assumes (creating drift). Neither is a good outcome when the work has any complexity.
The common factor is that none of these are things the model can recover by reasoning harder. They are external facts about the history of the collaboration. If the facts are not provided, the model does not have them, regardless of how capable it is.
The research landscape
The field knows this is a problem. Several systems have tried to solve it, with varying degrees of ambition.
MemGPT (Packer et al., 2023) demonstrated that you can layer a persistent memory system onto a language model by treating memory management as a function-calling problem. The model decides what to store, what to retrieve, and when to page information in and out. The approach works. It also introduces a new failure mode: the model now has to manage its own memory correctly in addition to doing its actual job, and those management decisions consume reasoning capacity.
Mem0 (Chhikara et al., 2025) refined the idea into a production-oriented memory layer for AI agents, with structured retrieval and scalable storage. The architecture is cleaner, but the fundamental tradeoff remains: memory management overhead competes with task performance.
Cognitive Workspace (An, 2025) took a different angle — active memory management with hierarchical cognitive buffers and task-driven context optimisation. The system tries to keep the most relevant information warm while archiving the rest. LongMemEval (Wu et al., 2024) benchmarked these approaches and found that cross-session memory in chat assistants degrades roughly 30% in accuracy on sustained multi-session interactions. The gap between “technically possible” and “operationally reliable” remains large.
The pattern across all of these is instructive. Each system tries to make the model remember. Each system adds cognitive overhead to do so. Each system creates a new class of failure where the memory management itself goes wrong.
A different premise
Bifrost starts from a different assumption: do not make the model remember. Give it structured artifacts to read.
The distinction matters because it changes where the complexity lives. In a memory-augmented system, the model must decide what to store, when to retrieve, and how to integrate recalled information with its current task. Those are reasoning-intensive operations that compete with the actual work. In an artifact-based system, the governance state is external, deterministic, and pre-structured. The model reads it at session start the same way it reads a configuration file. There is no retrieval decision to make, no recall accuracy to worry about, and no memory management overhead during the session itself.
The implementation is deliberately simple. Three artifacts live in the repository:
governance_contract.json tracks features, their acceptance criteria, and their pass/fail status. It answers: what does “done” mean, and how far along are we? The contract currently carries 122 features, with 113 passing. When a feature fails, it becomes the recommended next action.
.janus/ holds the live session state across tiered files — working.json for the active session (current task, recent decisions, active blockers), governance.json for the trust score, escalation log, and session summaries, and longterm.json for durable patterns and the project’s milestone history. It answers: what happened in previous sessions, what patterns have we seen, and what is the current governance posture?
claude-progress.txt is a human-readable running log — past 5,000 lines and growing. It answers: what was actually accomplished, in plain language, across the full history of the project?
An MCP server provides structured access to these artifacts; three of its tools carry the governance loop. janus_get_bearings reads the governance state and recent git history at session start, producing an orientation in under 200 tokens. janus_foundation_check runs the loop detection heuristic against the persisted iteration count. janus_end_session records progress, updates the trust score, and writes the session summary before context is lost.
The structured governance state is a few tens of kilobytes of JSON. The progress log is larger, but no session reads it whole — bearings orients from a summary, not the raw history. The layer needs no vector search, no embedding models, no retrieval pipelines. It is auditable by a human reading files.
Tiered memory
Not all governance information has the same shelf life.
Bifrost organises persistence into three tiers, each with a different scope and retention policy.
Working memory holds the immediate session context: current task, recent decisions, active blockers. It is volatile by design. When a session ends, working memory is compressed into a summary and archived.
Governance memory holds the trust score, escalation log, foundation check history, and session summaries. This is the tier that enables cross-session Trust Elasticity. It persists across sessions and grows slowly — enough accumulated session history, across roughly six months of work, to reconstruct the full trajectory of the project without re-reading the raw logs.
Long-term memory holds indexed failure patterns. The hindsight system captures specific failure modes and their resolutions in structured notes: what went wrong, why, and what fixed it. There are currently 41 hindsight notes in the system. When the Foundation Check triggers a HALT, the system automatically queries hindsight notes for similar patterns before recommending a recovery path. This means the system learns from its own failures across session boundaries — not through model memory, but through indexed artifacts that any future session can read.
The tiered structure draws on ideas from MemGPT’s hierarchical approach and Cognitive Workspace’s active management, but avoids the overhead of runtime memory decisions. The tiers are populated by explicit governance events (session close, foundation check, escalation), not by the model deciding what seems important.
What this looks like in practice
The operational footprint is easier to show than to describe.
A session begins with bearings. The MCP tool reads the governance artifacts, checks the git history, and produces a brief orientation: current trust score, last session’s work, recommended next feature, and any active blockers. The cost is under 200 tokens. The agent knows where it is without being told.
Work proceeds normally. Trust Elasticity operates within the session exactly as described in Article III — iteration tracking, semantic similarity checking, confidence inference. The difference is that the iteration count does not start from zero. If the previous session ended at N=2 on a particular approach, this session’s Foundation Check inherits that count. The loop detection spans session boundaries.
When the session ends — whether by natural conclusion or approaching context limits — the end-session tool writes a structured summary to the governance tier and updates the progress log. The trust score carries forward. The escalation log carries forward. The hindsight notes carry forward. Nothing is lost to the session boundary.
Session 47 picks up where session 46 left off. The Foundation Check still fires at N=3 across sessions. The trust score reflects the cumulative behavioural track record, not just the last thirty minutes of interaction.
Why artifacts beat recall
The case for file-backed governance over model-managed memory comes down to three properties.
Auditability. Governance artifacts are plain text in a git repository. They have version history, diffs, and blame. A compliance reviewer can read them without running the AI system. A memory-augmented model’s internal state is opaque by default — you can ask the model what it remembers, but you are back to trusting self-report, and Article II explained why that is fragile.
Determinism. When Bifrost reads the session state, the result is the same every time. The trust score reads the last recorded value, the iteration count picks up exactly where it stopped, the last session closed with a specific summary. There is no retrieval variance, no relevance scoring, no risk that the system recalls a stale or incorrect version of its own history. The artifact is the single source of truth.
Cost. Bifrost adds no runtime overhead during the session. The bearings call happens once at startup. The end-session call happens once at close. Between those two points, the governance state sits in files and does not consume tokens, attention, or reasoning capacity. Compare this with a memory-augmented system that must evaluate whether to store, retrieve, or update its memory at each turn.
Why this matters for practitioners and buyers
Cross-session governance changes the economics of AI-assisted work in a specific way: it eliminates the re-briefing tax.
In most AI workflows today, operators spend meaningful time at the start of each session reconstructing context. The more complex the project, the more time this takes. In some cases the re-briefing consumes more context than the actual work. Bifrost replaces that manual reconstruction with a structured, automatic, sub-200-token orientation.
For teams building AI workflows, the practical question is whether your system can carry state across session boundaries without either losing information or adding runtime overhead. A system that forgets between sessions will always have a re-briefing cost. A system that manages its own memory will always have a recall-accuracy risk. A system that reads structured artifacts has neither.
For procurement teams evaluating AI tools, the question is sharper: does the tool’s governance persist? If you configure safety policies, define acceptance criteria, establish trust thresholds — do those survive a session restart? If the answer is no, then every session is an unmonitored greenfield, regardless of what the vendor’s documentation says about their governance layer.
Where this stands
Bifrost has been running in continuous production use since December 2025. The governance artifacts in this project span 122 tracked features, 41 indexed hindsight notes, and a progress log past 5,000 lines, accumulated across roughly six months. That is a meaningful operational track record for a single-user research project. It is not a controlled study across teams, organisations, or risk domains.
The approach is informed by the research — MemGPT’s hierarchical memory, Mem0’s production architecture, Cognitive Workspace’s active management, LongMemEval’s benchmarking — but solves the problem differently. Where those systems add capabilities to the model, Bifrost adds structure to the environment. The model does not need to be smarter about memory. It needs better artifacts to read.
The real design question is not whether AI agents should have persistent memory. They obviously should. The question is who manages that persistence — the model, under cognitive load, or the environment, through files it can audit, diff, and trust.
References
Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S. G., Stoica, I., & Gonzalez, J. E. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv. https://arxiv.org/abs/2310.08560
Chhikara, P., Khant, D., Aryan, S., Singh, T., & Yadav, D. (2025). Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv. https://arxiv.org/abs/2504.19413
An, T. (2025). Cognitive Workspace: Active Memory Management for LLMs. arXiv. https://arxiv.org/abs/2508.13171
Wu, D., et al. (2024). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. arXiv. https://arxiv.org/abs/2410.10813
McKinsey & Company. (2026). State of AI Trust in 2026: Shifting to the Agentic Era. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/state-of-ai-trust-in-2026-shifting-to-the-agentic-era
Alex Perry is the founder of Janus Labs and creator of the Janus Protocol. With 15 years leading product and technology delivery, including executive-level oversight of regulatory programs, privacy governance, and multi-squad agile transformation, he specialises in governance infrastructure for human-AI co-reasoning in regulated environments. This article is part of the AI Adoption Science series.
Janus Labs is an independent AI governance research initiative. Learn more at januslabs.com.au.