AutoGen Agent Memory: Persistent Knowledge Beyond One Run

AutoGen agent memory is an interface, not a complete persistence policy. AutoGen AgentChat can ask a memory provider for relevant context before a model call, but you still choose what gets stored, how identities are scoped, when stale facts are corrected, and whether another tool can inspect the result.

For project knowledge, the durable source of truth should often be files your team can read, edit, diff, and self-host—not only embeddings hidden behind a retrieval API. Meshnote supplies that layer as a Markdown wiki over MCP. AutoGen remains the agent runtime; the wiki remains portable across agents.

First: AutoGen is in maintenance mode

Microsoft's current repository says AutoGen is community-maintained and will not receive new features; new projects should start with Microsoft Agent Framework. That does not make an existing AutoGen deployment disappear. It does change the architecture decision: avoid coupling canonical knowledge to framework-specific state when a migration is likely.

The current AgentChat API defines a Memory protocol with five core operations: add, query, update_context, clear, and close. AssistantAgent uses update_context to inject retrieved material. The basic ListMemory returns a chronological list; persistent extensions include ChromaDB, Redis, and Mem0. AutoGen also includes an MCP workbench, so framework memory and shared project knowledge do not need to be the same store.

Use two memory planes, not one bucket

Plane	Store here	Do not treat it as
Runtime recall	User preferences, recent episodes, semantically retrieved conversation facts	The canonical project record
Readable project knowledge	Decisions, constraints, runbooks, architecture notes, approved facts, source links	A dump of every conversation
Working context	Current task, tool results, temporary plan	Long-term memory

This boundary prevents a common failure: an extracted fact becomes authoritative merely because retrieval ranked it highly. Runtime memory may suggest that “the API uses v1”; the project wiki should say when v2 was adopted, why, and which source established it. The broader persistent-memory architecture guide covers lifecycle and expiry rules, while the Mem0 vs Zep comparison explains when vector or temporal-graph recall is the better runtime plane.

Working setup: connect AutoGen to readable memory over MCP

The example below uses AutoGen's current McpWorkbench and Streamable HTTP transport. It connects an AssistantAgent to a hosted Meshnote project. Create an API key in Meshnote settings, put it in an environment variable, and keep the project slug non-secret.

python -m venv .venv
# Windows: .venv\Scripts\activate
# macOS/Linux: source .venv/bin/activate
pip install -U autogen-agentchat "autogen-ext[openai,mcp]" "mcp<2"

set OPENAI_API_KEY=your_openai_key
set MESHNOTE_API_KEY=mnk_your_key
# macOS/Linux: export OPENAI_API_KEY=... MESHNOTE_API_KEY=...

# agent.py
import asyncio
import os

from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.ui import Console
from autogen_ext.models.openai import OpenAIChatCompletionClient
from autogen_ext.tools.mcp import McpWorkbench, StreamableHttpServerParams

PROJECT = "product"

async def main() -> None:
    params = StreamableHttpServerParams(
        url="https://meshnote.io/mcp",
        headers={
            "Authorization": f"Bearer {os.environ['MESHNOTE_API_KEY']}"
        },
    )
    model_client = OpenAIChatCompletionClient(model="gpt-4.1-mini")

    async with McpWorkbench(server_params=params) as workbench:
        agent = AssistantAgent(
            name="project_agent",
            model_client=model_client,
            workbench=workbench,
            reflect_on_tool_use=True,
            system_message=f"""You work on Meshnote project '{PROJECT}'.
Before answering project questions, call get_schema, then search_wiki.
Read relevant pages before relying on them.
Do not write raw transcripts. Promote only durable decisions, constraints,
runbooks, or corrected facts. Before changing a page, read it and pass its
version back as base_version. If a write conflicts, re-read and merge.
""",
        )
        await Console(agent.run_stream(
            task=(
                "Find our API version decision. If the wiki has no supported "
                "answer, say that plainly; do not invent one."
            )
        ))

    await model_client.close()

asyncio.run(main())

Run it with python agent.py. This is tool-accessible knowledge, not automatic prompt injection: the system message tells the agent when to search. Meshnote's MCP write flow is optimistic: read_page returns a version and write_page requires that value as base_version. That makes concurrent edits visible instead of silently losing one agent's work. For the same architecture across several clients, see shared memory across AI tools.

What the top implementation guides miss: test authority, not just recall

Most AutoGen memory guides demonstrate a preference added to ListMemory or a similarity query against ChromaDB. Those examples prove injection. They do not prove that a production memory can be corrected, isolated, audited, or moved. Run this six-case drill before trusting any design:

Restart: record “deploys require two approvals,” terminate the process, start a new agent, and recover it.
Correction: change two approvals to one. The next answer must use one while history still shows what changed.
Conflict: have two agents edit the same page from one base version. One write must fail or merge explicitly.
Isolation: ask an agent authenticated only for project B to read project A. It must receive no content.
Provenance: ask why the rule exists. The answer should lead to a source or decision note, not merely a similarity score.
Exit: disable AutoGen and inspect the stored Markdown with ordinary file tools. A human or another MCP client must reconstruct the current rule.

This test is the original gap to close: persistence is not enough. A memory system is operationally trustworthy only when current truth, superseded truth, permissions, and recovery are testable.

How the main options fit AutoGen

Option	Best fit	Trade-off
AutoGen ListMemory	Deterministic demos and small context lists	Returns all entries and is not a cross-process knowledge system by itself
ChromaDB or Redis memory	Semantic retrieval over larger corpora	Requires ingestion, scoping, correction, and operational policy
Mem0	Extracted conversational facts and broad integrations	Convenient automation means you must inspect conflict and deletion behavior
Zep/Graphiti	Relationships and facts whose validity changes over time	A temporal graph is more infrastructure than many project wikis need
Letta	Agents whose identity and self-managed memory are part of the runtime	It is a stateful agent platform, not merely an AutoGen storage adapter
Native ChatGPT/Claude memory	Low-setup personal continuity inside one product	Less suitable as a shared, agent-agnostic project record
Meshnote over MCP	Readable, reviewable knowledge shared across tools	Deliberate curation is slower than storing every turn

Published memory benchmarks should inform, not settle, this choice. LoCoMo evaluates long conversations, while 2026 work such as Memora stresses repeated updates and deletion. Vendor scores often use different reader models, judges, retrieval depth, and token budgets. Re-run a representative workload and include stale-fact rejection, latency, context size, and human correction—not just question-answer accuracy.

A practical policy

Keep transient plans in AutoGen's model context.
Use a retrieval backend for high-volume, user-scoped episodic recall.
Promote only durable and attributable project facts to the wiki.
Require read-before-write and explicit conflict handling.
Review stale pages on a schedule; never assume retrieval rank equals truth.
Keep secrets out of both prompts and project memory.

If readable ownership and cross-tool portability are your priority, start syncing — $8/mo. Teams can choose self-hosted from $10/seat/month, with a five-seat minimum.