Agentic AI Transformation: Google's 4-Stage Playbook

Agentic AI Transformation: Google's 4-Stage Playbook

I had a small argument with myself last Sunday morning. I'd just finished mapping out the seventh "AI agent" I'd built this quarter — a tidy little Claude-powered thing that scrapes competitor pricing, drops it into a sheet, and pings me in Slack. It works. It saves me maybe forty minutes a week. And staring at the diagram, I realized something uncomfortable.

I had built seven agents. I had built zero workflows.

That distinction sounds like semantic nitpicking until you sit with it. Then it stops sounding like nitpicking and starts sounding like the entire reason most enterprise AI pilots quietly die in their second year. Which is exactly the problem Google's new Agentic AI Transformation Framework — the one Clara walks through in the Agentic Strategy course on Google Skills — is built to solve.

I spent the better part of three days working through the framework, mapping it against my own projects, and stress-testing whether it actually holds up outside of a polished retail demo. Some of it changed how I'm structuring my next client engagement. Some of it I think is genuinely overcomplicated for solo builders. And one piece of it — the value engineering stage — is the thing I wish someone had handed me eighteen months ago.

Let me show you what I mean.

The Difference Between an Agent and an Agentic Workflow

Here is the line that reframed the whole thing for me: an AI agent does a task. An agentic AI system runs a process.

When I built that competitor pricing scraper, I built an agent. It does one thing, in one slot, and then it stops. A human still has to look at the data, decide whether our pricing needs to move, write the change ticket, get approval, and push it live. The agent is a tool. The workflow is still entirely human.

An agentic system is what happens when you stop slotting AI into individual tasks and start handing it the entire process. It pulls competitor pricing. It reasons about whether the gap matters. It checks our margin policy. It drafts a pricing change. It runs it past whoever needs to approve. It pushes the update to the product catalog. It monitors conversion for the next 72 hours and either holds the change or rolls it back.

That is not a bigger agent. That is a different category of system.

Google's framing — and I think this is right — is that we are at the same kind of pivot point with agentic AI that we hit with cloud computing around 2010 or with mobile around 2008. Not "useful new tool." A reorganization of how work gets done. The companies that figured out cloud-native architecture early ate the lunch of the ones who treated AWS like "rented servers." The same split is starting now with agentic versus task-level AI.

And nowhere is that split more visible than in retail.

Agentic Commerce and the Quiet Death of the Click

Here is a number that should make every e-commerce founder pay attention. eMarketer projects that AI-platform-driven e-commerce will hit roughly $20.9 billion in 2026 — about a 4x jump from 2025. McKinsey is calling for agentic commerce to generate $1 trillion in U.S. retail revenue by 2030. Morgan Stanley thinks nearly half of online shoppers will be using AI shopping agents by then, accounting for about a quarter of their spend.

Translation: a meaningful percentage of your future customers will never see your landing page. They will tell an agent what they need. The agent will buy it.

This is what people mean by "zero-click commerce," and it's already showing up in traffic data — search engine traffic to brand-specific destinations is down roughly 25% heading into 2026, with a clear migration toward GenAI channels like ChatGPT, Perplexity, and Gemini doing the discovery and (increasingly) the transaction layer. Around 70% of consumers say they are at least somewhat comfortable letting an AI agent make purchases on their behalf. 45% are already using AI assistants for product ideas. 13% have actually completed a purchase through one — and that number is the canary, not the ceiling.

I'll come back to what this means for the way you build product pages — there's a specific, ugly implication for SEO that I think most teams haven't priced in. But first, the framework itself, because the framework is what tells you whether you're building something that survives this shift or something that dies in it.

Google's Four-Stage Framework, Tested Against Real Projects

The framework has four stages: Discover, Design, Build, Scale. That sounds suspiciously like every other consulting deck I've seen. It is not. The substance inside each stage is where it earns its keep, and the order matters more than people will give it credit for. I'll walk you through each stage the way Clara structures it in the course, and then I'll tell you where I think it bends in practice.

Stage 1: Discover — The "What If" Mindset Shift

The Discover stage is mostly cognitive. The thesis is that most enterprises walk into AI thinking "as-is" — meaning they look at their existing process and ask, "Where can we slot AI in to make this faster?" That question has a ceiling, and the ceiling is low. You end up with a faster version of the same process. Forty-minute task becomes a twelve-minute task. Nice. Not transformative.

The "what if" mindset asks a different question. It says: if we had a tireless, reasonably intelligent system that could observe, decide, and act across this entire end-to-end process, what would the process even look like? You stop optimizing the steps and start asking whether the steps need to exist at all.

I tried this exercise with a client onboarding workflow I'd been "AI-ifying" for a small SaaS. As-is thinking had me building an agent that drafts welcome emails. What-if thinking asked: why is there a welcome email at all? The reason it existed was to manually walk a new user through setup. If an agent can detect a new account, watch the user's first session, and proactively offer help inside the product when they hit friction — there is no welcome email. There is no setup guide. There is no help center ticket about "how do I get started." The entire shape of the onboarding changes.

That is the gap between as-is and what-if. And the discomfort of that gap is the actual deliverable of stage one. You are supposed to leave it slightly disoriented. If you leave it with a tidy list of "places to put AI," you did it wrong.

Stage 2: Design — Value Engineering and Critical User Journeys

This is the stage that I think is the actual jewel of the framework, and it's the one most underplayed in the discourse around agentic AI. Stage two does two things: it forces you to quantify the business value of every potential agentic project before you build, and it makes you map the Critical User Journeys — the CUJs — that the agentic system has to navigate.

Value engineering, in plain language, is the discipline of refusing to build the next AI thing until you can answer three questions: what specifically does this change for the business in dollars or hours, who is the human responsible for that outcome today, and what happens to that human's job when the agent does it well. If you cannot answer all three with specifics, the project goes back into the queue. It does not get prioritized because someone in the leadership offsite said the word "AI" with conviction.

I want to be honest — this is the stage where I have personally been the worst offender. I love building. I will rationalize the value after the fact. The framework correctly assumes that most of us will, and it bakes the discipline in before a single line of code gets written.

The Critical User Journeys piece is the operational complement. A CUJ is not a feature list. It is the specific path a real human (or a real agent on behalf of a human) takes to accomplish something that matters. You map the journey, mark every decision point, every data dependency, every place where the current process breaks down or hands off to another system. Then you ask which of those steps an agent could own end-to-end and which still require a human in the loop.

The reason this matters is that most "agentic" projects fail not because the model is dumb but because nobody mapped the journey. The agent gets stuck at step 4 because step 3's data lives in a system the agent cannot reach. Or step 6 requires an approval that nobody documented. Or the handoff between the agent and the human happens through a Slack channel that one specific manager monitors but nobody else does. CUJ mapping surfaces all of that before you build, which is roughly 200x cheaper than discovering it after.

Stage 3: Build — No-Code Prototyping with the Right Tools

Stage three is where it gets fun, and where Google is making a fairly aggressive bet. The framework's position is that the prototype should be built by the cross-functional team that mapped the CUJ — not handed off to an engineering team to interpret. The whole point of using no-code tools like Google AI Studio and Gemini Enterprise at this stage is to keep the people closest to the process in the driver's seat while the system takes shape.

This is the part of the course aimed squarely at AI product managers — the explicit framing is that a PM should be able to build a working agentic prototype without filing a single engineering ticket. I have mixed feelings about this. On one hand, I have watched far too many enterprise AI initiatives die in the gap between a PM's spec and an engineer's interpretation of that spec. Letting the PM build the prototype directly closes that gap, and the speed-up is real.

On the other hand, no-code prototypes have a habit of becoming production systems by accident. The thing built in three days "to prove the concept" gets demoed to leadership, leadership loves it, and suddenly it is running in production with all the architectural rigor of a Saturday afternoon hackathon. I have seen this happen with Zapier workflows, with Bubble apps, with Notion automations. There is no reason agentic AI prototypes will be exempt.

The framework's discipline around stage three is what saves it. Prototypes are explicitly scoped as throwaways — proof of concept, not production. The point of the stage is to validate that the CUJ holds up when an agent actually runs it, that the value engineering numbers were right, and that the human handoffs work. Once that is validated, you graduate to stage four, where the actual production system gets built with the architecture, security, and observability that production demands.

Stage 4: Scale — The Stage Nobody Wants to Talk About

The course is honest about something: stage four — actually scaling and operationalizing agentic systems across an enterprise — is the stage with the least mature playbook. Everyone is still figuring it out. The companies who have done it (and there are not that many yet) treat it as a multi-quarter program involving platform teams, governance frameworks, agent observability, and a clear policy for when an agent's decision authority gets escalated to a human.

The two characters Clara uses to make this concrete are Beth, the Head of Strategy at a fictional retail chain called Symbol Mart, and Tomo, the technical leader. Beth's job is to keep the agentic transformation aligned with business value and to make sure the prioritized projects actually move the metrics they were supposed to move. Tomo's job is to make sure the systems that get built are secure, pragmatic, and scalable enough to survive the move from prototype to enterprise deployment.

The pairing matters. The reason most agentic AI initiatives fail at stage four is that they are owned exclusively by one of those two people. Beth-only leadership produces beautiful slide decks and prototypes that never scale. Tomo-only leadership produces robust systems that automate things nobody actually needed automated. The framework's central operational claim is that the stage-four success rate is a function of how tightly those two roles are coupled across the entire transformation.

That is the framework. Now let me tell you where I think it bends.

What Actually Works, and What I Think Is Overengineered

I want to be careful here, because it is easy to read a Google framework and either bow to it or dismiss it. Both reactions are lazy. Here is what I actually think after working through it.

The Discover-stage mindset shift is the most important piece, and the easiest piece to skip. Almost nobody does it properly. Almost everyone walks into agentic AI carrying the as-is process model and slotting agents into the existing steps. The cost of skipping the what-if exercise is that you spend a year building agents that make a doomed process slightly faster.

The Design-stage value engineering discipline is the piece I am stealing wholesale and applying to my own work, including projects that have nothing to do with agentic AI. The principle generalizes — quantify the value before you build, name the human whose work changes, and refuse to greenlight the project until you can do both. I will probably write a separate post just on this, because it deserves it.

The CUJ mapping is correct in spirit and slightly heavy in practice for anything below the enterprise scale. If you are a five-person startup or a solo builder, you do not need a formal CUJ document. You need to walk through the workflow on a whiteboard and mark the handoffs. The framework's formality scales with the size of the organization. Use the principle, scale the artifact.

The Build-stage no-code emphasis is right for prototypes and dangerous for production. Treat it accordingly. The prototype gets built fast in Google AI Studio or Gemini Enterprise or whatever your stack is. The production system gets built with a real engineering process. Do not let the demo become the deployment.

The Scale stage is where the framework is honest about its own limits, and I respect that. Nobody has a playbook for enterprise-wide agentic transformation yet. What the framework gives you is the right organizational shape — the Beth and Tomo pairing, the value alignment, the technical pragmatism. The specifics, you will have to figure out by doing.

The thing the framework does not say out loud, and probably should: a meaningful number of these transformations are going to fail. Not because the framework is wrong, but because the organizational change required to act on it is genuinely hard. Letting an agent own an end-to-end process means somebody's job changes. Sometimes that change is enrichment — they move from doing the work to supervising the system. Sometimes it is elimination. The framework is a strategy document, not a change management document. You will need both.

What This Means If You Are Building Right Now

If you are a developer, the most useful shift is to stop asking "what task can I automate with an agent" and start asking "what process can I hand to an autonomous system." Different question, different architecture, different value ceiling. The agents you build under the second question are worth roughly 10x the ones you build under the first, in my experience.

If you are a product manager or a founder, the value engineering discipline is the highest-leverage practice you can adopt this quarter. Before you greenlight the next AI feature, write down in one paragraph: what specifically changes for the business when this works, who is the human responsible for that outcome today, and what happens to their work when the agent does it well. If you cannot write that paragraph, the feature is not ready to be built.

If you are running an e-commerce business, the agentic commerce shift is not a 2030 problem. It is a 2026 problem. The fact that 70% of consumers are comfortable with agent-driven purchasing means the buying agent that lives inside ChatGPT or Gemini is going to be deciding whether your product even shows up in the consideration set, long before the customer ever types your brand name. That has implications for product data structure, for API accessibility, for how you describe your products in machine-readable ways. If you are building today's product page for tomorrow's human shopper, you are building for a buyer who is being quietly replaced.

If you are an enterprise leader, the Beth-and-Tomo pairing is the part to internalize. Find your Beth. Find your Tomo. Make them co-own the transformation. If either one is missing or sidelined, the program will produce something — slide decks or systems — but it will not produce transformation.

A Note on the No-Code Promise

There is a piece of the course's framing that I want to push back on gently. The promise that AI PMs can build production-quality agentic systems without engineers is, in my honest assessment, partially true and dangerously seductive.

The partially-true part: PMs absolutely can build prototypes that prove the CUJ, validate the value, and demonstrate the workflow. That is real, and it is a meaningful unlock. The dangerously-seductive part: the gap between a working prototype and a production system that handles security, scale, error recovery, observability, compliance, and the edge cases that show up at hour 73 of continuous operation is enormous. That gap is where engineering lives. No-code does not close it. It makes the prototype faster, which is great. Treat it as that.

The right way to read Google's no-code emphasis is not "engineers are no longer needed for agentic AI." It is "the prototyping phase no longer needs to wait on engineering capacity, which means more ideas can be validated faster, which means engineering capacity gets spent on the prototypes that proved their value." That is a much smaller claim, and it is the one I think actually holds up.

What I'm Doing Differently This Week

Going back to the Sunday morning argument I started this with — the one where I realized I had built seven agents and zero workflows — I spent yesterday redesigning one of them.

The competitor pricing scraper is becoming a competitor pricing system. It still pulls the data. But now it reasons about whether the gap matters given our margin floor, drafts a proposed pricing move, sends a one-line approval request to me with the reasoning attached, and on approval pushes the change and watches conversion for 72 hours before either holding or reverting. The work I used to do — looking at the data, deciding, executing, monitoring — is now scaffolded by the system. My job is to approve or reject the proposed move. That is a process, not a task.

It took me about four hours to redesign it. It will save me, I estimate, four hours per month forever. The agent version saved me forty minutes a week. The workflow version saves me half a day. Same model, same data, same tools — different question asked at the design stage.

That is what the framework is actually for. Not for writing better slide decks about AI strategy. For getting you to ask a different question at the moment when the entire architecture of what you build is decided.

Pick one thing this week that you've already "AI-ified" as a task. Ask the what-if question about it. Ask whether an agentic system could own the whole process instead of one slice of it. If the answer is yes, redesign it. If the answer is no, ask why — because that "no" usually points at the actual constraint, and the actual constraint is usually a human handoff that nobody bothered to map.

That, more than any framework, is the move.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io