One string literal. That's what it now takes to rip the entire agent loop out of your application and replace it with a different one. On September 25, LiteLLM shipped LiteAgents, and the core of it fits in a single line of Python: harness="deepagents". Change it to "claude-sdk", "codex", "pydantic-ai", or "opencode", and your agent runs a completely different harness — different loop, different middleware, different defaults — while your tools, your MCP configuration, your model connection, and your client code stay exactly where they are.
The harness — the layer this entire industry spent 2025 and 2026 fighting over, the thing vendors weld their models to and teams spend months tuning — is now a field in a profile object. A profile that, incidentally, loads from JSON or YAML.
Most people read an announcement like this as a convenience feature. It isn't. It's the endgame of a commoditization arc that has been running all year, and it lands in the same week the opposite trend produced its purest artifact yet. Both signals point at the same conclusion: the loop itself is no longer where the value lives. What's left — the parts that don't swap — is about to become very obvious, and very expensive to have ignored.
What Actually Shipped
The mechanics matter, so let's be precise about what LiteAgents does, because the details are more radical than the pitch.
The interface is modeled on the Claude Agent SDK — the query() pattern with typed messages. Your application receives the same AssistantMessage, UserMessage, and streaming TextDelta objects regardless of which harness is running underneath. LiteAgents adapts your tools, your MCP configuration, and your event stream to each target. Each harness still runs its own native agent loop; what's standardized is the boundary, not the implementation.
Two design choices stand out. First, native controls survive the abstraction: through harness_options you can still reach Deep Agents middleware and backends, or Pydantic AI tool timeouts. The adapter doesn't flatten its targets to a lowest common denominator — which is honest, and also a confession that the harnesses genuinely differ in ways that matter.
Second, durability is a checkbox. A simple agent runs locally with no infrastructure. When a job needs to survive worker restarts or client disconnects, you add Temporal to the profile and run a worker — starting with SQLite, graduating to self-hosted Temporal or Temporal Cloud — and your client API doesn't change. Durable execution, which was an entire engineering discipline with its own specialist tooling eighteen months ago, is now a profile flag. With one caveat that I'll come back to, because it's the most important sentence in the docs: tools that perform external actions still need idempotency if an interrupted action may be retried.
The SDK ships as a preview, with a cookbook that runs the same model, the same Python tool, the same MCP tool, and the same follow-up across all six harness selectors. That cookbook is not documentation. It's a benchmark harness for the harness.
The Pattern Rhymes, Deliberately
If LiteAgents feels familiar, it should. LiteLLM itself did this to the model layer: one interface, any provider, swap with a string. The industry resisted, then adopted it almost universally, because once models converged on capability, the cost of provider lock-in exceeded the benefit of provider intimacy.
Now the same force is applied one layer up. And the precondition — convergence — is met. We know from direct measurement that the same model run through different harnesses can swing by more than 30 points on the same tasks. When the spread between harnesses is that large, harness choice is a per-workload optimization problem, not an identity. And optimization problems demand cheap switching. You can't A/B test an architecture; you can A/B test a config field.
This is how every infrastructure layer dies: not with a replacement, but with an adapter. The database went through it with ORMs and connection pools. The model went through it with LiteLLM. The loop is going through it now. Every layer that gets an adapter stops being a competitive decision and becomes a routing decision.
The Squeeze From Both Ends
Here's where the week gets interesting, because the same seven days produced the exact opposite signal too.
On September 27, MiniMax launched M3.1-Flash-Preview — a coding model with a one-million-token context and five reasoning-effort levels — and it is unavailable as a model. No model card, no benchmark report, no public pricing, no API endpoint. It exists only inside MiniMax Code, the company's own agent product. You cannot call it; you can only run inside its harness.
Days earlier, an anonymous free model called Space Bunny Alpha appeared on OpenRouter, and the community fingerprinted it — 24 out of 24 tokenizer probes matched MiniMax models in one test, 50 out of 50 in another — as an early build of the same system. The pattern is deliberate: collect free real-world benchmark data anonymously, then ship the model as a property of your product. The stealth preview is the eval phase; the in-product launch is the release.
So put the two ends of the week side by side. MiniMax is welding model to harness so tightly the model has no independent existence. LiteLLM is unwelding them so completely that the harness is a string literal. Both strategies can't win long-term, and the tension between them is the actual story of the stack right now.
My read: the unwelders win, and it won't be close. Vendors spent 2026 making model-plus-harness a single artifact, and for a quarter it worked, because the pairs genuinely performed better than the parts. But a pair you can't leave is a pair you're renting. The moment a neutral adapter lets teams measure Codex's loop against Deep Agents against OpenCode on their own tasks with their own tools, the welded pairs get forced back into competing on the merits of each layer separately — which is exactly the competition abstraction was invented to enable. Consolidation happened; what consolidated then got turned into plugins.
Look at What Everyone Else Shipped This Week
If you doubt the loop is commoditized, look at where everyone else is competing. In the same five days:
- LangChain shipped Managed Deep Agents 0.8 — and not one headline feature is about the loop. It's identity-scoped auth, user-level memory that doesn't bleed across callers, HTTP channels for putting agents inside product surfaces, and built-in web search with vendor credentials managed for you.
- n8n launched n8n Agents — prebuilt memory, sessions, versions, approvals, sub-agents — where the genuinely interesting design decisions are all in the tool layer: MCP servers wholesale, or specific integrations with pinned parameters, or entire workflows as tools, with per-tool credentials the agent never holds.
- Prismor went open-source as a runtime control plane that sits between your agent and every tool call, with named governance modes and an MCP gateway that injection-scans server responses before they reach the model's context.
Three major releases, zero of them competing on the agent loop. They're competing on credentials, memory isolation, channels, policy, tool governance. The industry's smartest money looked at the stack and decided the loop is settled — so settled it's worth giving away — and moved one layer out in every direction at once.
What Survives a Commodity
So if the harness is a config field, what are you supposed to engineer? This is the question that separates the teams that benefit from this shift from the teams that get hurt by it.
Your tools and their contracts. Every one of this week's releases treats tools as the durable asset: n8n lets any workflow become one, LiteAgents carries yours across five harnesses unchanged, Prismor exists to govern them. A tool with a clean, well-typed contract outlives any loop you run it from. A tool wired into one harness's internals dies with that harness's fashion cycle.
Your evaluation set. LiteAgents ships with a cookbook that runs identical tasks across six harnesses because the authors understand: once switching is cheap, the only thing that differentiates harnesses is measurement on your workloads. The team with a private eval set of real tasks can swap harnesses in an afternoon and know, with numbers, whether the new one is better. The team without one is switching on vibes.
Your policy layer. Prismor's governance modes compile to a policy.yaml you can edit, and its MCP gateway evaluates every tool call before forwarding it. Policy that lives outside the harness survives the harness. Policy baked into one harness's middleware does not — and this is the trap in LiteAgents' otherwise sound design: those native harness_options are a seductive path back into lock-in. Every setting you push through them is a setting you'll re-implement five times when you switch.
Your idempotency discipline. Here's that caveat from the docs again: the harness can replay, but it cannot un-send. Temporal durability means an interrupted run gets retried — which means any tool that charges money, sends email, or writes to a production system gets executed twice unless you made it idempotent. No amount of harness sophistication fixes this, because it's not a harness problem. It's the oldest problem in distributed systems, resurfacing at the exact boundary where the commoditized layer ends and your code begins. The adapter standardizes the loop; it cannot standardize the side effects.
What This Means for You
If you build agents for a living, this week changes your planning assumptions, concretely:
Stop writing harness glue. Any code that exists to integrate your application with a specific harness — session plumbing, message munging, retry wrappers — is now technical debt with a known expiry date. Route through a neutral boundary, whether that's LiteAgents or your own thin equivalent.
Treat harness choice as a benchmark question, per workload. The 30-point spread between harnesses on the same model means your coding-agent workload and your data-enrichment workload may want different loops. That's only actionable if switching costs nothing. It now costs a config change.
Move your investment to the assets that don't swap. Tools, evals, policies, idempotency, and the data your sessions generate. This is the same argument I make at length in Harness Engineering: The Complete Guide to Agent-First Software Development, and it's getting stronger by the week: engineering effort belongs in the layer you own, not the layer everyone is racing to give away.
Watch the vendors' next move. The welded-pair strategy — MiniMax shipping models that only exist inside one product — is the counter-trend, and it will intensify before it breaks. Every model you can't call directly is a vendor betting that distribution beats abstraction. The adapter says otherwise. Your eval set is how you'll know who won.
The Unsent Email Test
There's a simple way to know whether you're on the right side of this shift. Ask: if my harness disappeared tomorrow — if every trace of the loop I run were replaced by a competitor's overnight — what would I actually lose?
If the answer is "our tools, our eval results, our policies, and our session history," you've built durable assets, and every adapter that ships makes your life cheaper.
If the answer is "about four months of harness-specific middleware," the commoditization just arrived at your door, and it doesn't knock.
The harness became a config field this week. Make sure the same can't be said of anything you own.