From Substitution to Outcomes: How AI and SAMR Are Forcing a Rethink of Development Strategy

We like to say we’ve “transformed” how work gets done. But if you look closely at many enterprise systems, you still see the outline of a paper form hiding under a slick UI.

We replaced paper with terminals, terminals with web apps, web apps with SaaS—and then pointed automation at the whole stack. In too many places, we’ve simply substituted one medium for another, without asking whether the underlying process still makes sense.

In this post, I’ll do three things:

• Introduce the SAMR framework as a way to think about how technology shapes work.
• Show how many business processes sit on layers of substitution going all the way back to paper.
• Explain how AI enables goal‑based processes, where we define the outcome and how we’ll know we’ve met it, and let AI figure out the path—without prescriptive step‑by‑step code.

And along the way, we’ll confront an uncomfortable idea: some of your “modern” processes may still be driven by the personal preferences of someone who retired more than fifty years ago.

The Hidden Architecture of Substitution

If you draw a timeline of enterprise “modernization,” it looks something like this:

• Paper forms and filing cabinets.
• Green‑screen terminals presenting those same forms.
• Client–server and web apps that mimic the same fields and flows.
• SaaS and workflow engines orchestrating the same approvals.
• RPA bots clicking through those flows on our behalf.

At every stage, we’ve been very good at substitution:

• The paper form became a digital form.
• The hand‑carried folder became an electronic ticket.
• The physical in‑tray became a queue.

Even our automation is often substitution stacked on substitution. A bot is trained to follow the same keystrokes a clerk once used, on a screen that was itself designed to look like the old form.

The result is familiar: faster, more auditable, more convenient—even genuinely better in many ways. But the logic of the work has often remained untouched.

To unpack why that matters, it helps to borrow a framework from education: SAMR.

SAMR: A Simple Lens for Technology and Work

The SAMR model, originally developed by Ruben Puentedura for educational technology, describes four ways technology can change a task:

• Substitution – Tech is a direct substitute, with no real functional change (a digital worksheet instead of paper).
• Augmentation – Still a substitute, but with meaningful functional improvements (automatic grading, instant feedback).
• Modification – The task itself is significantly redesigned (collaborative editing, peer review, rich media instead of static answers).
• Redefinition – The task becomes something fundamentally new, enabled by technology (global co‑creation projects, real‑time translation, authentic audiences).

Substitution and Augmentation are often grouped as enhancement; Modification and Redefinition as transformation.

Although SAMR was created for classrooms, the logic moves cleanly into enterprise development strategy:

• Most “digitization” efforts sit firmly in Substitution.
• Many “automation” projects nudge into Augmentation.
• Only a fraction of initiatives truly reach Modification or Redefinition—where the work itself changes.

That gap becomes more striking when you consider how our current processes came to be.

The Ghosts in Your Workflow

Every process is a fossil record of prior decisions:

• A manager in the 1970s decided invoices “must always be reviewed twice.”
• A compliance officer in the 1980s insisted that “no payment goes out without a printed checklist signed by finance.”
• An operations lead in the 1990s added a spreadsheet step “just to be safe.”

Over time, those preferences hardened into policy, then into forms, then into fields in a database, then into conditions in a workflow engine.

They were rarely revisited. Instead, they were preserved and re‑implemented each time the technology stack changed.

So today, you may have:

• A cloud‑based, API‑driven, beautifully instrumented system…
• faithfully reproducing a three‑step approval dance invented by a department head who retired before you were born.

That is what stacked Substitution looks like: paper → software → automation, all in service of a pattern no one is quite sure we still need.

And this is the point in the story where AI gives us permission—not just to automate the steps—but to question why the steps exist at all.

From Step‑Based to Goal‑Based: What AI Actually Changes

Traditional process and system design is step‑based:

• Analysts document the current flow.
• Stakeholders negotiate changes.
• Developers encode the agreed sequence as workflow rules, conditionals, and integrations.

The system’s job is to follow that script as faithfully and efficiently as possible.

Modern AI—especially agentic AI and goal‑based agents—opens a different path. AI agents can be given a goal and a set of tools and constraints, then left to plan and execute the steps needed to reach that goal.

In practice, these agents can:

• Interpret a high‑level objective.
• Break it into sub‑goals.
• Select and call APIs, search across systems, and manipulate documents.
• Adapt their plan as they encounter new information or failures.

Instead of hard‑coding how to do the work, we define:

• What outcome we want.
• What rules and policies must never be violated.
• How we will evaluate whether the outcome is acceptable.

A useful analogy is a navigation app:

• Old world: we write down the directions step‑by‑step.
• New world: we provide the destination, constraints (no tolls, arrive before 5 PM), and trust the system to choose and continually update the route.

Goal‑based business processes follow the same pattern. Rather than encoding, “If field X has value Y, send to queue Z, then generate form Q,” we say:

“Given our policies and this data, decide whether to approve this application, generate all required documentation, and notify the right systems—while maintaining an auditable explanation of every decision.”

The AI agent chooses the path. Our job is to define the destination and the guardrails.

When we do that, we finally create space for Modification and Redefinition in the SAMR sense:

• Modification – AI reshapes existing workflows, collapsing handoffs, reordering tasks, or parallelizing work in ways humans didn’t design upfront.
• Redefinition – Entirely new models emerge: proactive systems that intervene before a “case” exists, continuously optimized processes that learn from outcomes, or services that tailor themselves in real time to individual customers.

This is no longer “paper, but digital.” It is a different category of work. workflow automation.

What a Goal‑Based Process Looks Like in Practice

Goal‑based doesn’t mean vague. In fact, it demands much more precision about outcomes than many current workflows ever had.

For a given process, you are defining four things.

Goal

A clear description of the outcome you want, in language a machine can work with.

• Example: “Produce a reconciled ledger for this period with no unreconciled items above $500 and a traceable explanation for every adjustment.”

Constraints and Policies

The rules that must always hold—regulatory, ethical, operational.

• Example: “Never modify transactions prior to the last audited period; always apply GAAP rules; escalate any deviation from standard policy to a human reviewer.”

Success Criteria and Evaluation

How you will assess whether the goal has been met, and whether the way it was met is acceptable.

• Example: “All totals match the system of record; reconciliation tests pass; a sampled set of items shows ≥99% agreement with human judgments; explanations are complete and understandable.”

Tooling Surface

The tools, systems, and actions the AI is allowed to use.

• Example: read APIs for ERP, controlled write APIs for adjustments, access to a document store with policies, and a sandbox environment for dry‑runs.

From a development perspective, the artifacts shift:

• You still write code—but much of it defines tools and contracts (what the AI can do, under what conditions) rather than enumerating every path.
• You design evaluation harnesses: automated tests and monitors that continually score how well the agent is achieving its goals.
• You implement policy and safety layers that make it impossible for the agent to step outside compliant behavior.

The business logic becomes less “if‑then‑else” and more “goal + constraints + tools + tests.” business process management.

Implications for Development Strategy

If we take SAMR and goal‑based AI seriously, a few strategic implications follow.

Start from outcomes, not swimlanes

If your first artifact for a new system is still a swimlane diagram, you’re anchoring yourself in a step‑based worldview. For AI‑enabled processes, early conversations should center on:

• Which outcome do we care about most?
• How will we know, quantitatively and qualitatively, that we’ve achieved it?
• What constraints are truly non‑negotiable?

Only after that do we ask, “What must remain in human hands, and what can be delegated to AI?”

Treat existing processes as hints, not holy writ

Existing workflows, RPA scripts, and macros are valuable—but not because they represent the ideal design. They are observed behavior, full of legacy assumptions.

• Use them to discover implicit rules (“we always check X before Y”).
• Distinguish between steps that exist for real risk reasons and those that persist out of habit.
• Be explicit about which parts of the flow you are willing to let AI reorganize—or remove entirely.

Design human + AI collaboration on purpose

In most organizations, the near‑term reality is not fully autonomous AI agents running your business, but semi‑autonomous agents operating inside guardrails with human oversight.

That means:

• Deliberately designing when and how AI asks for help.
• Giving people tools to inspect why an agent chose a path, not just the final output.
• Measuring not just throughput, but the change in cognitive load and decision quality for human experts.

Measure outcomes, not motion

If you continue to measure success in terms of “tickets closed” or “cases touched,” goal‑based processes will look like a bad fit. Their value shows up in:

• Time to goal achieved (e.g., “issue resolved to the customer’s satisfaction,” not just “ticket closed”).
• Quality of the outcome (accuracy, compliance, customer impact).
• Reduced rework and escalation, not just reduced click‑time.

Those are the metrics that tell you whether you’ve moved from SAMR’s enhancement tiers into genuine transformation.

Bringing It Together

Let’s return to the three promises from the beginning.

We used the SAMR model to frame how technology interacts with work: from simple substitution to genuine redefinition. In many organizations, “digital transformation” has stalled at the lower tiers—new interfaces on top of old logic, with automation layered on top.

We traced how that happens: processes crystallize around decisions and preferences that may be decades old, then get faithfully re‑implemented in each new generation of technology. Some of your most advanced systems may still be carrying the fingerprints of someone who retired fifty years ago.

And we explored how AI—particularly in the form of goal‑based agents and processes—offers a way out. By defining goals, constraints, success criteria, and tools, and allowing AI to discover and adapt the path, we create room for Modification and Redefinition in the SAMR sense. We move from coding routes to specifying destinations.

For development leaders, the call to action is straightforward:

• Pick one important, currently “digital” process.
• Rewrite its specification as a clear goal with success criteria, instead of a flowchart of steps.
• Ask, honestly: If we started from this goal, with today’s AI capabilities, is there any reason to keep the process the way it is?

The answer to that question is where your next wave of strategy work should begin.