From RPA scripts to Meta-Software: the 6-stage path I keep seeing

You saw the RPA wave; now you're living the agentic one. The path between them is a 6-stage trajectory, and stage 3 — agentic adoption without a Meta-Software layer — is where METR's 19% slowdown shows up. It isn't a bug in the technology. It's the symptom of an absent Pillar 2.

This post is a map, not a roadmap. The difference matters and I'll come back to it. For now: I want to give CIOs and engineering leaders a way to locate themselves on the path so the discomfort they're feeling stops being mysterious.

Why This Map Matters

A lot of organizations are in stage 3 right now without knowing it, and that's the central problem. The vocabulary they have available — "we adopted Copilot", "we're piloting agents", "we set up an AI center of excellence" — does not tell them where they are on the trajectory. It tells them what they bought. Those are different questions, and conflating them is what produces the misdiagnosis: senior engineers exhausted, throughput unchanged or worse, ROI invisible, and nobody able to name why.

The map does three concrete things for a leader. It lets you locate where you actually are today, separately from where the vendor narrative says you are. It lets you avoid skipping stages — which is the single most common mistake, and I'll come back to why it costs so much. And it gives you the vocabulary to explain to a CEO why the agentic investment hasn't shown ROI yet, without that explanation sounding like an excuse.

A posture caveat before the stages: this is a first cut, not a closed derivation. The number of stages could be five or seven depending on how you slice it. What I'd defend more strongly is the structural role of stage 3 — that's where the slowdown lives, that's where the trap is — and the claim that the cost of skipping stages is paid later, with interest. The rest of the partition is provisional.

The 6 Stages of the Path

The stages, in order, with the columns I find useful when drawing this for a leadership team — what runs, what's missing, and the characteristic symptom you'd see from outside.

Stage 0 — atomic RPA. Scripts executing atomic human tasks. No governance layer, no observability beyond "did the script run today". What's missing is any organizational sense of the bot population. The symptom is bots that die silently and nobody notices for weeks because nobody owns the inventory.

Stage 1 — CI/CD plus linters. Isolated policy-as-code, the first hint of Meta-Software showing up but in a single channel. What's missing is calibration: the rules were imported, not negotiated against the codebase they're protecting. The symptom is a high false-positive rate that trains the team to ignore the alerts, which then trains the team to ignore the layer altogether.

Stage 2 — technical observability. Latency, error rates, dashboards. The infrastructure tells you something failed, with millisecond precision. What's missing is functional context — the translation from "the request returned 500" to "the customer couldn't finish checkout". The symptom is incident reviews where the technical timeline is impeccable and the business impact section is improvised.

Stage 3 — agentic adopted without supervisory layer. Coding agents in the IDE, agentic ops on infrastructure, increasingly agents in support and analysis. What's missing is the four sub-categories of Meta-Software (structural validation, contextual continuity, behavioral observability, governance over agentic output) operating with useful latency. The symptom is the METR finding: 19% slowdown for senior practitioners, line-by-line reviews, and a confused team that can't explain why the productivity story isn't materializing.

Stage 4 — partial integration. One or two sub-categories of Meta-Software actually working, typically structural validation and contextual continuity because those are the easiest to retrofit onto existing CI. What's missing is the other two, and the closed loop between Pillar 1 (mixer-fluent practitioners) and Pillar 2. The symptom is partial relief: some categories of failure stop, others don't, and the variance across teams gets larger.

Stage 5 — integrated capability. The four sub-categories operating as organizational capability, not as point tools bolted onto specific projects. Pillar 1 directing Pillar 2 with a closed loop: practitioners reading the Meta-Software output, adjusting their work and the agent's configuration, and the Meta-Software in turn calibrating against the practitioners' judgment. The symptom is that the questions in roadmap planning shift from "how do we adopt agents" to "which classes of work are we governing well and which aren't yet".

Why Stage 3 Is the Most Dangerous

Stage 3 is dangerous because it looks like progress while it pays the highest hidden cost. You adopted the new (agents, agentic flows) without rebuilding the old (the controls, observability, and judgment layer that made the previous era safe). The two halves of the system are now out of phase, and the friction between them is what the team is metabolizing.

The traditional metrics don't catch it. Commits per day hold steady. PRs per week look fine. Story points completed are within range. The slowdown shows up in metrics nobody measures by default — rework rate on agent-generated code, time-to-trust an agent output before merging it, senior fatigue from line-by-line review, mean time from "agent produced something" to "a human confidently signed off". Those numbers move, and they move in the wrong direction. The dashboards weren't built to track them, so the move is invisible to leadership.

The CEO sees the agentic adoption — the announcement, the vendor logos, the all-hands demo — and asks for the ROI story at the next board. The engineering team can't produce one, because they're paying the stage 3 cost without naming it. The conversation that follows is structurally rigged: "the investment isn't paying off" sounds like an engineering execution problem, when the actual diagnosis is "Pillar 2 is missing and we never named it as a workstream".

This is the political risk that should keep a CIO up at night, more than the technical one. A misdiagnosed stage 3 ends careers. A correctly-named stage 3, with a concrete plan to address the missing sub-categories, is a credible quarterly narrative.

Why You Can't Skip Stages

The temptation is obvious: if stage 5 is the destination, why not jump? Buy the platform, hire the consultant, write the policy, declare the capability. The reason this doesn't work isn't aesthetic. Each stage carries a lesson the organization needs to have internalized before the next one becomes operable.

Stage 1 teaches the organization that policy-as-code fails when it isn't calibrated against the actual code. The team learns, through painful false positives, that imported rule sets degrade and that owning the calibration is a continuous job. Without that lesson, an organization handed a stage 5 governance layer will treat it as a vendor product, ignore the alerts within a quarter, and end up worse off than if they'd never installed it.

Stage 2 teaches the difference between "it runs" and "it does the right thing". The team builds the muscle of asking, after every incident, what business behavior actually broke. Without that muscle, the behavioral observability sub-category of Meta-Software is uninterpretable — it produces signal the team doesn't know how to read.

Stage 3 is the forcing function. It's where the organization discovers, viscerally, that the speed-of-line metric is no longer load-bearing and that something else has to take its place. Without that discovery, the move to stage 4 is a budget line, not a conviction. And budget lines don't survive a quarter of pushback.

Skipping stages produces capacity without discipline. The capacity is real — the tools work, the agents work, the platforms work. The discipline is absent, which means the capacity is wielded badly, and the discipline then arrives via crisis: a production incident traced to ungoverned agent output, a regulatory finding, a senior departure. The lesson gets learned. It just gets learned the expensive way.

Early Signals of Each Transition

A short field-guide to the moments when you know you're transitioning, because the moments are quieter than they should be.

Stage 0 to 1: someone in a meeting asks "how many bots do we actually have running across the organization" and nobody knows the answer. Not even within an order of magnitude. That's the moment.

Stage 1 to 2: a post-mortem reveals that every linter passed, every CI check went green, and the feature still didn't work for the customer. The disconnect between technical pass and functional outcome becomes the topic.

Stage 2 to 3: someone — usually an enthusiastic engineering manager or an ambitious senior — starts putting agents on commits, on tickets, on PRs, on infrastructure changes, without any new policy framework wrapped around them. The tools spread faster than the governance.

Stage 3 to 4: a senior says, in a one-on-one or a tired Slack message, "I'm reviewing everything the agent produces line by line, this doesn't scale, we need something". That sentence is the transition signal. If you ignore it, the senior eventually leaves.

Stage 4 to 5: the question "who owns the governance layer" appears on a roadmap doc or in a strategy review, and the answer is unsatisfying. The discomfort with the unsatisfying answer is what drives the move.

How to Locate the Org Without Selling the Destination

A final caveat that matters more than it sounds. Do not use this map to sell a "let's reach stage 5" project. That's the version of the map that turns it into consulting, and it's exactly the move that breaks the diagnostic value.

The map is useful when you use it to name where you are today and to identify the lowest-cost next step. Often that step isn't a full transition — it's closing one specific gap that's currently bleeding. A stage 3 organization might benefit most, in the next two quarters, from operationalizing one of the four sub-categories well rather than chasing all four. The map tells you what's missing. It doesn't tell you the order in which to add it.

Every organization has a natural ceiling that depends on industry, regulatory load, and risk tolerance. Stage 5 isn't a universal destination. A regulated bank may need to operate closer to stage 4 in some domains and stage 2 in others, on purpose, because the cost of governing certain workflows agentically exceeds the benefit. The map is diagnostic. It's not a mandatory roadmap.

What's Missing From This Map (Honesty)

The map has gaps I want to name out loud, because the version of the map that pretends to be complete is the dangerous one.

It doesn't differentiate stages by domain. Security can be operating in stage 4 while coding is in stage 3 and customer-facing analytics is still in stage 1. The single-stage label is a useful shorthand and a real oversimplification. A more honest application would give the organization a stage per domain and then look at the variance.

It doesn't quantify the cost of each transition. I can tell you stage 3 to stage 4 is expensive. I can't yet tell you how expensive, or what the half-life of the investment is, because the data isn't there. The number that does exist — METR's 19% — is about the cost of staying in stage 3, not the cost of leaving it.

It doesn't name the anti-patterns: the organization that's formally in stage 4 (the tools are bought, the org chart shows the function) but culturally still in stage 1 (the alerts are ignored, the rules are imported, the calibration is absent). Those exist in numbers, and the map currently doesn't have a way to flag them.

It's a first cut. Version 2 will come from CIOs and VPEs applying it for twelve months and telling me where it broke. That feedback is what would make the next version honest.

Which stage do you read your organization in? If you're in stage 3 and feeling the slowdown, name the most concrete symptom — send me a DM or reach out via the contact channels at rlabs.cl. I want to contrast it with other cases.

#MetaSoftware #DigitalTransformation #CIO #TechLeadership