The harness is the product: how XMPro avoids frontier-model lock-in
Nate Jones’s GLM 5.2 video is really about model lock-in
Nate B. Jones published a video titled “Why GLM 5.2 blew my mind.” On the surface it is a review of an impressive open-source model. It is not really about GLM 5.2 at all. The model is the hook. The actual subject is model lock-in, and the video is one of the clearest explanations I have seen of why lock-in happens and why it is so hard to escape.
His starting point is that a model is a brain in a jar. It does nothing useful on its own. What makes it useful is the harness around it: the prompts, the tool calls, the memory architecture, the routing, the governance. GLM 5.2 can be cheaper and, for a lot of everyday work, as good as a frontier model. And yet, Nate points out, almost nobody is switching. He walks through the reasons why, and they are worth listing, because each one is a form of lock-in:
The harness is welded to one model. When Lindy moved from Claude to a DeepSeek architecture, they had to rewrite their entire harness from scratch. The prompts, the tool calls, the memory, none of it lifted and shifted. Change the model and you change the whole work system. The frontier labs are building team-level harnesses (Claude Tag is his example) that quietly absorb your company context. Once the model sits that close to your data, you cannot rip it out, no matter how much cheaper an open model becomes. “Data is alpha.” If you feed your context to a frontier provider’s harness, you end up renting your own company brain back from them. Most work is center-of-distribution, which a cheap model handles fine. So the value is no longer in raw intelligence. It is in the last mile, the harness, and the scarce talent to build one that is not tied to a single vendor.
His conclusion for builders is the right one: own the harness, keep it model-agnostic, keep your context, and route each task to the cheapest model that can do it.
This post takes each of those reasons in turn and shows how XMPro already answers it, in architecture that ships today in the MAGS multi-agent system and the DataStreams runtime. The short version is that XMPro treats the harness as the product and the model as a component you can swap, and the rest of this piece is the evidence for that claim, drawn straight from how the products are built.
A note on “center of distribution”
This phrase runs through the whole analysis, so it is worth defining before we lean on it.
Every model is trained on an enormous body of text. Tasks that appear in that data millions of times, summarize this, classify that, extract the fields, compare a reading against a target, are the center of the distribution. The model has seen the shape of the problem countless times, and a human can check the output at a glance. Tasks that are rare, novel, or specific to one situation sit at the edge.
The consequence is the point. At the center, a cheap or open model is often as good as a frontier model, because competence comes from having seen the pattern, not from reasoning horsepower. At the edge, the frontier model earns its price. So “is this task center or edge” is really the question “how much intelligence does this step need, and which model should run it.”
The same idea appears under several names you may already know, which is a good sign it is describing something real rather than a piece of one commentator’s vocabulary:
In-distribution vs out-of-distribution, from machine learning: whether an input resembles the training data or falls outside it. Center-of-distribution work is in-distribution generalization; the edge is where models are known to degrade. Interpolation vs extrapolation: models are strong at filling in between examples they have seen and weak at reaching beyond them. Center is interpolation, edge is extrapolation. Routine vs non-routine cognitive work, from labor economics (Autor, Levy and Murnane): codifiable, repeatable mental tasks automate first, while non-routine analytical and creative work resists. Observation and reflection, as MAGS uses them, are deliberately the routine kind. Common-cause vs special-cause variation, from statistical process control (Deming, Shewhart): the ordinary, in-spec behavior a standard process handles on its own, versus the exceptional event that needs escalation. An operations reader will recognize this immediately. Routine monitoring and pattern recognition are common-cause work; a genuine anomaly is special-cause. Apply and analyze vs create, from Bloom’s taxonomy: lower-order cognitive tasks that follow a known method versus higher-order tasks that produce something new. We ask the agent to apply and analyze, not to create. The Clear and Complicated domains vs the Complex domain, from Cynefin (Snowden): where best practice or expert good practice applies, versus where the answer is emergent.
Across all of these framings the message is the same. Most of the useful work is repeatable, has an established pattern, and does not require invention. The design intent in MAGS, spelled out later, is to keep the model’s job inside that repeatable middle wherever possible, and to reserve the rare edge task for a more capable and more expensive model.
The core claim
XMPro keeps the harness free of the model by separating four things that a frontier-native harness fuses together:
The model: which LLM answers a given call. The reasoning harness: the deterministic cognitive loop, memory, planning, and consensus around the model. The process: the DataStream, the deterministic dataflow that actually touches the world. The rules: constraints, deontic and organizational rules, and objective functions, held as data.
Figure 1: Swap the model, and what has to change. A frontier-native harness rewrites everything; XMPro changes one config field
Because these are separate, changing any one of them does not force a rewrite of the others. That is the whole game. A frontier-native harness fuses model, prompts, tools, and rules into one codebase, so switching the model means rewriting the system. XMPro’s separation is what makes the Lindy rewrite unnecessary. As the MAGS design notes put it: governance is config-driven, and the code is a parametric executor. The code does not know or care which model it is running.
Layer 1: the model is a config field, not a codebase
The single strongest rebuttal to the lock-in trap is that in MAGS the model is a value, not an integration.
Every provider sits behind one abstract contract. It exposes a single method to generate a response: a list of role-and-content messages goes in, and a text response plus a metrics dictionary comes out. The contract is deliberately generic. No provider-specific request or response type leaks through it. Behind that one contract sit 15+ concrete LLM providers: OpenAI, Azure OpenAI (two API surfaces), Anthropic, Google, AWS Bedrock, Grok, Mistral, Meta/Llama, Cohere, HuggingFace, OpenRouter, and, critically, Ollama and Lemonade, which run locally and self-hosted. A parallel embedding layer fronts 11 embedding providers the same way.
Selection is a runtime switch. The Anthropic client is created only if an Anthropic key is present, the Ollama client only if an Ollama URL is present, and so on. A provider is instantiated only when its credentials exist. The Anthropic implementation itself is a thin HTTP adapter that sets an API-key header. There is no MAGS business logic inside it. Claude is one interchangeable backend among fifteen plus.
Model choice is bound at two levels, both of them data, not code:
Per agent: the agent profile carries its model provider, model name, and token limit as fields, loaded from the database. Per prompt: each stored prompt carries its own model provider and model name. A single agent can route its reflection prompt to a cheap local model and its planning prompt to a frontier model.
This is exactly the router Nate says companies want and struggle to build. In MAGS it is a configuration exercise. Moving a center-of-distribution task from Claude to GLM, or to a local Ollama model, is a change to a database field. The harness, the memory, the planning, the constraints, none of it moves.
Layer 2: the reasoning harness is deterministic and model-independent
The model is only the generative step inside a much larger deterministic scaffold. That scaffold is the ORPA cognitive loop, Observe, Reflect, Plan, Act, Communicate, plus a proactive Sense timer. What matters for the lock-in argument is that the parts of this loop that must be reliable are math and data, not model judgment:
Memory significance is calculated deterministically, combining semantic novelty from the vector database with observation frequency from the time-series database. This is Prospect-Theory and Shannon-information math over stored data, not an LLM asking itself how important something felt. Memory itself lives in the customer’s own data stores: a graph database for the knowledge graph, a time-series database for content and frequency, a vector database for semantic search, and an optional triple store for standards-based reasoning. The two-tier memory, the decision traces, and the knowledge graph are the company brain, and they sit in the company’s databases. Planning is scored against explicit objective functions with weighted formulas such as “0.4 efficiency + 0.3 quality + 0.3 safety.” The LLM drafts, the objective function scores. Consensus across agents is a structured voting process, not a chat. Every decision is traced. The system records full provenance for each decision: an ordered trajectory of every entity touched during the cycle, precedent decisions, and standards linkage (ISO 14224, ISA-95). Full observability runs through all of it.
Swap the model and this scaffold is unchanged. The significance math, the objective functions, the decision traces, and the memory stores are all provider-agnostic. The model is the one component you can pull and replace without touching the reasoning. This is the “generate, then govern” pattern in concrete form: the LLM generates, the deterministic harness governs.
Layer 3: the process is a DataStream, and the AI is one block in it
This is where XMPro’s separation goes further than most people’s mental model of an “AI agent,” and it is the direct answer to “the model owns your workflow.”
A DataStream is a static, operator-defined graph of blocks wired together, authored in a visual designer and persisted as ordinary configuration: the stream, its blocks, and the links between them. Each block is a plugin that satisfies one small contract: create, start, receive events on a named input, and publish events on a named output. Data moves as event batches from block to block, along the links the operator drew. The topology is data, not something the model improvises.
An LLM block is just one block type among connectors, transforms, function blocks, and rules. It satisfies the same contract as a SQL connector, and the runtime treats them identically. That means an AI block can be sandwiched between deterministic blocks that validate its inputs and gate its outputs. The DataStream is the harness; the model is a node inside it.
MAGS connects to this in both directions:
MAGS as a block. The entire multi-agent runtime is packaged as a single DataStream block, shipped as a plugin in the AI and Machine Learning category. A modeler drops the XMPro MAGS Agent onto the canvas like any other block. DataStreams as the agent’s hands. An agent’s tools are themselves DataStreams. When the agent decides to act, it publishes a message to a topic and waits for a reply. It does not run code in-process. The message triggers a deterministic DataStream in the Stream Host.
The MAGS design notes put the consequence plainly: tools are DataStreams, not baked-in code; the agent process holds no downstream credentials, because the connector credentials live in the Stream Host; and DataStreams are the deterministic constraint gate at execution.
Figure 2: XMPro DataStreams with exchangable LLM models
The model has no credentials and no authority to touch the world directly. Every consequential action is proposed by the model and then executed, and gated, by an operator-defined DataStream. If you replace the model, the streams, the connectors, the credentials, and the process logic are untouched.
Recommended by LinkedIn
Layer 4: the rules are data, evaluated by the process, not baked into the model
The rules are the fourth thing frontier-native harnesses tend to weld into prompts and code. XMPro externalizes them.
Policy constraints are data objects: a rule expression such as “emissions <= regulatory_limit,” the measure it applies to, a modality, and an action to take on violation. They are stored in a library and linked to teams, loaded from the database at runtime. Deontic and organizational rules are lists on the agent profile, injected into prompt templates by placeholder substitution. The rules are data poured into a template, not text hard-coded in a model-specific harness. Enforcement is layered, and the model is never the last line of defense. A cheap in-process validator does a first arithmetic check and fails open by design. The authoritative evaluation of complex rules happens in the DataStream at execution time. Safety and regulatory limits are enforced deterministically, downstream of anything the LLM said. Governance by role. Agent roles (Guardian, Orchestrator, Expert) carry enforced permissions. A Guardian enforces constraints independently and is the approver; an Orchestrator cannot act without Guardian approval. This is governance structure held in configuration, not in a model’s weights or a vendor’s system prompt.
Prompts follow the same rule-as-data pattern. They are stored templates with a code fallback, versioned, with placeholders, and each prompt can bind to its own model. A prompt is not welded to one model’s formatting conventions.
Why separate the process and business logic from the rules
Nate’s video explains why you would want a model-agnostic harness. It does not go into why you would separate the process from the rules inside that harness. XMPro does, deliberately, and the reasons matter for an industrial buyer:
They change at different rates and are owned by different people. A process engineer changes the dataflow. A compliance or safety officer changes the constraints. A platform team changes the model. If these three are fused, every change is a cross-team code deployment. Separated, each owner edits their own data: the canvas, the constraint library, the model configuration. This is the organizational version of avoiding the Lindy rewrite. Rules must be auditable and enforced deterministically. In a regulated ISA-95 Level 3/4 environment you cannot have a safety limit that exists only as a suggestion inside a prompt, subject to the mood of whichever model is answering. “Emissions must stay under the regulatory limit” has to be a checkable expression, evaluated by deterministic code, logged with full provenance, the same way every time. Rules-as-data in a DataStream gate give you that. Rules-in-the-model do not. Portability and routing depend on it. Because the rules and the process live outside the model, you can send center-of-distribution reasoning to a cheap local model and edge-of-distribution reasoning to a frontier model without the rules or the process caring. The separation is precisely what makes the “route to the cheapest capable model” strategy achievable, the strategy Nate says almost no company has managed. Determinism where it counts, generation where it helps. The design puts the LLM where variability is an asset (drafting a plan, summarizing an observation, proposing an action) and puts deterministic code where variability is a liability (scoring the objective, validating the constraint, executing the connector, recording the trace). You get the model’s fluency without betting safety on its consistency.
The last mile, and why task-type routing actually works
This is where Nate’s argument bears directly on a buying decision, and it is where XMPro’s design pays off in a way that is easy to miss. Two claims need to be separated:
The last mile is expensive to build. Turning a raw model into something that reliably does a specific job, in a specific operational context, with memory, tools, governance, and integration, is real engineering. Nate says the talent to do it is scarce and that is why frontier providers keep their pricing power. The last mile does not have to be rebuilt per model, per deployment, or per task. It can be built once, as a system, and then parameterized.
XMPro’s answer is the second claim. The last mile is productized, not hand-coded each time. The DataStream designer, the connector library, the agent profiles, the constraint library, the prompt store, and the provider registry are the last mile, delivered as configuration surfaces rather than as a codebase you fork. A new deployment authors data. It does not rewrite a harness.
Model switching is per task, not per system. Because the model is bound at the level of the individual prompt, every distinct cognitive function in the system is its own routing point. There are roughly 40 named prompts, each a separate, independently bindable task. Grouped by the shape of the work:
Perception and summary (the observation and conversation-summary prompts): compress and structure provided data into a fixed schema. A cheap or local model. Reflection (the reflection prompts for each agent role): synthesize patterns from the agent’s own recent memories against stated objectives. A cheap or local model. Classification and formatting (intent classification for retrieval, tool-payload formatting): map an input to a category or a strict output format. A cheap or local model. Decisioning against criteria (plan-adjustment decisions, communication decisions, impact analysis): judge provided context against explicit thresholds. A mid-tier model. Novel plan generation (plan generation and adjustment): compose a plan to reach a goal. A frontier model, when the goal is truly open.
The important property is that changing the model for any one of these changes nothing else. The reflection prompt can run on a local model while the planning prompt runs on a frontier model, in the same agent, at the same time. The routing decision Nate says almost no company has managed to build is here a single setting per prompt.
Why observation and reflection are center-of-distribution work. Nate’s phrase for the tasks a cheap model handles well is “the fat middle of everyday AI work”: tasks with a familiar shape, lots of prior examples, and output a human can check quickly. The design of MAGS deliberately makes the two highest-frequency cognitive steps, Observe and Reflect, exactly that kind of task. The agent is not being asked to invent. It is being asked to run the same analytical pattern over new data, every cycle.
Look at what the observation step actually asks the model to do:
“Carefully analyze the current data and situational context provided. Focus on: identifying key patterns and trends… assessing the current state against optimal conditions… Your task is to observe and analyze only, not to make recommendations or plan actions at this stage.”
And the output is not free-form. It is a fixed schema: a confidence rating out of 10, an analysis section against named criteria, a structured self-evaluation scored 1 to 5, and a summary. This is a fill-the-template transformation of the agent’s own context. It has a familiar shape, it repeats on every cycle over fresh data, and the output is trivially inspectable, a confidence number and a structured analysis you can validate against thresholds. That is the textbook center of the distribution.
Reflection is the same kind of task one level up. The model is handed its recent observations, its past reflections, and its objective functions, and asked to analyze patterns, identify trends, and evaluate the effectiveness of its previous decisions. The prompt states it plainly: “Reflection is not an action, it is internal reasoning about how effectively you are fulfilling your role.” It is bounded introspection over the agent’s own memory, in a fixed format, not open-ended creation.
The hard judgments are pulled out of the model entirely and given to deterministic code:
When to reflect is not a model decision. The loop compares a computed significance score against a threshold on the agent profile. The math is semantic novelty from the vector store times observation frequency from the time-series store. The model never decides whether something mattered enough to think about. Arithmetic does. Whether an action is allowed is not a model decision either. It is the constraint validator and the DataStream gate from Layer 4. How good a plan is is scored by the objective function, not asserted by the model.
So the model is deliberately left with the repeatable, inspectable, center-of-distribution part of each step, and the parts that need to be reliable and reproducible are held in deterministic code. This is the same “generate, then govern” split, applied at the granularity of individual cognitive functions.
Even the hard task is narrowed toward the middle. The one step that looks like invention, planning, is itself constrained so that it is closer to selection than to creation. The plan-generation prompt restricts the model to a declared set of available actions and states the scope explicitly:
“Planning is ONLY concerned with executing Available Actions listed above… If the current goal and conditions do not warrant executing any Available Actions, the correct outcome is NO plan or NO tasks.”
The model is not inventing new capabilities. It is selecting and sequencing from an operator-declared action set to satisfy an objective function. That is a far more bounded problem than “figure out what to do,” and it moves even the planning step toward the center of the distribution, where cheaper models are competitive.
The economics line up with the frequency. The payoff is that cost tracks frequency in the right direction. Observe and Reflect are the high-frequency steps. Sensing runs on a timer, observation fires on every inbound event, and reflection fires whenever the significance threshold is crossed. Planning is the rare step, gated behind a planning interval and an adaptation trigger, and it only produces a plan when conditions actually warrant one. So the tasks that dominate token volume are precisely the bounded, repeatable ones you route to cheap or local models, and the expensive frontier calls are reserved for the rare moments of true novelty.
This is the GLM 5.2 thesis made concrete. Most of the agent’s work is center-of-distribution by design, because MAGS narrows each step until it is, and it routes each step independently, because the model is bound per prompt. The result is that an operator can push the fat middle of the workload onto a cheap open model, keep a frontier model on standby for the rare edge task, and pay for intelligence roughly in proportion to how much of it a task needs.
Point by point against the lock-in traps
A model is useless without a harness. The harness (the ORPA loop, memory, planning, consensus, DataStreams) is the product; the model is a plugged-in component. Switching models means rewriting the harness (the Lindy problem). The model is a setting per agent and per prompt, with 14 providers behind one contract. The harness does not move. Prompts and tool calls are not transferable. Prompts are stored, versioned, provider-neutral templates; tools are DataStreams invoked over a message broker, not model-specific code. The frontier harness absorbs your context. Memory, decision traces, and the knowledge graph live in the customer’s own graph, time-series, and vector databases. You end up renting your company brain back. The company brain is on the customer’s infrastructure; the model reads it and writes to it but never owns it. Center versus edge routing is hard to build. Per-prompt model binding is native; route cheap tasks to local models and hard tasks to frontier, from configuration. Last-mile harness talent is scarce. The last mile is productized: a visual DataStream designer, a constraint library, agent profiles, and a provider registry.
The context-ownership point, specifically
Nate argues that data is alpha, and that a frontier team-level harness makes you rent it back. XMPro’s answer is architectural, not a promise in a privacy policy.
The context a MAGS agent accumulates, its observations, reflections, plans, decisions, the knowledge graph of equipment and relationships, the time series of what happened when, is written to databases the customer runs. The model provider sees only the messages of individual calls, and only for whichever provider is configured for that call, which can be a local model with no external call at all. There is no equivalent of a vendor sitting in your collaboration tools quietly learning your company. The stickiness Nate warns about comes from the harness owning the context. Here the customer owns the harness and the context, and rents nothing but tokens, from whichever provider is cheapest for the task.
Bottom line
Nate is right that the value has moved to the last mile, and that most companies are one model-migration away from discovering their harness is welded to a vendor. XMPro’s answer is that it built the model-agnostic last mile as the product, years before the GLM 5.2 moment made the argument urgent. The model is a field you can change. The reasoning is a deterministic scaffold. The process is a DataStream you draw. The rules are data you edit. The context is yours, on your infrastructure. That is the difference between a harness built around one model and a harness the models plug into, and can be unplugged from, without the business logic ever noticing.
Pieter van Schalkwyk is the CEO of XMPro, specializing in industrial AI agent orchestration and governance. Drawing on 30+ years of experience in industrial automation, he helps organizations implement practical AI solutions that deliver measurable business outcomes while ensuring responsible AI deployment at scale.
He authored the Industrial AI Agent Manifesto, published by the Digital Twin Consortium in February 2026, a governance framework for trustworthy autonomous operations.
Our GitHub Repo has more technical information. You can also contact myself or Gavin Green for more information.
Read more on agentic operations at The Digital Engineer
This article originally appeared on XMPro CEO’s LinkedIn blog, The Digital Engineer, on 5 July 2026.
