It is no longer a question of whether to use it

Entering 2026, the context of discussions about AI has changed. Earlier, everyone was still arguing about whether tools could be used and whether they should be used; now many people around me have already started running their own Agents, Skills, or automated orchestration. Ready-made workflows are everywhere, but they also easily create an illusion that getting an exquisite template means the problem is solved, while overlooking that copying steps does not equal acquiring capability.

Industry data confirms both the surge in supply and the gap that remains. A Microsoft report published in 2026 notes that the number of active agents in its ecosystem grew 15-fold year over year; but the report also stresses that the breadth and depth of agent deployment vary widely across industries and user groups, and this should not be taken as full adoption. Meanwhile, an August 2026 OpenAI study of its enterprise customers shows that AI is accelerating toward executing concrete work: as of June 2026, among its enterprise customers, output tokens generated by Codex accounted for 64% of the combined output tokens of Codex and ChatGPT. In practice, deployment depth varies greatly. Leading approaches typically connect agents to their own business context and specialized tools; generic prompt templates struggle to meet specific business needs. It is precisely this variation in depth that causes copying others' processes to start hitting walls. As execution-level supply becomes ever more abundant, the confusion becomes more concrete: tools are always available and ready-made processes are easy to obtain, so why does following someone else's steps still fail to produce the desired result?

Little Rice Ball holds a pencil, thinking about choosing between two branching AI workflows.

Where does copying go wrong?

Starting from someone else's ready-made steps is entirely reasonable. Copying lets people quickly see how a complex task is broken down, and most people build their intuitive sense of agents this way. But copying often hits walls, because workflows are highly local: they grow out of specific material, cognitive, and responsibility conditions.

On material conditions, the original author's process is by default tied to their particular toolchain, data fields, and permission boundaries. Interfaces they can call smoothly may not connect in your environment; their raw data is tidy, while once your data has gaps, the automation chain throws errors and ultimately degrades into manual patching. On cognitive conditions, processes serve specific goals and contexts. Information the author omits from instructions relies on long-accumulated business background; where they stop to review and on what basis they judge a result unacceptable rests on professional experience not written into the process. Responsibility conditions are the hardest to transfer. What standard a deliverable must meet to pass, and who bears the consequences of errors, determine which steps must be checked by a human; responsibility cannot be transferred along with someone else's flowchart.

This local constraint is equally clear at the industry level. A 2026 assessment of 36 service providers by professional research firm HFS and KPMG points out that scaling agentic AI depends on process redesign, clear decision rights, and business context; the vast majority of deployments still retain human oversight, and the difficulties are concentrated mainly in operational design. Analogizing the professional research firm's assessment of service providers to the level of personal workflows, my analysis is: what determines whether a process can run is mainly your personal context and responsibility boundaries. Executable actions are increasing: the second edition of Salesforce's 2026 report shows that among its enterprise customers who continuously use the product, the average number of activated agents rose from 5 to 13, and each agent's business actions rose from 2 to 6. As the scope of actions expands, the design of gatekeeping and accountability becomes even more important. As OpenAI points out in its enterprise research, turning effective individual experience into organizationally shared practice likewise requires reworking permissions, review, and governance. Those local supports that fade into the background are precisely the parts that cannot be directly carried over.

Little Rice Ball places a process puzzle piece into their own gap, beside a ready-made process made up of documents, permissions, and manual checks.

What is truly worth learning?

Since others' specific steps and parameters cannot be directly applied, what should we look at when learning from others? Many people habitually collect others' prompts, tool lists, or execution steps. But these are results the other party produced under specific data, software, and permission constraints. Someone else's answer easily fails in your business, and repeatedly spending effort tweaking those words and phrases often leads to pointless exhaustion.

What is worth learning is how the other party breaks down tasks and where they set judgment points. When looking at a mature workflow, first look at how the other party splits a complex task into independent steps, and which steps they keep in their own hands. Following the execution chain downward, there are real business considerations behind where they stop for manual verification, what standard they use to judge output unacceptable, and on what basis they decide to intervene. How context is distilled and passed on during human-machine handoff is also a matter of great nuance. Specific instructions are merely the way of writing an answer to one particular question, whereas the thinking behind task decomposition, boundary setting, and quality gatekeeping remains useful across different kinds of work.

In Microsoft's 2026 report, the emphasis that advanced users place on these steps is also visible. The report compared two types of users: on the behavior of "discussing quality standards," the proportion of advanced users separately identified in the report was 54%, compared with 29% for ordinary users. The report also shows that these people more often work with their teams to sort out business processes and record how handoffs between agents and people work. It must be noted that this is a group comparison in Microsoft's survey, reflecting a correlation in group behavior, and cannot be treated as a causal conclusion. What this correlation shows is the fact that those who are ahead put their energy into sorting out processes, discussing quality standards, and recording handoffs. They also often look back at their workflows, reassess which steps are handed to agents and which are done by people, and continuously adjust their processes in daily work. Only by seeing clearly how others set checkpoints in complex tasks and drawing on this approach to handling problems can one better respond to the actual conditions at hand.

Start with one part of your own process

When exploring your own workflow, the starting point should be restrained enough. You can first pick out a specific step that must be handled every week, whose quality is obvious at a glance, and whose consequences of error are easy to bear. Avoiding a huge and complex full loop is because bottlenecks in a short process are clear at a glance, the cost of troubleshooting is low, and the effect is easy to verify.

Within this local part, drawing on others' experience only requires extracting the ideas of breaking down tasks and setting judgment points, and then rewriting the steps using the software, real data, and actual permissions you currently have. The standards should also be changed to the delivery requirements you face. If the whole chain runs through and at every pause point you can clearly state why you must take a look yourself, the transformation is complete. As for whether to expand the scope of agent involvement later, that depends on the output quality continuously measured in practice and on risk tolerance; retaining human checkpoints is always a necessary practice for preventing delivery risks. Recording the transformed process is itself very valuable: only by clearly writing down the process steps, the places where humans and machines hand off, and the quality standards adopted can this process be repeatedly used and adjusted, and only then can it in turn be shared with others.

Little Rice Ball uses a magnifying glass to inspect the short process he built, with documents and a permission key placed nearby.

This article does not include a ready-made template. A workflow that can stably deliver results needs to be explored on real data being processed, is constrained by the system permissions actually held, and gradually takes shape through repeated manual checks and actions that take responsibility for delivery consequences. The actual conditions of different teams and individuals vary greatly, and there is no one-size-fits-all solution; the starting point can only fall back to the specific process you are currently working on.

References