Why I Split AI Work Into Four Steps Before Choosing Tools

A model’s name alone can’t explain how you actually work

If you trace back a day when you got something done with AI, you’ll usually find yourself moving across several tools. You search for material, sort out what’s actually needed, switch to another tool to change a file or write code, and then check the result. And yet, when someone asks “which AI do you use,” we try to answer with a single company name.

I’ve found it helpful to break this process into four stages when choosing tools: discovery, coordination, execution, and verification. These four stages are a distinction I made up to examine how work actually happens. It doesn’t mean every task follows this exact order, or that you need to buy a different product for each stage.

Knowing where the work is actually getting stuck lets you talk concretely about what needs to change. An organization that spends too long finding source material and an organization with no clear standard for reviewing results will get very different results from adding the same tool.

In usage studies, humans plan more and agents execute more

In a June 2026 report, Anthropic analyzed 400,000 Claude Code sessions created by roughly 235,000 people between October 2025 and April 2026. Classifying the conversation logs by model, the firm found that about 70% of planning decisions were attributable to humans, while about 80% of execution decisions were attributable to Claude. How Claude Code is used in practice

Here, planning means deciding what to build and what counts as done. Execution means choosing which files and code to modify and which commands to run. Even within a single conversation, the two roles stay clearly divided.

The “expertise” the study talks about isn’t a job title either — it’s how well someone understands the task at hand. Anthropic classified this based on the precision of instructions, the kinds of confirmations requested, and how users corrected the agent’s mistakes. As the report puts it, an accountant who doesn’t know a coding language can still be an expert on a task if they can precisely specify reconciliation rules and exceptions.

Sessions classified this way as beginner-level had a “verified success” rate of 15%, while intermediate-and-above sessions scored 28-33%. This means the model judged the outcome a success and found supporting evidence, such as passing tests or explicit user confirmation. It is not a success rate measured by whether companies actually adopted the output, or whether it moved revenue or costs.

So these figures can’t be generalized into a measure of AI performance across every profession, or treated as causal evidence about education. Still, what stood out to me is this: knowing and being able to articulate the standards of your own work may give you an edge in directing an agent.

Breaking work into four stages makes it easier to spot the missing roles

Here’s the breakdown I use.

Stage	Question to ask	Functions and roles needed	Output to leave behind
Discovery	What do we need to know?	Search, research, source verification	Candidate materials and evidence
Coordination	What order and scope should this follow?	Planning, tool integration, assigning authority and ownership	Execution plan and permitted scope
Execution	What actually gets changed?	Writing files, changing code, processing work-system tasks	Documents, code, tickets, etc.
Verification	Does the result match what was asked for?	Testing, review, approval, error handling	Grounds for judgment and records of fixes/recovery

At the discovery stage, having a lot of material isn’t enough on its own. It has to be relevant to the work at hand, current, and traceable to a verifiable source. If it’s internal company data, access permissions and whether information is missing also matter.

At the coordination stage, you need more than just connecting tools — you need to assign responsibility. That means deciding what information to base judgments on, who reviews the plan, and which actions require approval before execution.

At the execution stage, actual state changes. Files get saved, tickets get modified, and depending on the case, orders or external shipments can be triggered. This is where you need designs that reconfirm outcomes and prevent duplicate execution.

Verification isn’t something done just once at the end. You can check sources when selecting materials, review targets and scope before execution, and inspect results after execution. If a problem turns up, you can also go back to an earlier stage.

For instance, if you’re drafting a notice for a new product, you can separate out the tasks of finding pricing and terms, defining the target audience and permissible wording, drafting the copy, and reviewing it for factual accuracy and potential for misunderstanding. Even if a single tool performs all of these, the roles themselves still remain.

Just because earlier research distinguished planning from execution doesn’t mean these four stages have been statistically proven. The point of my breakdown is to identify, side by side, what tools are already good at and what the organization hasn’t yet decided.

Connectivity Standards Handle Different Jobs

Google’s March 2026 developer guide uses a restaurant’s food-ingredient ordering process as an example to explain the role each standard plays. It makes clear that inventory lookup, communicating with suppliers, placing orders, approving payment, and displaying information on screen are all distinct problems. Developer’s Guide to AI Agent Protocols

Standard	Role in the Guide
MCP	Connects to tools and data to look up things like inventory
A2A	Discovers other agents and exchanges quotes, quality, and shipping information
UCP	Exchanges product, order, and checkout information in a defined format
AP2	Links records that prove who authorized a purchase and under what conditions
A2UI	Represents the layout and data of the screen an agent will present
AG-UI	Delivers an agent’s progress status and messages to the screen

These standards aren’t six competing products vying for the same job. Nor does a single ordering process necessarily require adopting all six. They’re an example of how you combine them to fit your current system and the functions you need.

Having a payment-approval record doesn’t mean the actual payment and order both succeeded. You need to check the order-completion status and the payment result, and decide in advance how to handle failures. A standard provides an agreed-upon way to exchange information, but it doesn’t guarantee the outcome of the task itself.

MCP is a project contributed to the Linux Foundation’s Agentic AI Foundation in December 2025. This means multiple parties are jointly developing an open standard—but it doesn’t mean tools and data used with one company’s product can be moved directly to another. Linux Foundation’s explanation of MCP and AAIF

In practice, you need to look beyond whether a standard is supported. You should check whether the functions you need are provided in the same way, whether authentication and permissions carry through, and whether errors and intermediate states can be interpreted. A single “MCP supported” badge isn’t enough to conclude that the integration work is done.

What to carry over when you switch tools

Even when a better model comes along, replacing your product outright isn’t always easy. Conversation history, user training, and existing workflow integrations can all become sunk costs. I pay particular attention to the following four items.

First, where outputs and history get stored. Check which drive your documents live on and which repository logs your code changes. The fact that something sits on a vendor’s server doesn’t automatically mean you don’t own it or can’t export it. You need to verify contractual rights, export formats, and how much version history actually transfers—separately, each one.

You might only be able to export the current file, with edit history or comments left behind. Or, conversely, you might set things up so outputs land in your organization’s own storage and multiple tools work off it in sequence. You have to first decide what context the next task actually needs before you can judge how portable things really are.

Second, access permissions. Getting a new tool to reach the same data and systems may require redoing authentication, organizational policy, and security review. You also need to check whether permissions actually get revoked when you cut off the old tool. Swapping the model and re-authorizing system access are two separate line items—calculate them separately.

Third, evaluation cases and grading criteria. Your organization needs to own the questions it actually gets wrong often, the range of acceptable answers, and the pass conditions. The point is to check whether those criteria can be exported outside the product and run or reviewed in a new tool. Even with records in hand, a different execution environment can still cost you money to adapt your evaluation tooling.

Fourth, differences between connection specifications and implementations. Using an open specification creates common ground you can build on. But vendor-specific features or version discrepancies can still demand separate work. Don’t conflate “the spec is open” with “switching is cheap”—they’re distinct claims.

If your organization manages these four items well, there’s real room to cut switching costs. That doesn’t mean migration happens in a matter of days, though. Revalidation, retraining, and recovery costs remain even when all four items are in place.

One product or several connected tools — it’s still a cost question

When you break work into four stages, using several products for each can feel like the obvious answer. But every connection point you add is also a place where things can break — and a permission you now have to manage. It can also get harder to trace where the data actually changed.

If a single product carries you from data exploration through execution to review, you cut down on the cost of handing context off between tools. On the other hand, if one particular stage is mission-critical, a dedicated tool built for that function can genuinely help. My view is that you have to weigh stage-by-stage performance against total operating cost together.

Say search quality is already good enough, but work stalls because there’s no execution permission — adding a new model won’t fix that. Conversely, if you keep missing the evidence you need, the problem is your data access and search method, not execution speed. And if the output looks great but nobody ever decides whether to actually adopt it, what you need first is an owner and a review standard.

The four-stage breakdown exists to separate these problems from each other. It’s not a classification meant to multiply the number of products you use — it’s one meant to reveal where the same failure keeps recurring.

Oswarld’s Lens

When people talk about adopting a tool, I notice the conversation gravitates toward model scores and response speed. I agree those are important comparisons. But that framing alone doesn’t answer where the output actually accumulates, who gets to decide it’s usable, or whether you can migrate to a different tool later.

What I kept coming back to in this usage study was the definition of expertise. Regardless of job title, what matters is how well someone understands and can articulate the standards for a given task. Even when an organization has real knowledge, if it only lives in one person’s head, it’s hard to hand off enough of it to an agent.

That’s why I think it matters to pull those standards out into sentences and examples: what not to do, what the exceptions are, what the output should be compared against. Those sentences alone don’t make a finished evaluation set, but combined with examples and a judging method, they become material you can review repeatedly.

Even with code, passing tests doesn’t confirm every dimension of quality. Strategy or writing requires even more judgment calls. But even in these areas, you can still record whether the reasoning holds up, whether the requested constraints were honored, and who adopted the result and why. You don’t need perfect automated grading to make your review criteria explicit.

In a past issue, I wrote about the gap between Google’s follow feature and actual measurement data. Being able to use a connection feature is a different matter from actually securing the usage records you need. I think the same logic applies to AI tools: you need to check what kind of records the organization can actually keep and use for its next decision.

When I choose a tool, what I care about most is whether we can preserve the material needed to judge the results and inform our next choice. You need to record which step took too long, why something failed, and whether the fix actually improved the outcome — only then can the next adoption decision or contract renewal be discussed concretely.

💬 Among discovery, adjustment, execution, and verification, which stage are you getting stuck at most often right now?

References & Further Reading

• Anthropic, How Claude Code is used in practice, June 16, 2026
• Google Developers, Developer’s Guide to AI Agent Protocols, March 18, 2026
• Linux Foundation, The Relationship Between MCP and AAIF, January 12, 2026

Read together: Designing Verification Work and Ownership · Google’s Follow Feature and the Metrics Behind It

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.