DM Explains · No. 038 · Architecture
Pluggable agent pipelines: swap the model, keep the wiring
The new coding agent will be obsolete in six months. The question is whether replacing it means a rewrite or a swap.
· 14 min read
Read me first
Pluggable agent pipelines genuinely do turn a model or agent swap into a weekend's work, but only when you decided in advance which seams were allowed to move; bolt swappability on afterwards and you have written glue code with extra ceremony.
Swapping a coding agent: a team wraps their connected commercial coding agent (1) behind a typed interface (2) while the harness, merge policy and audit trail above stay fixed (3) — the router (4) now targets an on-premises model, execution runs decoupled from planning (5), and memory migrates to a local store (6) before disconnecting from external networks.
A team wires a commercial coding agent into its release pipeline: it opens pull requests, the harness scores them, a merge policy decides what lands, and an audit trail records every decision for compliance. Six months later a cheaper or on-premises alternative appears, and the whole workflow — the merge rules, the audit trail, the scripts that track what the agent did — turns out to have been written assuming that one agent's particular quirks. Model and agent releases now arrive every few months. If every upgrade means rewriting orchestration logic, a team either freezes on an ageing component or burns months on each swap, and in regulated settings an unplanned rebuild can mean re-certifying a workflow from the start.
Everyday picture. The family house has one socket shape in every room. Papa plugs in a new lamp, Amma's mixer, or Dadi's heater into the same socket without anyone rewiring the walls.
Where the picture breaks. Unlike appliances, agent components often share context across the whole house — like a household calendar pinned to the fridge — so swapping one still means checking that the shared state still makes sense to whoever is plugged in now.
Why it exists now
Through 2025 and into 2026, several releases converged on the same answer. Microsoft published the open-source Agent Framework, unifying Semantic Kernel's enterprise foundations with AutoGen's orchestration patterns and building in support for the Model Context Protocol (MCP), Agent-to-Agent (A2A), and OpenAPI standards so agents stay portable and vendor-neutral (Microsoft Foundry Blog, 2026). Red Hat described an "agent mesh" pattern for software modernisation where the model layer, served through vLLM, stays swappable across a validated catalog while the harness, workflow tracking, merge policy and audit trail above it stay fixed (Red Hat, 2026). The Weaveflow package introduced what its documentation calls a "USB for AI agents" port contract (PyPI, 2026). And the OxyGent paper argued that production multi-agent systems in complex industrial settings commonly fail to scale precisely because they rely on rigid workflows and non-pluggable components (arXiv, 2026). The shift is from bespoke, hard-wired agent scripts to formally pluggable pipelines — not because flexibility is fashionable, but because the rate of component churn made the old approach expensive.
How it works
Component abstraction
Wrap it, don't wire it in
What it is. Models, agents (model plus runtime), and static tools are each wrapped as a discrete, swappable box rather than called directly from pipeline code.
Why it exists. If a connected commercial coding agent is hard-coded into the harness, replacing it later means touching every place that called it. Wrapping it as a component means the replacement only has to satisfy the same boundary.
Where it breaks. Drawing the boundary in the wrong place just moves the hard-coding problem one layer down — wrapping the agent is pointless if the harness still assumes that agent's specific output format.
How that's handled. Red Hat's agent mesh pattern serves the model layer through vLLM and Red Hat AI Inference, swappable across a validated catalog without touching the harness iterations above it; replacing an agent means introducing a new driver script and updating the YAML the harness reads.
In technical terms
In technical terms: the model layer is served through vLLM behind a validated catalog interface, and an agent swap is implemented as a new driver script plus a YAML configuration change read by the harness, with no change to the orchestration code above it (Red Hat, 2026).
Standard interfaces
Same socket, any appliance
What it is. Components expose typed inputs and outputs, capability tags, or a shared protocol such as MCP, A2A or OpenAPI, instead of a bespoke function signature only one caller understands.
Why it exists. A shared contract is what lets a tool or agent built in a different framework — or by a different team — connect without custom glue code for every pairing.
Where it breaks. A matching socket shape doesn't guarantee the appliance works the same; two components can satisfy the same interface and still behave very differently once plugged in.
How that's handled. Weaveflow exposes typed input and output ports and capability tags as an agent's public interface while keeping its model, memory and tools private; the underlying model can be swapped by changing a "provider:model" string, and a transform is auto-injected when two agents' types are compatible but not identical.
In technical terms
In technical terms: Weaveflow treats an agent's port contract — typed inputs, typed outputs, capability tags — as the only exposed surface; swapping the backing model is a one-line "provider:model" string change, and type-compatible-but-not-identical connections get an automatically injected transform rather than a manual adapter (PyPI, 2026).
Stable orchestration
The backbone doesn't move
What it is. The harness, the audit trail, and the merge policy sit above the swappable components and are not rewritten when a model or agent changes underneath them.
Why it exists. Most of the system should stay rigid; only a few seams should move. If orchestration moved every time a component changed, there would be nothing left to call "stable."
Where it breaks. If orchestration itself needs an upgrade, the whole premise of swap-without-rebuild collapses — the backbone is only useful while it stays still.
How that's handled. Microsoft's open-source Agent Framework unifies Semantic Kernel's enterprise foundations with AutoGen's orchestration patterns and runs across containers, on-premises, or multiple clouds, so workflow logic survives a model or agent swap intact.
In technical terms
In technical terms: the Agent Framework's runtime is cloud-agnostic, deployable in containers, on-premises, or across multiple clouds, and keeps MCP, A2A and OpenAPI as its portability layer so the orchestration code calling an agent does not change when the agent behind it does (Microsoft Foundry Blog, 2026).
Dynamic routing
Plan at runtime, not on paper
A team running a connected commercial coding agent inside a software-modernisation pipeline swaps to an on-prem alternative: 1 interface stays typed ports 2 new driver script replaces the model 3 socket shapes match 4 no transform needed 5 outputs validated against merge policy 6 harness, merge policy and audit trail untouched → pipeline intact without disconnecting from the network early
What it is. Instead of a fixed flowchart drawn before the task starts, the system works out which component handles which step while the task is running.
Why it exists. A pre-drawn directed acyclic graph (DAG) assumes the same components, in the same order, every time. Once components become swappable, the "best" order can depend on which components are plugged in today.
Where it breaks. Runtime planning adds its own failure surface: a graph generated on the fly is harder to audit ahead of time than one written down in advance, which matters in regulated pipelines.
How that's handled. OxyGent replaces rigid, static directed-graph workflows with permission-driven dynamic planning, generating execution graphs at runtime and producing real-time call-graph visibility into which components actually ran.
In technical terms
In technical terms: OxyGent encapsulates agents, tools, large language models, and reasoning flows as pluggable atomic "Oxy" components, then builds the execution graph at runtime under permission constraints rather than compiling it once as a static DAG (arXiv, 2026).
Decoupled execution
Separate the plan from the run
What it is. The work of deciding what to do (planning and reasoning) is kept separate from the work of actually doing it (execution), and the plan is compiled into an optimised execution graph before it runs.
Why it exists. Mixing planning and execution into one pass means every search through possible pipelines re-does both; splitting them lets the expensive planning step be reused.
Where it breaks. This is reported from preliminary, single-source experiments, not a settled industry benchmark, so the numbers should be read as early evidence rather than a guaranteed result.
How that's handled. Stratum separates pipeline execution from planning and reasoning, compiling plans into optimised execution graphs across heterogeneous backends; preliminary experiments report up to 16.6x faster large-scale agentic pipeline search, as of 2026.
In technical terms
In technical terms: Stratum compiles agent-centric plans into execution graphs that run across heterogeneous backends, and its authors report preliminary experiments showing up to 16.6x faster large-scale agentic pipeline search as a result of decoupling the search-time planning step from execution (arXiv, 2026).
Pluggable memory
Swap the cupboard, not the recipe
What it is. The store that holds an agent's working data or conversational history sits behind a common interface, so the backend can change without touching agent logic.
Why it exists. Decoupling storage from agent logic means a cost, latency, or compliance-driven database change doesn't ripple into every place an agent reads or writes memory.
Where it breaks. Swapping a memory store can silently change what context an agent retrieves, since different backends rank or return results differently; logic tuned against one backend's behaviour may not transfer cleanly.
How that's handled. Microsoft's Agent Framework offers pluggable memory modules — Redis, Pinecone, Qdrant, Weaviate, Elasticsearch, Postgres — and deployment templates let agent-stack components run next to the data without custom plumbing.
In technical terms
In technical terms: the Agent Framework exposes a common memory interface over Redis, Pinecone, Qdrant, Weaviate, Elasticsearch and Postgres, as of 2026, while separate deployment templates — such as those Aiven ships for running agent-stack components next to data — remove the need for custom plumbing between the agent and its storage backend (Microsoft Foundry Blog, 2026; Aiven, 2026).
Compared with what came before
| Monolithic agent script | Pluggable agent pipeline | |
|---|---|---|
| Model/agent swap | Rewrite the calling code | Change a config string or driver script |
| Tool integration | Custom glue code per tool | MCP/A2A/OpenAPI contract, reused across tools |
| Workflow structure | Fixed DAG written by hand | Fixed backbone, with some steps planned at runtime |
| Memory backend | Hard-coded to one store | Abstracted behind a common interface |
| What you give up | Nothing extra to build | Time spent defining interfaces and boundaries up front |
The judgement is not that pluggability is free. Defining the ports, capability tags, and the line between "backbone" and "swappable seam" is work done before any benefit shows up. It pays off only across multiple swaps, which is exactly the situation enterprises now expect to be in every few months rather than every few years.
Where it breaks
A matching interface tells you two components can connect, not that the swapped-in one performs equivalently once it's live — a reranking model, a cheaper agent, or a different memory backend can satisfy the same contract and still change what the pipeline actually produces.
Not a guarantee of equivalent behaviour
Standard interfaces (MCP, A2A, OpenAPI, typed ports) establish that a component can be plugged in, not that it performs the same task the same way. Swapping an agent still needs evaluation against the same test cases the old one passed.
Unlimited swappability without a stable backbone is just glue code in disguise: if every layer, including orchestration, is made "flexible," there is no fixed point left to anchor an audit trail or a merge policy against, and the system becomes as brittle as the monolithic script it replaced — just with more configuration files. Runtime planning (OxyGent's approach) and decoupled execution (Stratum's) both trade predictability for adaptability; a graph assembled at runtime is harder to review before the fact than a workflow written down in advance, which matters directly for compliance-sensitive pipelines. And Stratum's 16.6x figure comes from a single source's preliminary experiments, not an independently verified benchmark, so it should be read as an early signal rather than a settled number.
Numbers to carry
| Figure | What it measures |
|---|---|
| Up to 16.6x faster (2026, preliminary) | Stratum's reported speed-up for large-scale agentic pipeline search from decoupling execution from planning |
| Redis, Pinecone, Qdrant, Weaviate, Elasticsearch, Postgres (2026) | Pluggable memory backends supported by Microsoft's Agent Framework |
| MCP, A2A, OpenAPI | The three interoperability standards built into Microsoft's Agent Framework |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "Pluggable means everything in the system can be swapped" | Successful designs hold most of the system rigid — harness, audit trail, merge policy — and make only a few bounded seams swappable |
| "A standard protocol guarantees interchangeable behaviour" | MCP, A2A and OpenAPI establish that components can connect, not that a swapped-in one performs the same way |
| "Runtime planning is strictly better than a fixed workflow" | Runtime-generated execution graphs are harder to audit in advance than a workflow written down ahead of time |
| "Pluggable architecture is free once you set it up" | Defining ports, capability tags and the backbone boundary is work done up front, before any swap benefit appears |
Worked example
- Papa's team runs a connected commercial coding agent inside a software-modernisation pipeline; the harness, merge policy, and audit trail are already built around the agent-mesh pattern, with the model layer served through vLLM behind a validated catalog.
- A compliance requirement arrives: the agent must move on-premises before the network connection to the external vendor is cut.
- The team writes a new driver script for the on-premises agent and updates the YAML file the harness reads — no change to the merge rules, the audit trail format, or the orchestration code.
- Before cutting over, they run the on-premises agent against the same test cases the old agent passed, because a matching interface does not guarantee equivalent output quality.
- Illustrative only: if the old agent opened roughly 40 pull requests a week and the new one opens 38 with a similar pass rate on the harness's checks, that's a swap worth shipping; if it drops to 15, the interface matched but the component didn't.
- The audit trail logs the swap itself as a single configuration change, dated, rather than as a rebuilt pipeline — which is the entire point of having kept the backbone fixed.
Should you use it?
Pluggable pipelines earn their setup cost when an organisation expects to swap models, agents or vendors repeatedly — new releases, a mandated move to an on-premises alternative, or multiple teams composing agents built in different frameworks into one workflow. They are overhead when a script hard-coding one model and one tool is simpler to build and nobody intends to change it, or when the priority is an extremely stable, auditable workflow where introducing swappable seams is itself a source of risk.
The cheapest first experiment is not a full rebuild: pick the one component most likely to change in the next six months — usually the model or the agent — and wrap just that boundary behind a typed interface or config string, leaving everything else as it is. If that swap goes smoothly, the backbone was drawn in the right place.
Say it in the room
"Decide now which two or three seams are allowed to move; wrap only those, and leave the rest of the pipeline exactly as hard-coded as it already is."
Lines to carry
- "Swap the appliance, not the wiring."
- "Most of the system should stay rigid; only a few seams should move."
- "A matching socket shape doesn't guarantee the appliance works the same."
- "Unlimited swappability without a backbone is just glue code in disguise."
- "Measure the swapped-in component against the old one's test cases before trusting it."
FAQ
Isn't this just microservices with extra steps?
Not quite. Microservices decompose business logic into independently deployable services talking over APIs. Pluggable agent pipelines specifically decompose AI reasoning components — models, agents, memory, tools — behind protocols like MCP or A2A, with the orchestration layer and audit trail staying fixed as the backbone rather than service boundaries alone carrying the design.
Does using LangChain or CrewAI already give me this?
A single framework provides building blocks within its own ecosystem, which helps, but a pluggable pipeline specifically targets interoperability across frameworks — LangChain, CrewAI, custom code — through a shared port contract, so no component stays locked to one vendor's framework.
How much extra work is the abstraction layer?
It is work done up front: defining component boundaries, typed ports, and which parts of the system count as the fixed backbone. For a small, single-purpose automation that will never change its model or tool, that work is pure overhead; for a pipeline expected to absorb multiple vendor swaps over its life, it is the cost that makes each swap a configuration change instead of a rewrite.
Can I trust the 16.6x speed-up figure?
Treat it as an early signal, not an industry benchmark. It comes from Stratum's own preliminary experiments in 2026, reported by a single source, measuring large-scale agentic pipeline search specifically — not every agentic workload will see the same gain.
What stops swappability from becoming a mess of its own?
Keeping most of the system rigid. The failure mode described in the OxyGent paper is the opposite problem — systems that stayed rigid everywhere and could not scale — but the fix is not making everything flexible; it is choosing a small number of clearly bounded seams and leaving the rest, including the orchestration backbone, untouched.
Glossary
- MCP (Model Context Protocol) — a standard that lets an AI agent discover and call external tools or data servers without writing custom integration code for each one.
- A2A (Agent-to-Agent) — a protocol allowing agents built in different frameworks or environments to send structured messages and collaborate with each other.
- OpenAPI — a specification format for describing REST APIs, which lets a system automatically turn an existing API into a callable tool.
- DAG (Directed Acyclic Graph) — a fixed, one-directional flowchart of steps; used here to describe rigid, pre-planned agent workflows that pluggable systems try to replace with runtime planning.
- Orchestration layer — the part of a system that decides which agent or tool runs when, and coordinates the overall workflow.
- Harness — the surrounding code and tooling that runs an agent repeatedly, tracks its outputs, and enforces policies like merge rules.
- vLLM — an open-source serving engine used to run large language models efficiently so that different models can be swapped behind the same serving interface.
- Oxy abstraction — OxyGent's term for wrapping agents, tools, large language models, and reasoning flows into a single, uniform, swappable building block.
- Pluggable memory — a design where the system storing an agent's conversational history or working data can be swapped without changing the agent's logic.
- Runtime — the software environment in which an agent actually executes, as opposed to the model's weights or code alone.
- Agent mesh — Red Hat's term for an architecture where models, agents, and tools are treated as swappable components connected through stable interfaces.
- Port contract — a defined set of inputs and outputs an agent exposes, allowing it to connect to any other agent that matches the same contract.
- Capability tags — labels attached to an agent describing what it can do, used by other components to decide whether it is compatible for a given task.
Sources
- Pluggable by design: An agent mesh for software modernization — Red Hat, 2026
- Build your open and agnostic agent stack — Aiven, 2026
- weaveflow v2.1.1 — PyPI, 2026
- Introducing Microsoft Agent Framework: The Open-Source Engine for Agentic AI Apps — Microsoft Foundry Blog, 2026
- OxyGent: Making Multi-Agent Systems Modular, Observable, and Evolvable via Oxy Abstraction — arXiv, 2026
- A Reference Architecture for Integrating Agentic AI into Enterprise Software: Responsibilities, Interactions, and Variability — arXiv, 2026
- stratum: A System Infrastructure for Massive Agent-Centric ML Workloads [Vision] — arXiv, 2026
- Agent Applications: A Reference Architecture for Building and Operating AI Agent Systems — agentapplication.io, 2026