Proposal
Define a memory-driven modular agent harness architecture for Mnemon-adjacent agent systems.
Mnemon proposes a harness layer for durable agents: the host agent keeps its execution runtime, while external modules turn experience into governed long-term state and use that state to improve future behavior.
The core idea is to separate the host agent runtime from external capability modules. A host agent should keep its own runtime loop, prompt assembly, tool routing, permission model, UI, and native extension mechanisms. External modules should attach through standard extension points rather than replacing the host runtime.
Self-evolution is one important capability built on this architecture, but it is not the whole architecture. The specific self-evolution harness proposal is tracked in #10.
Motivation
Most capable agent systems already own their execution loop and runtime boundaries. Replacing those runtimes makes adoption harder and fragments the ecosystem.
A modular agent architecture lets capabilities be installed as external modules:
- memory modules
- skill/procedure modules
- evaluation modules
- risk and safety modules
- review and approval modules
- policy modules
- host-specific setup modules
The host agent remains the runtime. Modules provide additional behavior through explicit, inspectable integration surfaces.
The memory-driven thesis is that durable agents should not only call tools or follow prompts. They should preserve agent-specific experience, preferences, decisions, failures, skills, and long-running state, then use that state as the continuity center for future behavior.
Proposed Architecture
The host agent owns:
- ReAct or equivalent execution loop
- prompt assembly
- tool routing
- native skill/runtime discovery
- subagent or worker execution
- permission model
- user interface
- session lifecycle
External modules attach through:
- hooks for lifecycle timing
- skills or protocol documents for reusable operations
- subagent specs for heavier background work
- filesystem state for durable module data
- environment variables for portable path resolution
- setup scripts for concrete host installation
- policy documents for host-readable behavior rules
The host integration contract should be explicit enough that one module can be installed without requiring the whole framework.
This is distinct from a pure tool connectivity layer. Tool protocols connect agents to external tools, data sources, and services. Mnemon organizes memory-centered governance loops around the host agent: memory, skills, goals, evaluation, risk, review, audit, policy, and future replication.
Integration Levels
A host agent may support different levels of modularity:
- Markdown-only: the host reads install docs, guides, and protocols directly.
- Hook-capable: the host can receive lifecycle nudges such as Prime, Remind, Nudge, and Compact.
- Skill-capable: the host can discover and invoke protocol skills.
- Subagent-capable: the host can delegate maintenance tasks to workers.
- Full reference host: the host supports hooks, skills, subagents, filesystem config, and project/user scopes.
Claude Code is the first reference host because it satisfies the full reference-host level. It validates the attachment model, but should not define the full architecture boundary.
Design Principles
- Do not replace the host agent runtime.
- Do not require one universal skill format across all hosts.
- Keep modules independently installable.
- Keep memory as the continuity center for skills, goals, evaluation, review, audit, policy, and future replication.
- Keep module state inspectable on disk where practical.
- Prefer Markdown-readable contracts before opaque adapters.
- Treat setup scripts as concrete installers, not as the architecture itself.
- Let stronger hosts use richer hooks, skills, and subagents without making them mandatory for every host.
Open Source And Community-Shaped Standards
Mnemon should be open source because agent governance should be inspectable, portable, and community-shaped.
A modular harness cannot be designed only around one host agent or one team's workflow. It needs real integration pressure from different runtimes, projects, permission models, memory patterns, skill formats, and failure cases.
Open development is especially important for governance modules. Memory, skill evolution, risk review, approval, audit, policy, and future replication all affect durable agent state or self-modifying behavior. Users should be able to inspect how those modules work, verify their boundaries, and adapt them to their own host environments.
The community can help define and validate:
- new host-agent setup targets
- hook and lifecycle mapping across runtimes
- protocol skills for memory, skills, policy, review, audit, and goals
- state, proposal, report, and audit formats
- safety boundaries, approval gates, rollback paths, and failure cases
- practical patterns that emerge from real long-running agent use
The goal is not to build a closed agent product. The goal is to grow an open harness substrate that can make many host agents more durable, inspectable, and governable.
How Self-Evolution Fits
Self-evolution is a module family within this broader modular agent architecture. In Mnemon, the current self-evolution modules are:
- Memory Loop: working memory, long-term memory, and dreaming consolidation.
- Skill Loop: evidence capture, curator review, active/stale/archived lifecycle, and proposal-first skill mutation.
The broader self-evolution proposal is tracked in #10.
Acceptance Direction
This proposal should guide future work to:
- formalize the host-agent integration contract
- describe host capability levels
- keep module boundaries clear
- generalize setup patterns beyond Claude Code
- let future modules attach without changing the host runtime
- keep memory-centered state as the basis for skills, goals, evaluation, review, audit, and replication
- keep Mnemon from becoming a replacement agent framework
- keep governance modules inspectable and auditable
- invite community validation of host integrations, protocols, state formats, and failure cases
Related
Proposal
Define a memory-driven modular agent harness architecture for Mnemon-adjacent agent systems.
Mnemon proposes a harness layer for durable agents: the host agent keeps its execution runtime, while external modules turn experience into governed long-term state and use that state to improve future behavior.
The core idea is to separate the host agent runtime from external capability modules. A host agent should keep its own runtime loop, prompt assembly, tool routing, permission model, UI, and native extension mechanisms. External modules should attach through standard extension points rather than replacing the host runtime.
Self-evolution is one important capability built on this architecture, but it is not the whole architecture. The specific self-evolution harness proposal is tracked in #10.
Motivation
Most capable agent systems already own their execution loop and runtime boundaries. Replacing those runtimes makes adoption harder and fragments the ecosystem.
A modular agent architecture lets capabilities be installed as external modules:
The host agent remains the runtime. Modules provide additional behavior through explicit, inspectable integration surfaces.
The memory-driven thesis is that durable agents should not only call tools or follow prompts. They should preserve agent-specific experience, preferences, decisions, failures, skills, and long-running state, then use that state as the continuity center for future behavior.
Proposed Architecture
The host agent owns:
External modules attach through:
The host integration contract should be explicit enough that one module can be installed without requiring the whole framework.
This is distinct from a pure tool connectivity layer. Tool protocols connect agents to external tools, data sources, and services. Mnemon organizes memory-centered governance loops around the host agent: memory, skills, goals, evaluation, risk, review, audit, policy, and future replication.
Integration Levels
A host agent may support different levels of modularity:
Claude Code is the first reference host because it satisfies the full reference-host level. It validates the attachment model, but should not define the full architecture boundary.
Design Principles
Open Source And Community-Shaped Standards
Mnemon should be open source because agent governance should be inspectable, portable, and community-shaped.
A modular harness cannot be designed only around one host agent or one team's workflow. It needs real integration pressure from different runtimes, projects, permission models, memory patterns, skill formats, and failure cases.
Open development is especially important for governance modules. Memory, skill evolution, risk review, approval, audit, policy, and future replication all affect durable agent state or self-modifying behavior. Users should be able to inspect how those modules work, verify their boundaries, and adapt them to their own host environments.
The community can help define and validate:
The goal is not to build a closed agent product. The goal is to grow an open harness substrate that can make many host agents more durable, inspectable, and governable.
How Self-Evolution Fits
Self-evolution is a module family within this broader modular agent architecture. In Mnemon, the current self-evolution modules are:
The broader self-evolution proposal is tracked in #10.
Acceptance Direction
This proposal should guide future work to:
Related
docs/harness/docs/harness/modular-agent/DESIGN.mddocs/zh/harness/modular-agent/DESIGN.md