A Workflow Is Not a Collection of App Clicks

An AI-native workflow should preserve the context of a decision, not merely complete a sequence of clicks. Someone leaves a productive customer meeting, gets into a taxi and calls a colleague. The opportunity is moving forward. A concern has been resolved. There is a new commitment and perhaps a change to what the customer needs. The conversation was good, and the person responsible knows what to do next.

Somewhere else, the CRM still says that nothing happened.

I have encountered versions of this problem across product leadership and consulting. People are asked to enter hours, move opportunities through stages, complete forms, and update dashboards. Each request has a perfectly reasonable purpose. The person who needs accurate information for planning, analysis or compliance is not being unreasonable. Neither is the person who has just spent ninety minutes with a customer and wants to preserve the actual relationship rather than immediately reconstruct that meeting in five applications.

What interests me about an AI-native workflow is not whether an agent can click those five buttons faster. It is whether we can stop forcing the person closest to the work to act as the integration between what happened, what the organization knows, and what needs to happen next.

A workflow is not a collection of app clicks. It is the continuity of an objective through changing context, decisions, people and systems.

The awkward distance between doing the work and recording it

Consider time tracking. In software product environments, customers want their employees to record hours because they intend to learn something from the data afterwards: utilization, profitability, project progress, capacity or the commercial health of an engagement. In consulting, I have also been on the other side, with reminders and yellow flags waiting when I had not entered my hours.

There is nothing irrational about either perspective. The problem is that the data-collection moment is often detached from the moment when the relevant work took place. Recording becomes a second task, competing with the first. If the entry is late, the memory becomes less reliable; if it is forced too early, the administrative work interrupts something more valuable. Improving the time-entry screen does not necessarily change that tension.

The same thing happens in sales. After a client meeting, the most important information may be a change in the customer’s priorities, an unspoken concern, a relationship opportunity, or a promise to investigate a particular solution. The CRM, reasonably enough, wants a stage, next action, amount and expected date. Those fields are useful representations of the opportunity. They are not the opportunity itself.

We have built organizations in which one group produces information and another group consumes it through reports and dashboards. Both jobs matter. Yet we routinely assume that information will cross between them because the people doing the work will have sufficient time, attention and discipline to translate it into the system’s preferred format.

That assumption has always been fragile. The interesting opportunity is not simply to automate the translation. It is to make the context flow continuously enough that the people making the next decision begin from something close to what actually happened.

What an AI-native workflow should do before a decision

Imagine a customer requesting an exception to a contract. A familiar workflow might begin with a ticket, a CRM note and several approvals. The request will be passed to the person authorized to decide, who may receive a link to the current policy and a short explanation of the commercial circumstances.

In a better process, the preparation is not limited to attaching the latest document someone happened to remember. An authorized AI assistant could search the relevant knowledge base, identify the current policy, check its effective date, compare it with documented precedents and look for contradictions. It could review product-roadmap information that might change the commercial question. It could tell the decision-maker which information is missing and what source supports each finding.

A generated briefing is not automatically a correct briefing. If an assistant retrieves an old exception policy and presents it as current, the system has merely made the wrong information faster to consume. The useful design is one that checks provenance, currency, conflicting documents, access rights and uncertainty, and shows where the evidence stops.

The decision-maker may then learn that the customer wants an exception for something the product team already plans to deliver. Perhaps granting the request would create a precedent that other customers could reasonably demand. Perhaps an older internal note points one way while a newer, approved policy points another. None of these considerations guarantees an answer. They make a better question possible.

In the language of organizational context for AI agents, the assistant needs more than a task brief. It needs enough of the surrounding organization to recognize what the task touches. And in the language of AI delegation and success criteria, that context must come with an explicit limit on what the system can decide.

This is consistent with Anthropic’s discussion of trustworthy agents: useful systems need meaningful human control over tool access and consequential actions, not a vague promise that someone can intervene if something goes wrong.

A completed step is not a completed outcome. The next person must inherit the decision, not just the status.

The exception is precisely where human judgment earns its place

The person authorized to grant the exception may know something important that will never appear in the policy archive. This customer may be preparing for an IPO. There may be an attractive sister company in the group. A relationship built over several years may create strategic options that do not fit a pricing or approval checklist. Or the request may simply be one the company should decline, regardless of how neatly the commercial arguments can be arranged.

AI should not pretend that those considerations are absent because it cannot find them. Nor should it invent them to fill the gap. Its contribution is to make the recorded facts, relevant options, contradictions and unanswered questions available to someone with the authority [and the broader judgment] to decide.

I am deliberately describing an authorized assistant here. It should not treat everything it can technically retrieve as permissible to use. Commercial sensitivity, customer confidentiality, document permissions, retention rules and the integrity of the source material are part of the workflow itself. NIST’s AI Risk Management Framework describes governance, context, measurement and risk management as connected activities rather than independent boxes to check after deployment.

An organization that takes those controls seriously need not choose between unrestricted automation and permanent paperwork. The more demanding option is to define which information may be assembled, which actions may be prepared, which must be approved, and how the decision remains explainable afterwards.

Notice what we have not done. We have not built a robot that clicks through a contract exception form on someone’s behalf. We have designed a better preparation process for a decision that still belongs to a person.

The more neglected opportunity is what happens afterwards

Now the manager grants the exception. The customer is informed. Everyone leaves the call satisfied. If the story ends there, we have solved only half the problem.

What does the account team know tomorrow? What happens when the same customer calls another colleague? Does the next service representative see that the exception was approved, why it was approved, what its boundaries are, and whether it has an expiry date? Can the organization distinguish an exception that should remain exceptional from a signal that its standard offering needs to change?

I once discussed a very similar pattern around a technician visiting a building to complete a repair. After the visit, the technician’s natural habit may be to telephone the colleague who arranged the job. The repair went fine, a common replacement part was consumed, more stock should be purchased, and a particular instruction manual proved useful. The call has all the information the organization might need. Yet unless somebody translates the conversation into a work order, inventory request and maintenance history, much of it remains trapped in a conversation.

That is where I find the next generation of AI-supported workflows particularly interesting. With the participants’ knowledge, appropriate recording permissions and approved systems, an assistant could help turn the technician’s ordinary debrief into a proposed service record, parts request and follow-up. The technician could correct it; sensitive or ambiguous details could be held for review. The organization could then preserve a useful account of what happened without demanding that the technician become a part-time database administrator.

The same idea applies to the customer exception. The decision should become a durable, discoverable record linked to the relevant customer, policy, commercial arrangement and follow-up obligations. The resulting record can inform the next person who speaks to the customer. It may also reveal that the policy needs revision, or that repeated exceptions are becoming a product or pricing problem.

That is a bigger ambition than voice-to-text. Transcription can capture words. A useful AI-native workflow must interpret their operational meaning, propose updates to the correct systems, preserve provenance, handle disagreement and ask for confirmation where necessary. It should not silently infer a binding decision from an informal remark.

In my own Open Source Consulting work, I have begun addressing pieces of this problem in a deliberately smaller way. Meetings are recorded where appropriate and analyzed afterwards because I do not want to choose between being present in a ninety-minute conversation and reconstructing its first fifteen minutes from memory. An opportunity update can begin with a few spoken observations rather than an evening of manually reconstructing the CRM. The assistant can use earlier context and the next required steps to suggest what should change. I still validate consequential records and decisions. This is a working experiment in a personal environment, not proof that the same arrangement can be dropped unchanged into a large enterprise.

Why one shared organizational memory does not mean one giant database

When I describe this direction, I sometimes think of the company as needing a central brain. That metaphor is useful, provided we do not take it literally.

The ambition is not to pour every confidential document, product roadmap, HR record, customer conversation and service ticket into one unrestricted repository. Nor is it to declare one vendor’s AI assistant the definitive authority on everything the company knows. Data ownership, access rights, retention and system-of-record responsibilities still matter, particularly when a record is legally or commercially consequential.

What we need is a way for the relevant organizational knowledge to become available in context, at the point where a person or an authorized system needs to act. Different sources may retain different owners. The assistant may retrieve approved passages, check versions, carry references forward and distinguish a verified record from a provisional inference. The point is continuity of meaning, not physical centralization.

The limits of human memory are exactly why this matters: a technician, seller or product leader cannot be expected to remember every revision of every instruction, every precedent, and every unresolved commitment across an organization. The breadth of potentially relevant information quickly exceeds what one person can hold in working memory. AI can help with that retrieval and synthesis, but only when the underlying information is maintained and the system is prepared to admit what it does not know.

There is a useful warning in Anthropic’s distinction between predetermined workflows and more autonomous agents. A series of reliable, explicit steps may be the better design for ordinary updates. More dynamic reasoning is justified when the work really needs judgment about what to search or do next. Greater autonomy is not intrinsically greater value.

Put differently, the operating layer above the applications must not become another opaque application that everyone is expected to trust on sight.

A practical test for one broken handoff

None of this requires a company-wide transformation program to begin. I would start with one point at which people repeatedly have to move information from the way they naturally work into the format a system demands. Choose a handoff where the pain is real, observable and consequential.

Those five questions are a proposed operating test, not an established industry framework or proof of ROI. The point is to run a small, reversible experiment before investing in a large architecture. It is very much aligned with OSC’s preference for assessing the value hypothesis before transformation investment.

Don’t make the people who feel the pain fight the people who own the controls

There is another reason these problems survive. The employee who experiences the broken handoff is often not the person who can authorize a new connection, approve an AI tool, license a platform or define the acceptable information-security boundary.

It is easy to turn that into a story about unhelpful gatekeepers. I understand the frustration. Someone who has just watched half a day disappear into re-entry and follow-ups does not particularly want to hear that a procurement or security process is functioning exactly as designed. But information security, licensing cost, data stewardship and operational support are real concerns. The solution is not to declare them irrelevant.

I would rather bring both sides to the same table and ask them to design a better outcome. The employee can explain what is broken and why the existing process is costly. The security or operations colleague can make the constraints explicit and help shape a safe experiment. AI makes it increasingly possible for the person closest to the problem to prepare a credible prototype, an illustrated alternative process or an evidence-backed business case without first becoming a specialist in every adjacent discipline.

That democratization is part of what I mean when I talk about people becoming business builders. It does not mean every employee becomes an entrepreneur or can unilaterally rewrite policy. It means more employees can formulate and test an improvement hypothesis, understand trade-offs and participate meaningfully in designing a better business.

There is a cultural question underneath this. If one group is rewarded for throughput, another for compliance, and nobody for the customer’s actual result, collaboration will require more than a demonstration. I would want to show the cost of the broken handoff in terms that both groups regard as legitimate, not merely deliver a more persuasive slide deck.

That broader challenge belongs in the operating-model conversation. The Micro-level action is simpler: take one disputed handoff, let the people involved define what good would look like, and test whether a bounded AI-supported process can improve it without sacrificing the controls that matter.

The test is what the next person knows

Microsoft’s 2025 Work Trend Index describes fragmented working days and growing interest in agent-supported work. Those findings do not tell us whether any particular AI workflow will succeed. They do help explain why endlessly adding applications and reminders is an increasingly unsatisfying response to coordination problems.

I suspect we will continue to use specialized applications for a long time. They hold real records and support valuable work. The question is what sits between them: a weary human reconstructing yesterday’s conversation, another fragile chain of scripted actions, or a carefully bounded layer that helps information and decisions move with their context intact.

For the salesperson getting into a taxi, the goal should not be perfect CRM hygiene as an end in itself. It should be a next colleague who understands what the customer wants, a business that can act on the commitment, and a record that accurately reflects what actually happened.

For the technician driving home, the goal is not a beautiful completed form. It is a repaired asset, an accurate maintenance history, replenished stock when required, and a colleague who does not need another phone call to understand the situation.

And for the person approving a contract exception, success is neither an AI-generated briefing nor a green approval status. It is a sound, authorized decision that can be acted upon and understood tomorrow.

That is how I would begin to distinguish an AI-native workflow from a faster collection of app clicks: not by counting the actions it performs, but by asking whether the next person can continue the work without rebuilding the context.