10
AI Stack & Context Friction
Stop Building Workflows Around the Tools
The moment the tool defines the workflow, the business starts adapting itself to software instead of designing the work it actually needs.
Natalie de Groot & NatGPT · September 2026
IN THIS PIECE
INTRODUCTION
The tool should not get to define the work
The human is part of the specification
A powerful tool can make weak work happen faster
Excitement is not empowerment
Businesses have always tried to capture human know-how
Do not confuse adapting to software with improving the work
The digital colleague needs to stay in the conversation
Start with the work, then choose the smallest technology that serves it
If the software disappeared tomorrow, could you still explain the work?
INTRODUCTION
A company can spend a surprising amount of money on AI before anyone asks the most basic implementation question: how does this work actually need to happen? I have seen the sequence run in reverse more than once. Leadership buys the platform, the automation, the agent layer or the lead-generation system because the capability looks extraordinary. Then the organization starts bending people and process around whatever the product was built to do. Training becomes learning the interface. Workflow design becomes deciding which field goes into which box. Success becomes whatever metric the software happens to expose most confidently.
One marketing agency I worked with had bought a powerful automated lead-generation tool. The owners were excited because it could produce volume. And it did. The problem was that the volume was sending salespeople into calls with people who should never have reached a sales call, while the automated messaging was generic enough to make a strong agency sound like every other company using the same machinery. Employees tried to repair the output manually, but their fixes tended to improve one message rather than change the underlying behavior. Eventually the team used the system less because every interaction created more correction work. The software was working. The implementation was not.
That distinction matters. Buying AI capability is not the same thing as implementing AI well. A tool can perform exactly as advertised while the business around it becomes slower, more generic or more frustrating. The implementation problem begins when the organization treats the product as the specification and asks humans to reorganize themselves around it before anybody has defined what good work actually requires.
The tool should not get to define the work
The normal implementation question sounds reasonable: how do we integrate AI into our existing workflow? But even that can start too far downstream if the workflow itself has already been shaped by software constraints. Before I ask where AI belongs, I want to understand the movement underneath the tools. What is the outcome? Who is involved? What information has to arrive? Where does judgment happen? Which part of the work needs continuity from one handoff to the next? Which step exists because it genuinely serves the work, and which step exists only because an old system once required it?
I think of a workflow as how work, people, information and judgment move toward an outcome. Software steps are one layer of that movement, not the definition of it. Once you see workflow that way, implementation changes. A CRM field is not the workflow. A Zapier trigger is not the workflow. A sequence inside an automation platform is not the workflow. Those are technical representations of movement that the business should already understand well enough to evaluate.
This is why I would ask a company a slightly uncomfortable question before we redesign anything: if none of your AI tools existed tomorrow, could you still explain how this work needs to happen well? If the answer is no, then the business does not yet have a workflow design. It has a product configuration. That does not mean the configuration is useless. It means we should not confuse the interface with the operating logic underneath it.
The human is part of the specification
When I say the human is the specification, I do not mean every habit should be preserved or every employee preference should become a permanent system requirement. I mean the design has to begin with reality. Who actually does the work now? How do they think about it? Where do they make a judgment that is obvious to them but invisible in the process map? What do they hate doing? What do they wish someone else would carry? Which part of the work gives them energy because that is where their expertise becomes visible? Where have they invented a workaround because the formal process does not fit what actually happens?
I am looking for the equivalent of the box that says “click here if you are human.” Those moments reveal where the official sequence and the lived process diverge. They show me where AI is likely to misunderstand something, where a human is compensating for a system gap, and where automation might remove the wrong thing. A marketing team may absolutely want help producing, organizing and distributing content. That does not mean they want the creative judgment removed. The better design may be to hand them the baton as conductor while the machine carries more of the repetitive orchestration around them.
This is also where AI Behavior Design becomes relevant. In the deeper Human-AI Systems work, the field is concerned with shaping how an AI system behaves, remembers, expresses and evolves through intentional structure rather than treating each interaction as an isolated prompt. The practical implication for a business is simple: the system has to be taught enough of the human and organizational pattern to behave in alignment. If the company simply installs a generic prompt library, scrapes the public website and calls the result “trained on your business,” it may have transferred information without transferring the behavior, judgment or context that makes the business itself.
A powerful tool can make weak work happen faster
The lead-generation example matters because nobody needed a more powerful lead generator. They needed a better definition of a qualified opportunity, a better representation of the agency’s voice, and a system that could learn from the team’s corrections instead of making people repair generic output over and over. The owners had purchased capability before defining the conditions under which that capability would create value.
This pattern appears everywhere. A company buys an AI writing platform because it can produce fifty assets in the time a team once produced ten. Then the team spends hours rewriting them because the system flattened every meaningful distinction. An automation reduces the number of clicks but adds review because nobody trusts what arrives at the other end. A chatbot answers instantly but creates more escalations because it does not know which customer exceptions matter. The numbers can look impressive while the work gets worse.
That is why efficiency has to be evaluated against the actual outcome, not merely the visible activity. More leads are not better if the wrong people reach sales. More content is not better if the brand becomes generic. More automated decisions are not better if humans have to clean them up afterward. A system can remove labor from one step while quietly creating correction labor in three others. If the implementation team only measures what the tool does, it can miss what the humans are now doing to compensate for it.
Excitement is not empowerment
I have been brought into rooms to get people excited about AI, and I can do that. A large audience can leave a session energized, curious and ready to experiment. But excitement and empowerment are not the same thing. If Monday morning arrives and employees still do not understand what AI is supposed to help them do, what they are allowed to change, how their expertise should enter the system, or what to do when the output is wrong, then the organization has created enthusiasm without operating capacity.
That gap is common when leadership wants AI adoption but has very little visibility into where the team actually is. Licenses get purchased. A training day happens. Maybe a vendor includes onboarding. Then the organization wonders why adoption is uneven. Sometimes the team is resistant. Sometimes, though, the team has already discovered that the tool creates generic work, repeats mistakes, or makes them feel as though their job has been reduced to feeding a machine that does not understand why their expertise matters.
Empowerment requires more than teaching buttons. People need enough understanding to participate in the system. They need to know where their judgment belongs, how to correct the AI in a way that can improve future behavior, when to challenge it, what information should be shared, and what should remain under human control. The point is not to turn every employee into a systems architect. The point is to stop treating the human operator as the last-mile inconvenience in a workflow that was supposedly designed for them.
Businesses have always tried to capture human know-how
Long before generative AI, companies tried to make tacit work explicit. I remember an employer years ago who had everyone document procedures in extraordinary detail: what happened when the office opened, how a new client file was created, where things were stored, which steps followed which. The reason was stated plainly. The business needed the process to survive the person.
There is nothing new or inherently sinister about documenting work. Organizations need continuity. What changes with AI is that the knowledge being captured can become executable. A person is not only writing down how they do the job. Their language, judgment patterns, exceptions, methods and decision habits may become material that trains or conditions a system that can perform parts of that work later. That deserves more care than “please fill out this process document so we can automate it.”
Door 10 does not need to become an ownership argument, but implementation teams should at least recognize the significance of the transfer. Employees are not merely data-entry points. They are often the source of the intelligence that makes the system useful. If you want them to participate seriously, it helps to be transparent about what is being learned, how it will be used, what remains theirs to decide, and why the organization is asking for that knowledge in the first place.
Do not confuse adapting to software with improving the work
There is an obvious boundary condition here. Sometimes the tool should change the workflow. Sometimes the old process is terrible. Sometimes a new technical capability exposes an approval step nobody needs, a manual ritual inherited from software that disappeared years ago, or a variation that adds no value and should finally be standardized. Good implementation is not a museum for old habits.
The distinction is whether the change improves the work or merely makes the work easier for the software to process. If a team has to add a pointless step because the platform cannot represent the actual decision, that is adaptation to software. If automation removes a pointless step because the decision can now be handled safely with less friction, that may be real improvement. If twenty people use twenty incompatible names for the same object, standardization can create enormous value. If the tool requires everyone to flatten meaningful exceptions into one category because that is what the dashboard supports, the simplification may destroy useful intelligence.
The tool has to earn the right to reshape the workflow by making the work more coherent, more usable, safer, faster or more valuable. The license agreement does not grant that right automatically. The test is not whether the implementation matches the product documentation. The test is whether the work is better after the technology enters it.
The digital colleague needs to stay in the conversation
Workflow design also cannot be treated as a one-time installation exercise because the work changes after AI enters it. People discover new uses. They discover things the system gets wrong. A team develops shortcuts. A model improves. An agent acquires another responsibility. A customer expectation changes. The system learns from repeated use whether the organization intended to teach it or not.
That is why I keep coming back to a simple operating habit: if AI is materially participating in the team’s work, talk about the digital colleague regularly. It does not require a new committee. A short recurring conversation inside an existing staff meeting can be enough. What helped this week? What irritated everyone? What did we correct repeatedly? Where did the AI save real time? What did the team learn that the system does not know yet? What should it stop doing? Which decision or exception needs to become part of the maintained context rather than stay trapped in one employee’s head?
The AI system can even participate in that learning loop. If meetings are already recorded and transcribed through approved company tools, the relevant system can review those transcripts under appropriate privacy and access rules and surface recurring friction, missing context or opportunities to help. That is not about letting AI run the meeting. It is about making sure the system responsible for supporting the work is not structurally excluded from the information that explains how the work is evolving.
This creates a healthier implementation rhythm: map, implement, observe, teach, adjust. The workflow remains a living operating environment rather than a frozen diagram built around the software that happened to win the procurement process six months ago.
Start with the work, then choose the smallest technology that serves it
If a company came into a Human-AI Orientation asking how to integrate AI into a business workflow, I would not begin with a list of tools. I would begin with the desired outcome and work backward. Who is involved? What are they trying to accomplish? What information has to be present? Where does judgment enter? Which decisions repeat often enough to support automation? Which exceptions carry enough consequence that a human should remain close? What needs to be remembered next time? What does the team want help with, and what part of the work do they want to keep because that is where their expertise lives?
Then I would look at the existing systems. Some may already be good enough. Some may be causing unnecessary friction. Some may only need better context or behavior design. One may need to disappear. Another may need a narrower job. Perhaps the right move is an automation. Perhaps it is a team-level context layer, a custom environment, a better training practice, cleaner source material or a simple change in who owns a decision. Technology enters after the operating requirements become visible.
This is not slower than tool-first implementation. It is often the faster path because it reduces the expensive loop where a business buys capability, discovers the people hate it, patches the prompts, adds another tool, hires someone to integrate the integration, and eventually pays to rebuild the thing around the work it should have understood in the first place.
The implementation question is not “Where can we put AI?” It is “How does this work need to happen well, and where would intelligence actually help?” Once those answers are clear, the tool choice becomes smaller, more practical and much less magical.
If the software disappeared tomorrow, could you still explain the work?
That is the question I would leave on the table. A company should be able to explain its desired work without naming a vendor. It should know what outcome matters, what intelligence belongs to the business, where human judgment creates value, what information has to travel, and where technology can remove friction without removing meaning. That becomes the foundation the tools are asked to serve.
The deeper Human-AI Systems work calls this kind of design intentional rather than transactional. AI Behavior Design was built around the idea that behavior, memory and continuity have to be shaped through structure, not hoped into existence through isolated prompts. At the business level, the same principle applies to implementation. A Human-AI System does not become coherent because the software is powerful. It becomes coherent because the people, intelligence, rules and technology have been arranged around work the organization actually understands.
So yes, integrate AI into the workflow. Change the workflow where the evidence says it should change. Automate aggressively where automation improves the work. Standardize what deserves standardization. But do not begin by asking the company to behave like the product. Begin by understanding the work deeply enough that the product has to prove it belongs there.
HUMAN-AI ORIENTATION
Does the workflow serve the work, or the tool?
Bring the process you want AI to support. We separate the actual work from the software around it, make the human operating logic visible, and decide which technology has earned a place in the workflow and which has not.
€950 · 2.5 hours · nothing is sold in the room
FIELD CONNECTION • hUMAN-ai sYSTEMS
Go deeper only when the thought needs another room.
Authentic AI Marketing opens the commercial door. Human-AI Systems holds the deeper architecture, artifacts, and system thinking behind the work.
DEEPER SYSTEMS. RICHER CONTEXT.
Watch / Listen
Read / LLM Ingestion