Feature: optional EverOS long-term memory integration

Is your feature request related to a problem? Please describe.

Haystack already has a clear ecosystem pattern for long-term memory integrations: Mem0 and Cognee expose a memory store together with Writer/Retriever components, while integrations such as Hindsight add agent-facing memory tools.

EverOS is an Apache-2.0, local-first, Markdown-native memory runtime for agents. It keeps user memory and agent experience/skills as separate first-class tracks, with scoped retrieval across user or agent, app, project, and session. Today, a Haystack user who wants this file-ownable memory model has to hand-wire the HTTP API and decide the write/flush lifecycle themselves.

Describe the solution you'd like

Would the maintainers be open to an optional EverOS integration following Haystack's existing memory integration shape?

A focused first version could provide:

• EverOSMemoryStore
  • add_memories(...) → POST /api/v2/memory/add
  • search_memories(...) → POST /api/v2/memory/search
• EverOSMemoryWriter for pipeline writes
• EverOSMemoryRetriever for pipeline retrieval
• optional agent tools for explicit remember/recall actions

There are two EverOS-specific details that the adapter should make explicit rather than hide:

1. Flush lifecycle. /memory/add can accumulate messages, while /memory/flush materializes durable memory. The integration could expose a policy such as per_write, session_end, or manual.
2. Typed search results. EverOS returns profiles, episodes, agent cases, and agent skills. The Retriever would convert these to Haystack ChatMessage objects while preserving the source type and scope in metadata.

Identity/scoping could map Haystack metadata into EverOS's user_id or agent_id (mutually exclusive), plus optional app_id, project_id, and session_id.

Before opening a PR, it would be helpful to align on:

• Should this begin as an external everos-haystack package listed in the integrations catalog, or would it be a candidate for haystack-core-integrations?
• What minimum serialization and integration-test contract should a new memory store follow?
• For the first PR, would Writer/Retriever components be preferred over agent tools, or should both ship together?

We are happy to implement a focused PR with unit tests, mocked API contract tests, documentation, and a runnable example after agreeing on the expected integration surface.

Describe alternatives you've considered

• A cookbook-only example using custom Haystack components.
• Two standalone tools that call the EverOS API directly.
• A generic MCP connection.

These are quicker, but they do not provide the same composable Writer/Retriever experience as the current Mem0 and Cognee integrations, and they leave flush/scoping behavior to each application.

Additional context

• EverOS repository (currently 12k+ GitHub stars): https://github.com/EverMind-AI/EverOS
• Public API documentation: https://github.com/EverMind-AI/EverOS/blob/main/docs/api.md
• The proposal is for an optional backend, not a change to Haystack's default memory behavior.