--- title: "Mem0 Integration" description: "Give AI agents durable long-term memory with Mem0. Agents add, search, and update memories, set expirations so stale context drops out, audit memory history, manage entities, and submit relevance feedback through the Mem0 Platform API." url: https://flowrunner.ai/integrations/mem0 date_modified: 2026-08-01T02:40:32-07:00 --- # Mem0 [Vector Stores & AI Infra](https://flowrunner.ai/integrations/category/vector-stores-ai-infra) Give AI agents durable long-term memory with Mem0. Agents add, search, and update memories, set expirations so stale context drops out, audit memory history, manage entities, and submit relevance feedback through the Mem0 Platform API. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 15 actions · API key · available [Mem0 website](https://app.mem0.ai/) · [Platform Documentation](https://docs.mem0.ai/) · Capability data verified 2026-08-12 1. A returning customer opens a support conversation 2. Search Memories runs hybrid retrieval scoped to the customer, pulling preferences, past issues, and prior decisions 3. The agent screens the results and finds two memories that contradict each other about the customer's plan 4. The contradiction posts to support operations with both memories and their change histories from Get Memory History 5. A person rules on which fact is true, with the full audit trail in front of them 6. Update Memory corrects the record, and Submit Feedback flags the bad memory so extraction improves 7. Add Memories persists the resolved conversation's new facts, with expiration dates on the time-limited ones ## What This Integration Enables A company running multiple AI agents discovers the coordination problem fast: each agent learns things the others need, and none of them share. Mem0 is the memory layer that fixes this, extracting salient facts from conversations and serving them back through hybrid search that fuses semantic, keyword, and entity signals. This connector wires that layer into every FlowRunner agent, which is where it belongs: memory owned by one chatbot is a feature, memory shared across an orchestrated fleet is infrastructure. FlowRunner's position on memory is unsentimental: it is customer data with a lifecycle, an asset and a liability at once. A platform that remembers must also expire, audit, and forget on command, and prove it did. - Store memories from conversations with inferred fact extraction or verbatim capture, metadata, categories, and expiration dates - Retrieve with v3 hybrid search and rich AND/OR/NOT filters, or list entity-scoped memories chronologically - Update, batch-update, and audit memories, with full per-memory change history - Discover which users, agents, apps, and runs hold memories, and delete at any granularity - Feed relevance feedback back into Mem0 so extraction and retrieval improve on your data Reads and writes run at machine speed. The operations that erase what the company knows about a relationship pass through a [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) gate, in both directions that matter. ### Without FlowRunner **Every conversation starts at zero**: The customer explains their setup for the fourth time, to the fourth different agent **Context trapped per tool**: What the sales workflow learned never reaches the support workflow **Memory as landfill**: Whatever got stored stays forever: stale, contradictory, and unauditable ### With FlowRunner **Agents that remember**: Salient facts persist across conversations and surface when they are relevant **One memory layer for the fleet**: Every agent reads and writes the same entity-scoped memory, so knowledge compounds **Memory with a lifecycle**: Expirations drop stale facts, history audits every change, and forgetting is governed ## Use Case Scenarios ### The support agent that remembers the last four tickets A message arrives in [Slack](https://flowrunner.ai/integrations/slack), and before drafting anything, the flow calls Search Memories scoped to the sender. The reply, drafted with [Claude](https://flowrunner.ai/integrations/anthropic-ai), accounts for the customer's environment, their past workaround, and the preference they stated in March. After resolution, Add Memories stores what changed. The customer stops repeating themselves, and escalations arrive with history attached instead of archaeology required. ### Memory as the connective tissue between agents The sales qualification agent learns the prospect's stack and constraints. The onboarding agent, a different flow entirely, recalls them through the same user-scoped memory and skips the questionnaire. The renewal agent, a year later, reads both layers. Entity scoping keeps each customer's record clean, List Entities shows which relationships have accumulated knowledge, and the fleet behaves like an institution with a memory rather than a collection of goldfish. ### The deletion request handled as a procedure A customer asks the company to forget them. The flow assembles the inventory: List Memories scoped to the user, counts and categories, the entity record from List Entities. A person verifies the requester's identity and the scope, and approves. Delete Entity then erases the user and every associated memory in one governed operation, and the completion evidence files itself into [Google Sheets](https://flowrunner.ai/integrations/google-sheets) with timestamps. The company can honor the request, prove it honored it, and never do it by accident. ## Human-in-Loop Highlight Delete Entity permanently destroys an entity and every memory associated with it, and its smaller siblings, Delete Memories by scope and Batch Delete Memories by ID list, can erase a thousand records in one call. None of it can be undone. What makes this gate unusual is that it protects two failure modes that point in opposite directions. Deleting the wrong entity vaporizes years of relationship context the business can never reconstruct. Failing to delete when a customer demands it is a compliance failure with a regulator attached. So the gate is not "never delete"; it is "a person owns the decision either way." The agent assembles the scope, the counts, and the identity verification, a human confirms that this user, this scope, this reason is correct, and only then does the erasure run, with the evidence trail written as it goes. Machine speed for remembering; governed judgment for forgetting. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 15 actions ### Memories 12 - **Add Memories** Extracts and stores long-term memories from an array of conversation messages, associated with at least one entity (User ID, Agent ID, or Run ID). Infers salient facts by default or stores raw text verbatim, with metadata, custom categories, project instructions, and an optional expiration date. Processed asynchronously with a pollable event\_id. - **Search Memories** Hybrid v3 search fusing semantic, keyword, and entity-matching signals into a combined relevance score. Scoped by a Filters object that must reference at least one entity, with AND/OR/NOT groups and comparison operators. - **Search Memories (Legacy v1)** Semantic search on the deprecated v1 API with flat entity parameters. Kept for backward compatibility; the v3 action is preferred. - **List Memories** Lists memories scoped by flat entity parameters in reverse-chronological order with page-based pagination. - **List Memories (Filtered)** Lists memories on the v3 API with the full Filters object, combining entity scope with metadata, category, and date-range conditions. Returns a paginated envelope. - **Get Memory** Retrieves a single memory by ID with its text, entities, categories, metadata, and timestamps. - **Update Memory** Updates a memory's text, metadata, or expiration date by ID. Only supplied fields change. - **Delete Memory** Permanently deletes a single memory by ID. Cannot be undone. - **Delete Memories** Permanently deletes all memories matching an entity scope. Cannot be undone, and runs only behind this page's human gate. - **Get Memory History** Retrieves a memory's full change history: every add, update, and delete with before and after values and timestamps. The audit trail behind every correction. - **Batch Update Memories** Updates the text of up to 1000 memories in one call, each identified by memory\_id. - **Batch Delete Memories** Permanently deletes up to 1000 memories in one call. Cannot be undone, and gated accordingly. ### Entities 2 - **List Entities** Lists every user, agent, app, and run holding memories in the project, with type, identifier, and memory count. The census of what the fleet knows. - **Delete Entity** Permanently deletes an entity and all of its memories. The right-to-be-forgotten operation, executed only after human verification. ### Feedback 1 - **Submit Feedback** Submits relevance feedback on a memory: Positive, Negative, or Very Negative, with an optional reason. The loop that makes retrieval better on your own data. ## Frequently Asked Questions ### What can FlowRunner do with Mem0? FlowRunner agents can run Add Memories, Search Memories, and Search Memories (Legacy v1) in Mem0, plus 12 more actions. ### Does connecting Mem0 to FlowRunner require OAuth? No. Mem0 connects to FlowRunner with an API key, no OAuth flow required. ### Can Mem0 trigger a FlowRunner workflow automatically? Mem0 doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Mem0?** This integration exposes Mem0 to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/mem0. Site index: https://flowrunner.ai/llms.txt