Memory remembers. Skills codify. Fine-tuning retrains. Gateways route.
Duplex closes the loop.
Most AI infrastructure solves one part of the work. Duplex brings every part into one runtime intelligence that keeps getting better while it works.
Comparison current as of 16 October 2026.
Each one solves one part.
Memory platforms keep information. Skill learning turns experience into instructions. Fine-tuning changes model weights. AI gateways route requests and apply guardrails. Duplex brings all of it together, and keeps improving.
Step 1 of 5: Memory
Every capability, side by side.
Pick one to set beside Duplex, or see them all at once.
- 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.
Set beside Duplex:
| Capability | Duplex | Letta | CopilotKit CLiF | Deeplake Hivemind | Memory platformsMem0, Zep, AgentCore Memory and Supermemory | Fine-tuning and RFT | AI gatewaysPortkey, LiteLLM and similar |
|---|---|---|---|---|---|---|---|
| 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 | A stateful agent platform built around persistent memory and token-space learning | A full-stack pipeline that turns trajectories into skills, evaluations and training data | Shared agent memory that turns traces into skills automatically | Persistent context, facts, episodes and knowledge graphs | Customising a model by training it | Model routing, reliability, guardrails and observability |
| What it carries forward | Context, decisions, outcomes, rules, tasks, skills and what it has learned | Agent memory, conversations, files and skills | Threads, trajectories, insights, skills and evaluations | Sessions, memories and skills scoped to a workspace | Facts, messages, summaries, episodes and graph relationships | A new set of model weights | Configuration, logs, routing policies and caches |
| What gets better with experience | Its next decisions: confidence, routing, recommendations, tool use and reusable knowledge | The agent’s future behaviour, through updated memory and learned skills | The agent’s instructions, through reviewed skills drawn from real workflows | The next session’s behaviour, through distilled skills | Mainly the context given to the next model call | The underlying model’s responses | Request routing and reliability, not what the agent has learned |
| Knowing what happened, and learning from it | NativeIt knows what happened, and learns what to change next | Both are there, mainly through token-space memory and skills | Learning is generated from stored trajectories | Shared memory is turned into reusable skills | Mainly memory; how far it learns varies by vendor | Learning without lasting operational memory | Operational control without continual learning |
| Learning | |||||||
| Continual learning without retraining | NativeIt keeps learning, outside your model’s weights | NativeToken-space and skill learning | NativeSkill learning; fine-tuning data is optional | NativeLearning skills from traces | Improvement through context; how deep it goes varies by platform | NoTraining is how it learns | Not native |
| Turn-by-turn adaptation | NativeEach new result can change the next decision at once | Agent-managed memory can change continuously; skill learning follows finished experience | Analysis runs by hand or on a schedule | Skills are distilled in the background or at the end of a session | Memories can be added continuously, but retrieving them is not adapting | Waits until a training job finishes and the new model is deployed | Routing changes at once, but not from learned outcomes |
| Learning from corrections | NativeA correction changes what Duplex does next | Corrections can update memory or feed learned skills | User changes and app actions feed its learning | Corrections and session traces can become skills | Corrections can be stored and retrieved as context | Corrections must go into a training dataset or a reward pipeline | Usually logged; learning from them is external |
| Learning from outcomes | NativeSuccess and failure feed straight back into what it learns | Possible through reflection on trajectories and agent-managed updates | Outcomes across the stack become insights, skills, evaluations and training data | New skills are drawn from finished sessions | Episodes can be recalled, but learning from outcomes is generally external | NativeWhen outcomes can be turned into rewards | Outcomes show up in telemetry; learning from them is external |
| Learning from rewards | NativeA reward strengthens what worked and corrects what didn’t | Rewards aren’t its main way of learning | Can produce fine-tuning data from evaluated trajectories | Rewards aren’t its main way of learning | Rewards aren’t a standard memory feature | NativeRewards optimise the model’s weights | Not native |
| Credit for the steps behind a result | NativeIt works out which earlier actions led to a later result | Letta doesn’t offer this natively at runtime | Analysing trajectories can surface useful workflow patterns | Analysing traces can find reusable procedures | Not native | Can learn correlations from training examples, but can’t trace a live result back to its steps | Not native |
| How actions move the work | NativeIt learns how each action moves the work from one state to the next | The agent can infer this from context | Can turn workflows into skills | Can capture successful procedures as skills | Stored episodes can serve as examples | May absorb these patterns during training | Not native |
| Predicting what an action will do | NativeFrom what it observes, it predicts what an action will do, tries alternatives and plans | The model reasons over memory | ExternalLeft to the agent framework | Not native | Not native | Implicit inside the trained model, where you can’t edit it | Not native |
| Better choices of action | NativeOutcomes improve which action it picks next | Behaviour improves through memory and skills | Reviewed skills improve the agent’s next instructions | Distilled skills improve the next procedures | Retrieved context may shape behaviour indirectly | NativeBy optimising the model | Routing policies are configured, not learned from outcomes |
| Reusable skills | NativeExperience becomes skills that are tested before use, and can be paused, brought back or withdrawn | NativeTrajectories can become lasting skills that work with any model | NativeTrajectories become reviewed skills, backed by evidence | NativeSessions become skill.md files for the workspace | Depends on the vendor; generally not what the category is built around | Knowledge is absorbed into weights, not packaged as portable skills | Not native |
| Testing and managing skills | A skill is tested before it is relied on, and can be paused, brought back, withdrawn or removed for good | Skills are files you can inspect, manage and version | Published after human review, delivered at a pinned version | Skills stay files you can inspect and edit, linked to the sessions they came from | Usually a lifecycle per record, not per skill | Evaluation happens around training and deployment | Configuration versions, not a lifecycle for learned skills |
| Generalising to related cases | It carries what it learned to related cases and new wording, and into skills it can reuse | Token-space skills generalise procedures across tasks | Skills capture patterns across many production trajectories | Skills capture patterns that recur across sessions | Semantic retrieval finds related information, which is not the same as generalising behaviour | Generalises through the trained weights | Semantic caches match similar requests, but don’t learn how to act |
| Deciding and acting | |||||||
| Knowing how sure it is | NativeBefore every decision, it knows how familiar the case is and how sure it is | Mainly the model’s judgement and how relevant memory is | Driven by evaluation, not a live measure of certainty | How relevant retrieval and skills are, not a measure of certainty | Retrieval scores and relevance signals | The model’s confidence must be measured separately | Provider health, routing and guardrail scores, not certainty about the task |
| Answer, hand over or decline | NativeDuplex answers itself, calls your model, uses a tool or declines, within your rules | The agent usually carries on through model reasoning | ExternalThe host agent decides how to act | ExternalThe host agent decides how to act | ExternalThe host application decides how to act | The trained model still runs on every request | Route, retry, block or fall back, without learning from outcomes |
| Answering familiar work itself | NativeIt makes familiar decisions itself, without another frontier-model call | The model still interprets memory or skills | The model still reads the learned skill | The model still reads the learned skill | The model normally reads the retrieved context | The customised model still runs | A cache may skip a model call, but a cache doesn’t learn from outcomes |
| Handing over what is new or uncertain | New, uncertain or sensitive work goes to the right model, tool or person | The agent and model decide when more help is needed | ExternalThe host agent’s job | ExternalThe host agent’s job | ExternalThe application’s job | ExternalThe application’s job | Strong routing and fallback between providers; certainty about the task stays external |
| Planning, simulation and recommendations | NativeIt predicts what happens next, tries alternatives, builds plans and recommends actions | Mainly through model reasoning and agent tools | ExternalThe host agent’s job | ExternalThe host agent’s job | Memory supplies context; planning stays external | The model may plan better, but the state of the work stays external | Not native |
| 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 | Agents, subagents and shared memory are available | Works across supported agent frameworks | Shares lessons across connected agents | Shared memory can serve several agents | Not native | Some route to agents and MCP tools, but don’t learn which collaboration worked |
| Learning which tools work | It learns which tools work, when to use them and what each one leads to | Skills and memory can improve tool use | Full-stack trajectories capture tool and user actions for new skills | Tool traces can become reusable procedures | Tool results can be remembered | Tool behaviour may improve through training | They expose and route tools, but generally don’t learn from their outcomes |
| Tool actions within your rules | Tools run only through your rules and permissions | Agent permissions and tool configuration | Controlled by the host agent framework | Controlled by the host coding agent | ExternalLeft to the application in memory-only systems | External | Strong routing and guardrails; control of agent actions depends on the integration |
| Streaming | It streams model and tool output, with every step still within your rules | Available through agent and model interfaces | Available through supported agent frameworks | Depends on the host agent | Depends on the vendor | Depends on the model provider | NativeStrong streaming |
| Work that carries on | |||||||
| Learning from every step, automatically | Every step, through MCP + hooks or the plugins, feeds one shared learning loop | The Letta runtime stores agent conversations and actions | AG-UI captures agent and user actions as full-stack trajectories | Agent sessions and tool activity are captured automatically | SDK or harness integrations capture messages and events | Logs or datasets must be supplied for training | Requests, responses, cost and latency are logged |
| Context across sessions | NativeWork, decisions, tasks and the context that matters carry on across sessions | NativePersistent agents keep memory across conversations | Durable threads keep app interactions | NativeShared memory outlives agent sessions | NativeThis is what the category is built around | Not native | ExternalGenerally |
| Long-running work | NativeLong work stays open across sessions and agents, with safe points to go back to, until it is finished or forgotten | Persistent agents can carry on work, its lifecycle set by the agent and the app | Durable threads keep the history of interactions | Session memory helps pick work back up | Context can be retrieved, but managing the state of tasks is external | Not native | Not native |
| Across models | NativeWhat it learns and your context stay outside the model, and follow the work across providers | Strong: token-space memory and skills can survive a change of model | Strong: skills can be delivered across supported agent stacks | Strong: skills and memory can be reused by different coding agents | Generally strong, because memory doesn’t depend on the model | Weak: a new base model usually needs retraining or revalidation | Strong for routing, but nothing learned carries over |
| Across apps and agents | The same work carries on across Claude, Codex, Cursor, Hermes and your own agents | Stateful agents are reachable through SDKs and hosted MCP | Skills can be delivered through supported framework adapters | Shared memory connects Claude Code, Codex, Cursor and other agents | Possible when apps share the same memory identity | Not native | Requests can share one gateway, but what each app knows stays external |
| Handing work to another agent | A task and its context pass to another agent you allow, ready to continue | Shared agents and repositories can support a handoff | Shared trajectories and published skills keep behaviour consistent | Workspace skills pass lessons between agents | Another authorised agent can retrieve the shared context | Not native | Agent and MCP routing may be available; what the task means stays external |
| Keeping context compact | Context stays compact, focused on the rules, tasks and decisions that matter | Memory organisation, summaries and file-style context management | Trajectories are distilled into insights and skills | Sessions are distilled into compact skills | Summaries, extracted memories and episodic records | Not native | Prompt truncation or caching, not a lasting summary of what matters |
| Learning from images, audio, video and PDFs | It learns from images, audio, video and PDFs, as it does from text | Depends on the connected model and agent tools | Depends on the captured app events and the agent stack | Focused mainly on sessions and tool traces | Depends on the vendor and the model | Supported when the model and the training service accept the medium | Mainly passes supported media through to providers |
| Across media | A question in words can draw on what was learned from images, audio and video, and media can shape later decisions | Depends on the model and how memory is built | Outside CLiF’s main focus | Outside Hivemind’s main focus | Available in products that index more than text | Encoded into weights when the training supports it | Not native |
| People, teams and sharing | |||||||
| For each person | NativeEach person gets their own private context, preferences and learning | Native memory per agent and per user | Possible through app threads and learning containers | Available through personal or workspace scope | Strong memory per user or per actor | Usually needs a separately trained or adapted model | Keys and budgets per user; personal behaviour is external |
| For each team | NativeTeams share approved learning, and private work stays private | Shared memory repositories and skills | Published skills spread team learning | Shared workspace memory and skills | Available through namespaces, graphs or shared stores | Usually needs shared training data and a shared model | Configuration and budgets per team |
| Across the organisation | NativeWhat works can move from one person to the team and the organisation, under your rules | Skills and memory can be shared across the organisation | Reviewed skills can be spread across supported agents | Workspace lessons can spread across connected agents | Shared organisational memory is possible | A custom model can encode common behaviour for the organisation | Routing and guardrails across the organisation, without learning from outcomes |
| Sharing between people, under control | You choose what is shared and with whom, and can withdraw it; anything shared shows who it came from | Shared repositories and collaboration permissions | Project and deployment permissions | Workspace access controls | Vendor-specific namespaces, IAM or graph permissions | Access controls for datasets and models | Key, team and role controls |
| Protection for shared content | What someone shares arrives as information, never as instructions, so it can’t steer another person’s agent | Relies on agent context and permissions | Developer policy and tool restrictions outrank skills | Relies on how skills load, and on trust in the workspace | Depends on the app and the vendor | Training data needs its own controls before training | Guardrails can inspect shared inputs, but trust in what they mean stays external |
| Control and trust | |||||||
| Your rules | Your rules are part of how Duplex works: they allow, decline or limit real actions | Instructions and permissions shape agent behaviour | Learned skills can’t override developer safety rules or tool restrictions | Skills guide the agent, but enforce nothing on their own | Context can inform behaviour, but doesn’t authorise actions | Behaviour is shaped by training, not by live rules | Strong input and output guardrails, and routing policies |
| Rules applied before each action | NativeThe hooks check each action against your rules before it runs | Depends on the Letta runtime, permissions and tool host | Stays with the host app and the agent framework | Stays with the host agent | Memory supplies context, but doesn’t authorise outside actions | External | Strong for requests and responses that pass through the gateway |
| People in the loop | A person confirms the actions you choose, and what Duplex learns can be reviewed and undone | Users can inspect and manage memory and skills | A strong review before learned skills are published | Skills can be inspected and edited before reuse | Set by the app | Training review, evaluation and approval before deployment | Approval workflows vary by gateway |
| 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 | Persistent conversations, memory and agent state | Insights backed by evidence, and their source trajectories | Skills linked to sessions, and stored traces | History, source tracking and audit controls vary by vendor | Training jobs, datasets, reward metrics and model versions | Strong logs of requests, responses, cost and policy |
| Receipts you can verify | Decisions, skills and deletions can come with receipts you can verify | Versioned memories and skills | Links to evidence and exact skill revisions | Skill files linked to their source sessions | Source tracking varies by vendor | Model evaluation and training reports | Logs and guardrail results, not receipts for what was learned |
| Undoing what was learned, exactly | NativeOne learned change can be undone exactly, without retraining anything | Skills and memories can be edited or rolled back through versions | Published skills can be revised or withdrawn | Skill files can be edited or removed | Memories can be deleted, but the behaviour built on them isn’t exactly reversed | Roll back a whole model version, or retrain without the sample | Configuration and cache entries can be removed; there is nothing learned to reverse |
| Forgetting that reaches everything built on it | Removing something also removes what came from it: context, anything shared from it and related learning | Memory and skills are cleaned up through files and versions | Means removing the affected insights, skills and derived assets | Means removing the affected sessions and generated skills | Usually deletes records; derived summaries and copies elsewhere need separate handling | Needs machine unlearning or retraining | Logs and caches follow their own retention |
| Keeping customers apart | Every user, team, organisation and customer is kept apart, in every integration and in everything it shares | Permissions in the cloud and when self-hosted | Isolation per project and deployment | Memory and skills scoped to a workspace | Isolation by user, actor, namespace, graph or IAM | Cloud IAM and model access boundaries | Mature isolation by key, team, budget and role |
| Where everything learned came from | For everything it learned, you can see its source, its scope and how far it can be trusted | Memory and skills stay inspectable | Insights and skills stay linked to the trajectories they came from | Skills can link back to their source sessions | Strong in temporal graph products; varies elsewhere | Dataset lineage and training metadata | Lineage of requests and providers |
| Where it runs and connects | |||||||
| Any model provider | One intelligence across OpenAI, Anthropic, Google, AWS and compatible models | An agent harness that works with any model | Works across supported agent frameworks and models | Works across several coding agents and their models | Generally independent of the model | Usually tied to the customised model and the training provider | NativeProvider abstraction is what the category does best |
| MCP | NativeThrough MCP + hooks, Duplex joins every step your agents take | Hosted MCP lets other agents create and message stateful Letta agents | Skills can reach agents and MCP servers through integrations | Connects with major coding agents; how varies by client | Available in several products, including Supermemory and AgentCore | Not native | Increasingly native |
| 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, CLI and agent-runtime integration | AG-UI and framework adapters | Automatic capture of coding-agent sessions | SDK and MCP integrations | Data collection must be built separately | SDK and proxy integration, not hooks that learn from agent sessions |
| Your cloud, or self-hosted | Vareon Cloud, your cloud or no cloud: private cloud, your own account, self-hosted or air-gapped | Cloud, and a self-hosted app server | Cloud-hosted and self-hosted intelligence | Local agent integration; deployment options vary | Vendor-specific; open-source and managed options exist | Cloud training and hosted inference | Hosted and self-hosted options vary by gateway |
| No cloud: air-gapped | Built for deployments where nothing may leave, with local models, local dependencies and your own identity provider | Possible with a self-hosted stack and local dependencies | Possible with a self-hosted stack and local dependencies | Depends on the chosen deployment and model services | Depends on the platform | Limited to services that support offline training and inference | Available with self-hosted gateways and local providers |
| Cost, speed and fit | |||||||
| How it lowers model cost | Duplex answers familiar work itself, with no repeated frontier-model call | Better context and skills improve results, but the model still runs | Better skills cut failures and rework, but the model still runs | Better skills cut repeated mistakes, but the model still runs | Better context cuts repetition, but adds retrieval and still calls the model | A smaller customised model may give the quality you need | Caching, cheaper models, batching and provider choice |
| How it lowers latency | Decisions it is sure of come back fast; uncertain work still goes to your frontier model | Better-organised context can cut wasted reasoning | Skills make execution more direct | Skills shorten repeated discovery | Faster retrieval and smaller context | Depends on the customised model | Caching, load balancing and provider choice |
| Survives a model upgrade | YesLearning, context, tasks and rules stay outside any one model | YesMemory and skills are deliberately independent of the model | YesSkills and trajectories stay outside the model’s weights | YesSkills survive a change of coding agent or model | YesStored context doesn’t depend on the model | The customisation belongs to one model checkpoint, so it doesn’t carry over automatically | Routing configuration survives, but no learned behaviour is kept |
| Fine-tuning needed | NoFine-tuning becomes an optional step up | No | NoNot for skills; CLiF can also produce fine-tuning data | No | No | Yes | No |
| Best for | Organisations that need their AI agents to learn, act within rules, carry work forward and improve across models, as one system | Teams building persistent, self-improving agents around token-space memory and skills | Product teams turning real user workflows into reviewed skills, evaluations and training assets | Teams that want coding agents to share sessions and reuse lessons automatically | Apps that mainly need durable, relevant user or business context | Stable, high-volume tasks where the model itself must be specialised | Teams that mainly need provider abstraction, reliability, guardrails and cost control |
One closed loop.
Duplex is where context, learning, skills and your rules become one loop, running while the work happens.
Duplex understands the task in hand, and brings back the context that matters.
Step 1 of 8: The task
Why it matters.
An AI model can be intelligent without ever getting experienced at your work.
A memory system shows the model what happened before, but it doesn’t decide what should change. A skill system packages a lesson, but the model still has to read it and follow it. Fine-tuning changes the model, through a slower training cycle that is hard to undo. A gateway controls traffic, but doesn’t learn which decision led to the best outcome.
Duplex turns experience into improvement while it works, within your rules.
That builds a different kind of asset. Every confirmed correction, successful workflow, useful tool result and finished task strengthens the intelligence around your model, and none of it is locked inside one model vendor.
The bottom line.
- MemoryGives an agent a past.
- SkillsGive an agent reusable instructions.
- Fine-tuningGives a model different weights.
- GatewaysGive an AI stack control over traffic.
- DuplexGives the whole agent system the power to carry experience forward, learn from results, act within your rules and improve across models, over time.
Among the products and categories reviewed, Duplex is the only one built to combine:
- Context across sessions
- Continual learning from outcomes
- Learning from corrections and rewards
- Credit for the steps behind a result
- Learning how actions move the work, and predicting what comes next
- Decisions that know how sure they are
- Handing over to the right model, tool or person
- Long work that carries on
- Learning for each person, team and organisation
- Your rules, applied before each action
- Tool actions within your rules
- Sharing between people, under control
- Undoing what was learned, exactly
- Forgetting that reaches everything built on it
- Where everything learned came from, with receipts
- MCP + hooks, and plugins for the assistants you use
- Continuity across models and apps
- Your cloud, self-hosted or air-gapped
- Fewer model calls, as familiar work is answered directly
Duplex makes your AI systems better at the work with every experience.
The sources.
The product pages and documentation this comparison is based on.
- Letta: skill learning →
- Letta: hosted MCP →
- CopilotKit: introducing CLiF →
- CopilotKit: automatic learning →
- Deeplake Hivemind →
- Supermemory →
- Mem0: graph memory →
- Zep: agent memory →
- Amazon Bedrock AgentCore Memory →
- Amazon Bedrock reinforcement fine-tuning →
- Portkey AI gateway →
- LiteLLM AI gateway →
Comparison current as of 16 October 2026.
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.