Duplex and AI gateways,
side by side.
Portkey, LiteLLM and similar gateways route traffic, apply guardrails and manage providers. Duplex learns which decisions work, and acts on them within your rules, at every step of the work.
Comparison current as of 16 October 2026.
Every capability: Duplex and AI gateways.
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 | 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 | Model routing, reliability, guardrails and observability |
| What it carries forward | Context, decisions, outcomes, rules, tasks, skills and what it has learned | Configuration, logs, routing policies and caches |
| What gets better with experience | Its next decisions: confidence, routing, recommendations, tool use and reusable knowledge | 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 | Operational control without continual learning |
| Learning | ||
| Continual learning without retraining | NativeIt keeps learning, outside your model’s weights | Not native |
| Turn-by-turn adaptation | NativeEach new result can change the next decision at once | Routing changes at once, but not from learned outcomes |
| Learning from corrections | NativeA correction changes what Duplex does next | Usually logged; learning from them is external |
| Learning from outcomes | NativeSuccess and failure feed straight back into what it learns | Outcomes show up in telemetry; learning from them is external |
| Learning from rewards | NativeA reward strengthens what worked and corrects what didn’t | Not native |
| 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 | Not native |
| 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 | 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 | 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 | 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 | 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 | 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 | Route, retry, block or fall back, without learning from outcomes |
| Answering familiar work itself | NativeIt makes familiar decisions itself, without another frontier-model call | 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 | 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 | 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 | 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 | 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 | 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 | NativeStrong streaming |
| Work that carries on | ||
| Learning from every step, automatically | Every step, through MCP + hooks or the plugins, feeds one shared learning loop | Requests, responses, cost and latency are logged |
| Context across sessions | NativeWork, decisions, tasks and the context that matters carry on across sessions | 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 | Not native |
| Across models | NativeWhat it learns and your context stay outside the model, and follow the work across providers | 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 | 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 | 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 | 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 | 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 | Not native |
| People, teams and sharing | ||
| For each person | NativeEach person gets their own private context, preferences and learning | Keys and budgets per user; personal behaviour is external |
| For each team | NativeTeams share approved learning, and private work stays private | Configuration and budgets per team |
| Across the organisation | NativeWhat works can move from one person to the team and the organisation, under your rules | 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 | 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 | 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 | Strong input and output guardrails, and routing policies |
| Rules applied before each action | NativeThe hooks check each action against your rules before it runs | 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 | 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 | Strong logs of requests, responses, cost and policy |
| Receipts you can verify | Decisions, skills and deletions can come with receipts you can verify | 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 | 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 | 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 | 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 | Lineage of requests and providers |
| Where it runs and connects | ||
| Any model provider | One intelligence across OpenAI, Anthropic, Google, AWS and compatible models | NativeProvider abstraction is what the category does best |
| MCP | NativeThrough MCP + hooks, Duplex joins every step your agents take | 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 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 | 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 | 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 | 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 | Caching, load balancing and provider choice |
| Survives a model upgrade | YesLearning, context, tasks and rules stay outside any one model | Routing configuration survives, but no learned behaviour is kept |
| 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 | Teams that mainly need provider abstraction, reliability, guardrails and cost control |
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 memory platformsMem0, Zep, AgentCore Memory, Supermemory
- Duplex and fine-tuningFine-tuning and reinforcement fine-tuning
- 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.