Python: [Feature]: Explore EverOS as an optional Python long-term memory ContextProvider

[Yangtze-Seventh]

Description

We would like to explore whether EverOS could be supported as an optional long-term memory provider for the Python SDK.

This issue is intended to align on the preferred integration and contribution path before implementation, following the repository's contribution guidelines. We are not proposing to make EverOS a default provider or add a required dependency to Agent Framework.

About EverOS

EverOS is an open-source, local-first and Markdown-native memory layer for AI agents. The project currently has more than 11,000 GitHub stars and is designed to keep long-term memory portable, user-owned, and auditable.

Its memory model includes:

• user memory, including episodes and profiles;
• agent memory, including reusable cases and skills derived from execution experience;
• explicit user, agent, application, project, and session scopes;
• REST APIs for search, message ingestion, and flushing;
• self-hosted/local deployment, with Markdown as the durable source of truth.

Repository: https://github.com/EverMind-AI/EverOS
API reference: https://github.com/EverMind-AI/EverOS/blob/main/docs/api.md

Why this may fit Agent Framework

The Python ContextProvider lifecycle appears to map cleanly to EverOS:

• before_run: search the user and/or agent memory tracks and add relevant memories to SessionContext;
• after_run: record the current input, response, and tool-use trajectory through the EverOS ingestion API;
• AgentSession.state: retain provider-specific timestamps and retry/idempotency state;
• origin_session_ids: preserve provenance for memories retrieved from previous sessions.

This would complement, rather than replace, a HistoryProvider: the history provider would continue to own the current conversation history, while EverOS would provide semantic memory across sessions.

For safety, retrieved memories would be injected as explicitly marked untrusted background context through context.extend_messages(...), rather than appended to agent instructions.

Proposed integration shape

Our initial preference is a separately maintained Python package, for example:

from agent_framework import InMemoryHistoryProvider
from agent_framework_everos import EverOSContextProvider

everos = EverOSContextProvider(
    user_id="user-123",
    agent_id="support-agent",
    app_id="microsoft-agent-framework",
    project_id="support",
    search_tracks=("user", "agent"),
)

agent = chat_client.as_agent(
    name="SupportAgent",
    instructions="Help the user.",
    context_providers=[
        InMemoryHistoryProvider(),
        everos,
    ],
)

The proposed adapter would:

1. query the user and agent scopes independently and concurrently;
2. merge episodes, profiles, agent cases, and agent skills with bounded context limits;
3. preserve source attribution and origin session IDs;
4. persist only the original input and response, avoiding memory feedback loops;
5. retain function/tool calls and tool results so EverOS can learn agent cases and skills;
6. call /flush when an ingested batch remains accumulated;
7. fail open on retrieval errors by default, while making write-error behavior configurable.

The EverMind team would own the external package, tests, examples, compatibility tracking, and documentation.

Questions for the maintainers

1. Is an external agent-framework-everos package the preferred integration model for this type of third-party memory provider?
2. Would a Python-first Preview integration be acceptable?
3. Once the package and end-to-end examples are available, would it be appropriate to propose EverOS for the Microsoft Learn Memory AI Context Providers integrations table?
4. Are there additional lifecycle, security, testing, or naming conventions you would like us to follow before preparing the implementation?

If this direction makes sense, we would be happy to prepare the adapter, unit and integration tests, documentation, and a focused follow-up PR in the location recommended by the maintainers.