microsoft / microsoft/agent-framework

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

Open
#7,253 2 comments 0 reactions 1 assignee View on GitHub

@sphenry is already working on this.

Since Jul 23, 2026.

memory python
Dominant language
Python
Stars
13.6k
Forks
2.3k
Avg merge
2d 45m
Merged PRs (30d)
358

Description

## Description

We would like to explore whether [EverOS](https://github.com/EverMind-AI/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:

```python
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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.