Duplex and memory platforms,
side by side.
Mem0, Zep, AgentCore Memory and Supermemory keep facts, messages and episodes for the next model call. Duplex learns from experience: it understands the pattern, predicts what comes next and acts on it.
Comparison current as of 16 October 2026.
Every capability: Duplex and memory platforms.
What each one does, group by group, from what it is to what it costs.
- Native
- Built into how the product works at its core.
- External
- You provide it, or assemble it, separately.
- Not native
- The product’s documentation doesn’t list it as a built-in feature. A custom build may still be possible.
| Capability | Duplex | Memory platformsMem0, Zep, AgentCore Memory and Supermemory |
|---|---|---|
| What each one is | ||
| What it is | A runtime intelligence beside your AI: it learns and acts for your agents and assistants, within your rules | Persistent context, facts, episodes and knowledge graphs |
| What it carries forward | Context, decisions, outcomes, rules, tasks, skills and what it has learned | Facts, messages, summaries, episodes and graph relationships |
| What gets better with experience | Its next decisions: confidence, routing, recommendations, tool use and reusable knowledge | Mainly the context given to the next model call |
| Knowing what happened, and learning from it | NativeIt knows what happened, and learns what to change next | Mainly memory; how far it learns varies by vendor |
| Learning | ||
| Continual learning without retraining | NativeIt keeps learning, outside your model’s weights | Improvement through context; how deep it goes varies by platform |
| Turn-by-turn adaptation | NativeEach new result can change the next decision at once | Memories can be added continuously, but retrieving them is not adapting |
| Learning from corrections | NativeA correction changes what Duplex does next | Corrections can be stored and retrieved as context |
| Learning from outcomes | NativeSuccess and failure feed straight back into what it learns | Episodes can be recalled, but learning from outcomes is generally external |
| Learning from rewards | NativeA reward strengthens what worked and corrects what didn’t | Rewards aren’t a standard memory feature |
| Credit for the steps behind a result | NativeIt works out which earlier actions led to a later result | Not native |
| How actions move the work | NativeIt learns how each action moves the work from one state to the next | Stored episodes can serve as examples |
| Predicting what an action will do | NativeFrom what it observes, it predicts what an action will do, tries alternatives and plans | Not native |
| Better choices of action | NativeOutcomes improve which action it picks next | Retrieved context may shape behaviour indirectly |
| Reusable skills | NativeExperience becomes skills that are tested before use, and can be paused, brought back or withdrawn | Depends on the vendor; generally not what the category is built around |
| Testing and managing skills | A skill is tested before it is relied on, and can be paused, brought back, withdrawn or removed for good | Usually a lifecycle per record, not per skill |
| Generalising to related cases | It carries what it learned to related cases and new wording, and into skills it can reuse | Semantic retrieval finds related information, which is not the same as generalising behaviour |
| Deciding and acting | ||
| Knowing how sure it is | NativeBefore every decision, it knows how familiar the case is and how sure it is | Retrieval scores and relevance signals |
| Answer, hand over or decline | NativeDuplex answers itself, calls your model, uses a tool or declines, within your rules | ExternalThe host application decides how to act |
| Answering familiar work itself | NativeIt makes familiar decisions itself, without another frontier-model call | The model normally reads the retrieved context |
| Handing over what is new or uncertain | New, uncertain or sensitive work goes to the right model, tool or person | ExternalThe application’s job |
| Planning, simulation and recommendations | NativeIt predicts what happens next, tries alternatives, builds plans and recommends actions | Memory supplies context; planning stays external |
| Many agents, working together | It sends work to the right agent, splits it within your rules, keeps each agent to its scope and brings the results together | Shared memory can serve several agents |
| Learning which tools work | It learns which tools work, when to use them and what each one leads to | Tool results can be remembered |
| Tool actions within your rules | Tools run only through your rules and permissions | ExternalLeft to the application in memory-only systems |
| Streaming | It streams model and tool output, with every step still within your rules | Depends on the vendor |
| Work that carries on | ||
| Learning from every step, automatically | Every step, through MCP + hooks or the plugins, feeds one shared learning loop | SDK or harness integrations capture messages and events |
| Context across sessions | NativeWork, decisions, tasks and the context that matters carry on across sessions | NativeThis is what the category is built around |
| Long-running work | NativeLong work stays open across sessions and agents, with safe points to go back to, until it is finished or forgotten | Context can be retrieved, but managing the state of tasks is external |
| Across models | NativeWhat it learns and your context stay outside the model, and follow the work across providers | Generally strong, because memory doesn’t depend on the model |
| Across apps and agents | The same work carries on across Claude, Codex, Cursor, Hermes and your own agents | Possible when apps share the same memory identity |
| Handing work to another agent | A task and its context pass to another agent you allow, ready to continue | Another authorised agent can retrieve the shared context |
| Keeping context compact | Context stays compact, focused on the rules, tasks and decisions that matter | Summaries, extracted memories and episodic records |
| Learning from images, audio, video and PDFs | It learns from images, audio, video and PDFs, as it does from text | Depends on the vendor and the model |
| Across media | A question in words can draw on what was learned from images, audio and video, and media can shape later decisions | Available in products that index more than text |
| People, teams and sharing | ||
| For each person | NativeEach person gets their own private context, preferences and learning | Strong memory per user or per actor |
| For each team | NativeTeams share approved learning, and private work stays private | Available through namespaces, graphs or shared stores |
| Across the organisation | NativeWhat works can move from one person to the team and the organisation, under your rules | Shared organisational memory is possible |
| Sharing between people, under control | You choose what is shared and with whom, and can withdraw it; anything shared shows who it came from | Vendor-specific namespaces, IAM or graph permissions |
| Protection for shared content | What someone shares arrives as information, never as instructions, so it can’t steer another person’s agent | Depends on the app and the vendor |
| Control and trust | ||
| Your rules | Your rules are part of how Duplex works: they allow, decline or limit real actions | Context can inform behaviour, but doesn’t authorise actions |
| Rules applied before each action | NativeThe hooks check each action against your rules before it runs | Memory supplies context, but doesn’t authorise outside actions |
| People in the loop | A person confirms the actions you choose, and what Duplex learns can be reviewed and undone | Set by the app |
| A history you can check | A history of every decision, where it came from and what came of it, that can’t be quietly changed | History, source tracking and audit controls vary by vendor |
| Receipts you can verify | Decisions, skills and deletions can come with receipts you can verify | Source tracking varies by vendor |
| Undoing what was learned, exactly | NativeOne learned change can be undone exactly, without retraining anything | Memories can be deleted, but the behaviour built on them isn’t exactly reversed |
| Forgetting that reaches everything built on it | Removing something also removes what came from it: context, anything shared from it and related learning | Usually deletes records; derived summaries and copies elsewhere need separate handling |
| Keeping customers apart | Every user, team, organisation and customer is kept apart, in every integration and in everything it shares | Isolation by user, actor, namespace, graph or IAM |
| Where everything learned came from | For everything it learned, you can see its source, its scope and how far it can be trusted | Strong in temporal graph products; varies elsewhere |
| Where it runs and connects | ||
| Any model provider | One intelligence across OpenAI, Anthropic, Google, AWS and compatible models | Generally independent of the model |
| MCP | NativeThrough MCP + hooks, Duplex joins every step your agents take | Available in several products, including Supermemory and AgentCore |
| Hooks and plugins | NativePlugins for Claude, Codex, Cursor and Hermes, and hooks that bring Duplex in at each step and check sensitive tool actions | SDK and MCP integrations |
| Your cloud, or self-hosted | Vareon Cloud, your cloud or no cloud: private cloud, your own account, self-hosted or air-gapped | Vendor-specific; open-source and managed options exist |
| No cloud: air-gapped | Built for deployments where nothing may leave, with local models, local dependencies and your own identity provider | Depends on the platform |
| Cost, speed and fit | ||
| How it lowers model cost | Duplex answers familiar work itself, with no repeated frontier-model call | Better context cuts repetition, but adds retrieval and still calls the model |
| How it lowers latency | Decisions it is sure of come back fast; uncertain work still goes to your frontier model | Faster retrieval and smaller context |
| Survives a model upgrade | YesLearning, context, tasks and rules stay outside any one model | YesStored context doesn’t depend on the model |
| Fine-tuning needed | NoFine-tuning becomes an optional step up | No |
| Best for | Organisations that need their AI agents to learn, act within rules, carry work forward and improve across models, as one system | Apps that mainly need durable, relevant user or business context |
The other comparisons.
- Duplex and LettaStateful agents with memory and skills
- Duplex and CopilotKit CLiFReal workflows, turned into skills
- Duplex and Deeplake HivemindShared memory for coding agents
- Duplex and fine-tuningFine-tuning and reinforcement fine-tuning
- Duplex and AI gatewaysPortkey, LiteLLM and similar
- The full comparisonDuplex beside all six, side by side
See Duplex on your own work.
Compare it where it counts: a pilot puts Duplex on your own work, with the measures agreed before it begins.