Python: support mem0ai 2.x

[eavanvalkenburg]

Motivation & Context

Mem0ContextProvider needs to support mem0ai 2.x, where OSS search no longer accepts entity IDs as top-level keyword arguments. Without this update, OSS retrieval uses the old 1.x call shape and fails against the newer SDK.

This also replaces the earlier implementation in #6129 with the same compatibility goal plus passing package checks on the current branch.

Description & Review Guide

• What are the major changes?
  • Bumps agent-framework-mem0 to mem0ai>=2.0.0,<3 and refreshes the lockfile.
  • Sends mem0 search entity IDs through filters for mem0ai 2.x.
  • Treats application_id as Platform-only for OSS AsyncMemory, including rejecting OSS application-only configuration and omitting app scope from OSS storage.
  • Adds tests for OSS and Platform search/storage scoping behavior.
  • Caps NumPy below 2.5 in workspace resolver constraints because NumPy 2.5 stubs use Python 3.12 type statements while the repo mypy test profile targets Python 3.10.
• What is the impact of these changes?
  • Mem0 integration works with mem0ai 2.x while preserving explicit scoping behavior for OSS and Platform clients.
  • Package checks continue to pass with the updated dependency set.
• What do you want reviewers to focus on?
  • Whether the OSS handling of Platform-only application_id is the right compatibility behavior for mem0ai 2.x.

Related Issue

Supersedes #6129. No linked issue.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Pull request overview

Updates the Python Mem0 integration to be compatible with mem0ai 2.x by aligning the OSS AsyncMemory search call shape with the new API expectations, and clarifying/strengthening scoping behavior differences between OSS vs Platform clients.

Changes:

• Bump agent-framework-mem0 dependency to mem0ai>=2.0.0,<3 and refresh uv.lock.
• Update Mem0ContextProvider to pass entity scoping via filters for search() (mem0ai 2.x), and treat application_id as Platform-only for OSS (AsyncMemory).
• Add/adjust unit tests for OSS vs Platform search and storage scoping; add workspace NumPy constraint (numpy<2.5) to keep mypy (py3.10 profile) passing.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
python/uv.lock	Updates resolved deps for mem0ai 2.x and applies the workspace numpy<2.5 constraint.
python/pyproject.toml	Adds workspace resolver constraint for numpy<2.5 to keep type checking compatible with the repo’s mypy Python version.
python/packages/mem0/pyproject.toml	Bumps agent-framework-mem0 dependency to mem0ai>=2.0.0,<3.
python/packages/mem0/agent_framework_mem0/_context_provider.py	Adapts Mem0 search scoping to filters (2.x) and enforces Platform-only application_id behavior for OSS clients.
python/packages/mem0/tests/test_mem0_context_provider.py	Adds/updates tests validating OSS vs Platform filter shapes and application_id handling for search/storage.

[github-actions]

Flagged issue

OSS configurations that include both application_id and user_id/agent_id are silently merged across applications: _build_search_kwargs() drops app_id for OSS (_context_provider.py:246-248) and after_run() also omits it on writes (_context_provider.py:225-226). For inputs like (user_id='u1', application_id='appA') vs (user_id='u1', application_id='appB'), both providers hit the same OSS partition. If OS cannot support app scope, this combination should be rejected rather than silently ignored.

---

Source: automated DevFlow PR review

[github-actions]

Automated Code Review

Reviewers: 5 | Confidence: 92%

✓ Correctness

The PR correctly adapts the Mem0ContextProvider to mem0ai 2.x by unifying search calls to use a filters dict (required by the new SDK), properly excluding Platform-only app_id from OSS client paths, and adding validation to reject OSS-only configurations with application_id. The logic is internally consistent, well-tested, and I found no correctness issues.

✓ Security Reliability

The PR cleanly migrates from mem0ai 1.x to 2.x by routing OS search entity IDs through a filters dict and treating application_id as Platform-only. Validation correctly rejects unsupported OS-only configurations early. Error handling with asyncio.gather(return_exceptions=True) and re-raising of CancelledError is appropriate. No injection risks, resource leaks, secrets exposure, or unhandled failure modes were identified.

✓ Test Coverage

The PR has strong test coverage for all behavioral changes. New tests cover OSS filter format changes (filters dict vs direct kwargs), OSS rejection of application_id-only configuration, Platform client app_id propagation, and OSS storage omission of app_id. Unit tests for _build_search_kwargs and _validate_filters complement the integration-level before_run/after_run tests. Assertions are meaningful (checking exact dict shapes, not just no-exception), and mocks appropriately distinguish OS (AsyncMemory) from Platform (AsyncMemoryClient) clients.

✓ Failure Modes

The PR cleanly handles the mem0ai 2.x migration with proper guard rails. The _validate_filters() method correctly prevents OSS clients from reaching Platform-only code paths (app-only fallback), and the unified filters dict approach is well-tested. No silent failures, swallowed exceptions, or operational failure modes are introduced by this change.

✗ Design Approach

The PR mostly aligns the mem0 2.x search call shape, but it also codifies a design that silently drops application_id whenever an OSS AsyncMemory client is used alongside user_id or agent_id. That means OSS callers who supply both scopes will have reads and writes collapsed onto only the user/agent partition, so memories can leak across applications that share the same user or agent identifiers.

Flagged Issues

• OSS configurations that include both application_id and user_id/agent_id are silently merged across applications: _build_search_kwargs() drops app_id for OSS (_context_provider.py:246-248) and after_run() also omits it on writes (_context_provider.py:225-226). For inputs like (user_id='u1', application_id='appA') vs (user_id='u1', application_id='appB'), both providers hit the same OSS partition. If OS cannot support app scope, this combination should be rejected rather than silently ignored.

---

Automated review by eavanvalkenburg's agents

[github-actions]

Python Test Coverage Report •

File	Stmts	Miss	Cover	Missing
packages/mem0/agent_framework_mem0
_context_provider.py	127	9	92%	136, 147, 150–151, 156, 166, 174, 177, 185
TOTAL	45092	5414	87%

Python Unit Test Overview

Tests	Skipped	Failures	Errors	Time
8922	33 💤	0 ❌	0 🔥	2m 17s ⏱️

[eavanvalkenburg]

Addressed the automated review concern in 2faa2fc: OSS AsyncMemory now rejects any configuration that includes application_id, including user_id/application_id or agent_id/application_id combinations, instead of silently dropping app scope. I also restored uv.lock to the upstream main baseline and kept only the mem0ai entry/specifier changes so the broad lock rewrite that caused CI sample typing failures is no longer in the PR diff.

[eavanvalkenburg]

Also addressed the review comment from superseded #6129 in 5018e46: Platform AsyncMemoryClient.add now uses the mem0ai 2.x filters shape for user_id, agent_id, and app_id. OSS AsyncMemory.add still uses direct user_id/agent_id kwargs because that is the OSS add signature.