Long-Running Agents Need More Than Memory
Anthropic's managed-agent harness solves one hard problem: continuity. Progress logs, feature lists, git checkpoints, and startup scripts give each new session a map of what happened before. But continuity is not governance. Knowing what the agent did is not the same as knowing what it was allowed to do.
Long-running agents need both.
Agents as shift workers
The right mental model for a long-running agent is a contractor who arrives each morning, reads the previous day's notes, and picks up where they left off. A good handoff protocol ensures they know the current state: what's been completed, what's in progress, what the immediate priorities are.
But a contractor also works within constraints that aren't in the daily notes. Building codes. Materials specifications. Approved suppliers. Safety protocols. These constraints are separate from the task log. They are the operating environment within which the task is executed.
An agent that has excellent continuity but no governance knows what it's doing and has no reliable constraints on how it does it.
What Anthropic's harness gets right
The harness described in Anthropic's long-running agent documentation solves the continuity problem correctly:
Progress tracking: A structured log of completed steps prevents re-doing work and losing state
Feature lists: Current state is captured so new sessions can orient quickly
Git checkpoints: Work is preserved at meaningful boundaries
Startup scripts: Each session begins with context, not from scratch
Tool availability: The agent has consistent access to the tools it needs
This is good infrastructure. It addresses the core challenge of extending useful agent work beyond single-context windows.
The remaining gap: continuity is not governance
Continuity tells the agent what happened. Governance tells the agent what is allowed.
The gap shows up in specific, predictable ways as agent runs get longer:
Architectural drift over sessions. An agent that runs for 50 sessions on a complex implementation has made hundreds of local decisions. Without governance, those decisions accumulate without being checked against the architectural constraints that should govern them. A constraint violated in session 12 may be replicated in sessions 13 through 50, because the agent reads its own prior output as context and treats the violation as precedent.
Scope creep in autonomous workflows. Long-running agents face a compounding problem: each session's output becomes the next session's context. If session 1 introduces a slightly out-of-scope implementation choice, session 2 builds on it. By session 10, the agent is confidently extending a pattern that should never have been started. Continuity preserves this drift perfectly.
Constraint staleness. A 50-session agent run may span weeks of calendar time. During that time, architectural decisions may be updated, dependencies may be deprecated, and security requirements may change. An agent with continuity but no governance retrieves the same constraints it had in session 1, or none at all.
Why this gets harder as agents run longer
Short single-session agents are relatively easy to govern: inject constraints at session start, validate output before it's committed, done. The context window is small enough that constraints injected at the beginning have meaningful influence throughout.
Long-running agents break these assumptions:
Context windows fill with task history and tool outputs, reducing the influence of constraints injected early
Multi-session runs mean constraints must be maintained and updated across sessions, not just injected once
Autonomous retries and sub-agent spawning mean governance must propagate to surfaces not directly connected to the session start
The longer the run, the larger the governance surface, and the more important it becomes to have enforcement that operates continuously rather than just at session initialization.
The role of governance
Governance for long-running agents is not a one-time injection. It is a continuous enforcement layer that applies at each output boundary, across all sessions, with constraints that reflect the current state of architectural decisions — not the state at session 1.
What this requires:
Decision records as active constraints. Architectural decisions (ADRs) stored as structured, typed, scoped records. Not documentation. Not CLAUDE.md files. Constraints that are retrieved and enforced each time the agent produces output, not read once at session start.
Session-aware retrieval. Each new session retrieves the constraints relevant to what is currently being built — including any updates to those constraints since the run began. An ADR updated in week 2 of a 4-week run applies from week 2 onward.
Hook-level enforcement per output. Each time the agent proposes writing a file, the output is validated against applicable constraints before it is accepted. This runs in every session, not just the first.
Scope boundary enforcement. Governance records define what is in scope for the run. Drift beyond that scope is flagged before it compounds across sessions.
ADRs as durable intent, not documentation
The governance layer for long-running agents is not a different system from the governance layer for single-session agents. It is the same infrastructure, applied with session-awareness.
Mneme provides this infrastructure: structured decision records with scope and precedence, retrieved based on what is being generated, enforced at the hook level before output is accepted. For long-running agents, this means each session operates within the same constraint set as every other session — updated as decisions change, enforced continuously rather than once.
Anthropic's harness handles continuity. Mneme handles what the continuous agent is allowed to produce.
Both layers are necessary. A long-running agent with continuity but no governance knows exactly what it's doing. It just has no reliable architectural constraints on how it does it.
Originally published at mnemehq.com