The Real Self-Improvement Loop Runs in Post-Training, and Your Agent Is Downstream of It

The RSI discourse has a genre problem. It was written by people imagining a mind, so it looks for a mind: a single system that inspects itself, edits itself, and iterates. Post-training does not look like that. It looks like an assembly line with quality control, which is exactly why it got ignored.

The Sequence's framing is that the loop runs inside the pipeline that turns a base model into a product: generate candidate behavior, grade it, keep what scores, feed the survivors back as training signal, repeat. The piece notes this has been running "at industrial scale for two years" at every frontier lab, and that it "gets almost no attention in the RSI conversation, even though it is the one actually" producing the gains.

The author ties it to an earlier argument: that "the factory got automated before the design office, and that the line between them tracks whether the work comes with an answer key." That sentence is the load-bearing one. It is not a claim about model architecture. It is a claim about which work can be graded cheaply, because gradeable work can be looped, and loopable work compounds.

Here is why this matters to someone who runs agents rather than trains models. Every reliability property you care about is downstream of this loop. Whether the model recovers from a failed tool call. Whether it stops instead of inventing a plausible-looking result. Whether it follows a twelve-step instruction to step twelve instead of step nine. Those are not emergent mysteries. They are behaviors that somebody made gradeable, ran through a pipeline, and shipped.

Which also means the reverse. Behaviors nobody can grade cheaply do not improve on that schedule. They improve when a human at a lab decides to build a grader for them, and that decision is a product and cost decision made by people you will never meet. Your agent's competence profile is lumpy for economic reasons, not cognitive ones.

The practical consequence: stop reading capability as a single dial labeled "smarter." Read it as a map of which tasks currently have an answer key attached. That map is what moves, and it moves unevenly.

Once you accept that gradeability is the constraint, the capability landscape stops looking random. Code has an answer key: it compiles or it does not, the tests pass or they do not, the diff applies or it errors. Math has an answer key. Structured extraction against a schema has something close to one. Those are the domains where agents went from demo to daily driver fastest, and the reason is not that they are intellectually easier. It is that the loop can run on them without a human in the scoring seat.

Compare the domains without one. Was that strategy memo good? Was the tone right for this customer? Was pausing to ask the user the correct call, or was it timid? Every one of those requires a judgment call to score, and judgment calls do not industrialize the same way. This is where the factory-versus-design-office split in The Sequence's argument earns its keep as a predictive tool rather than a metaphor.

Science is the interesting middle case, because parts of it come with an answer key and parts of it emphatically do not. A hypothesis can be checked against data; deciding which hypothesis is worth checking cannot. Google's work in this area, discussed in Latent Space's interview with John Platt covering the company's Empirical Research Assistance effort and AI applied to climate problems, sits right on that seam. The interesting question in that kind of work is not whether a model can reason. It is which step of the research loop has a cheap verifier bolted to it.

On a Wardley map, this is a story about uneven evolution. Components with cheap automated verification slide from custom-built toward commodity at speed, because the loop grinds them down. Components whose quality depends on contested human judgment stay stuck in the custom stage, where they get expensive human attention or nothing.

So when you are deciding what to delegate to an agent this quarter, the useful question is not "is the model good enough yet." It is: does this task come with a checkable outcome? If yes, expect the capability to arrive on the loop's schedule whether or not anyone announces it. If no, expect to supply the grader yourself, forever, because nobody upstream is going to build one for your specific definition of good.

Your agent's behavior is a product of two loops running at different speeds with radically different transparency.

The first is the harness: the orchestration code, the tool definitions, the memory layer, the retry policy, the permission model. This loop is fully legible. Mastra's September 22 release enumerates exactly what changed, down to the MCP revision it rebuilt against and the two new vector backends it added. ai@7.0.112 lists its patch changes with commit hashes. You can read them, pin them, skip a version, or revert at 2am when something breaks.

The second loop is post-training, and it publishes nothing comparable. There is no tagged artifact, no per-change diff, no way to hold last month's behavior while you test this month's. When behavior shifts under you, you find out from your own logs, and usually a week late.

This is the asymmetry that the Harness Hypothesis was written for: the value is not in the model, it is in the harness that connects the model to the world. The corollary people skip is that the harness is also the only part of the system you own. It is where your version control lives, where your permission boundaries live, and where your record of what happened lives. Everything upstream of the API call is somebody else's release process.

That has a governance implication most teams have not internalized. If you run agents in a business, you have an undeclared dependency with no change-management process attached. Nobody signs off on it. Nobody reviews it. It updates anyway. The closest analogue in enterprise software history is a managed service that silently rolls its own engine version, except that here the engine's behavior is probabilistic and the failure mode is a confidently wrong output rather than a stack trace.

The response is not to complain about opacity, which is a competitive choice labs are unlikely to reverse. The response is to treat the harness as your instrumentation layer: log enough that you can detect drift, and structure agent orchestration patterns so that a behavior change degrades into a stop rather than into a silent wrong answer. You cannot pin the model. You can decide what happens when it surprises you.

The clearest evidence that the model layer is moving underneath everyone is what the harness layer keeps building to compensate for it.

Look at what shipped in Mastra 1.68.0. Tools that need extra input no longer improvise around the model: they use first-class suspend and resume, with server routes returning an explicit suspended state carrying a resume schema, versus a completed state carrying output. The paused state travels as signed, self-contained continuation data. Translated out of framework language: the agent can stop in the middle of a job, ask you something, and pick up exactly where it left off, and the system can prove the paused job was not tampered with in between.

That is not a model capability. That is a harness capability designed on the assumption that the model's mid-task judgment cannot be fully trusted, so the pause point gets made explicit and inspectable rather than left to the model's discretion. Same release adds Azure AI Search and Weaviate as vector backends for memory and retrieval, which is the same instinct applied to context: keep the durable facts in infrastructure you control rather than in whatever the model happens to recall.

Vercel's release points the same direction from a different angle. Among the patch changes in ai@7.0.112 is reporting consumer cancellation in stream end callbacks, plus pruning of reasoning file parts when reasoning is removed. Unglamorous. Also exactly what you need if you want to know that a user hit stop rather than that a model wandered off, and if you do not want intermediate reasoning artifacts lingering where they should not.

Read across both releases and a pattern shows up: the harness layer is industrializing control and observability while the model layer industrializes capability. Two loops, two different owners, two different currencies.

This maps directly onto the Autonomy Spectrum. Most agent failures come from deploying at the wrong point on the copilot-to-autonomous range, and the post-training loop keeps quietly moving where the right point is. A task that needed supervision in March may not in October, and something that worked in October may regress. Explicit suspend and resume is how you make that movable line a configuration decision rather than a gamble, because the agent stops at a boundary you defined instead of at whatever confidence threshold the weights happen to encode this month.

If the loop is the product, then the scarce asset is not the model. It is the machinery that decides what counts as a good answer.

This is the same structural argument Ben Thompson makes about physical assets in his piece on Amazon blocking Muse, where the case is that Amazon's physical world investments function as an AI moat, with room for a deal precisely because of that. The generalizable point is that in a world where model capability diffuses, durable advantage sits in the thing that cannot be replicated by training on public text: real-world assets, proprietary demand, or a verified feedback channel nobody else has.

Apply that to post-training and the moat resolves into three things, none of which is parameters: the graders, the trajectory data from real usage, and the operational discipline to run the loop without poisoning it. Weights are copyable. A two-year-old grading pipeline tuned against real failures is not.

Which explains a pattern in how labs behave toward the layer above them. Commoditize Your Complement predicts that a firm subsidizes the adjacent layer so its own layer keeps margin, and the behavior of the model vendors toward harness tooling is consistent with that reading: give away SDKs, publish protocols, make integration free, keep the pipeline private. The Mastra release rebuilding on a specific MCP revision is a small illustration of the dynamic. Protocol work at the harness layer moves in public and iterates in the open, while the thing that makes any given model worth wiring up does not.

Aggregation Theory finishes the thought. The winner is whoever owns the user relationship, and the interesting contest in agents is between harness owners who hold the user, the context, and the permissions, and model owners who hold the loop that sets the ceiling on what the harness can promise. Neither side is fully dependent. Both are uncomfortable.

For the reader running agents, the takeaway is cold but useful: you are a demand signal inside somebody else's improvement loop. Your usage patterns, your failure reports, your abandoned tasks are the raw material of the next capability tier. That is not sinister. It is the business model. But it means the roadmap for your agent is set by aggregate demand across millions of sessions, not by your workflow, and if your workflow is unusual, the loop will not come for it. You will have to build that grader yourself.

There is a security shape to all of this, and a vulnerability published the same week makes it concrete.

CVE-2026-91130 covers a cross-site scripting issue in Home Assistant: an authenticated party can give a statistics-capable entity a malicious name, and anyone who hovers over a data point on a chart containing that entity gets attacked. The advisory notes the more impactful variant. The malicious name can arrive from the integration provider itself, naming Tibber, Shelly, or any HACS integration as examples, and gets exploited through the default name without requiring any access to the instance at all. The advisory calls this the same supply-chain vector as a prior CVE.

That is the whole lesson in one paragraph. Content supplied by an upstream party you chose to trust flows into a surface you render, and the trust decision was made once, at install time, for all future values.

The Trust Boundary Model says to identify every place data crosses from one trust level to another and to inspect and enforce there. Most agent operators draw that boundary around obvious things: files, network calls, shell access, third-party skills. Very few draw it around model behavior itself, because behavior does not feel like data. It feels like a property of the tool. But if the post-training loop is running continuously upstream, then behavior is exactly like the entity name in that advisory: a value supplied by a third party, changing without notice, rendered directly into your operations.

The Swiss Cheese Model explains how that turns into an incident. A slightly more eager model that now attempts a step it previously declined, plus a tool permission that was scoped loosely because the old behavior made it moot, plus a log you do not read, and the holes line up. No single layer failed badly. The combination did.

None of this argues against running agents. It argues for assuming that the capability surface is a moving input rather than a fixed dependency, and for putting the inspection point where you actually control it: at the boundary between agent intent and consequential action. That is the same discipline that ai agent security 2026 conversations keep arriving at from the malicious-input direction. The post-training loop gets you there from the benign-upstream-change direction, which is the one nobody schedules a review for.

If post-training is a self-improvement loop you cannot see, the move is not to demand transparency that will not arrive. It is to build the smallest possible version of the same loop around your own use of agents.

That means owning three things.

• An answer key for your work. Twenty to fifty real tasks from your actual workflow, with outcomes you can check without arguing about them. Not a benchmark. Your tasks. This is the only instrument that tells you whether an upstream change helped you or hurt you, and it is the thing the loop upstream will never build on your behalf.
• A pinned, legible harness. Everything visible in releases like Mastra 1.68.0 or ai@7.0.112 is yours to control. Pin it, read the changelogs, and keep the suspend points and cancellation paths explicit so a behavior shift surfaces as a stop rather than as a surprise.
• A boundary that assumes drift. Scope permissions to the worst case of a slightly more confident model, not the average case of the one you tested. The Home Assistant advisory is a reminder of how far an upstream-supplied value can travel when nothing inspects it on the way in.

There is a fourth thing that does not fit in a bullet, which is access to practice that has not been written down yet. The operational knowledge here is genesis-stage: almost nobody has published how they actually detect model drift in production agents, because the people doing it are busy doing it. Which is why sessions like the Birds of a Feather evening on agentic engineering that Simon Willison and Jesse Vincent are hosting in San Francisco on October 14 are worth more than they look. The stated interest is in "work you haven't discussed publicly, odd experiments, or unfinished projects that don't have an obvious market." That is a fair description of where the real operating knowledge on this lives right now. The same instinct shows up in the steady, unglamorous iteration of tools like llm 0.36: people building instruments because they need to see something.

The RSI debate asked whether an AI would improve itself. The Sequence's answer is that one already does, on a shop floor, with graders and quality control and two years of production history. The interesting question for everyone downstream is no longer whether the loop exists. It is whether you have built the one small loop that tells you what the big one just did to your work.