9
AI Stack & Context Friction
Why Your AI Stack Gets Smarter While Your System Gets Dumber
A stack can become more capable in every part while the system loses the context that made the work intelligible in the first place.
Natalie de Groot & NatGPT · September 2026
IN THIS PIECE
INTRODUCTION
A smart component can still participate in a stupid system
Connection is not continuity
The farther work travels from the source, the easier it is to lose the reason
Memory is where the stack starts paying rent
Your business often lives in the exception
Follow one thing all the way through
Integration is preserved meaning, not connection count
Before you make the stack smarter, make the route intelligible
INTRODUCTION
For years, I used a simple test in workshops, masterclasses, in-house trainings and orientation sessions to show people that a very capable AI could still miss something embarrassingly basic. The old version was the strawberry test. That one eventually became less useful because models got better at the exact question. So I started using another one: “I need to get my car washed. The car wash is about a block away. Should I walk or should I take the car?”
The answer can sound excellent. Walking is healthier. Walking is better for the environment. If the weather is nice, it is a pleasant way to get some movement. The reasoning can be fluent, balanced and completely beside the point because the thing that needs to arrive at the car wash is the car. Nothing in the answer has to be absurd for the system to have misunderstood the task. It can contain good facts, sensible recommendations and polished reasoning while failing to preserve the relationship between the facts that actually matters.
That tiny example is useful because businesses can build the same failure at much larger scale. Every individual component in an AI stack can become more capable while the operating environment around those components becomes less coherent. The models improve. The automations get faster. The agents acquire more tools. The integrations multiply. The interfaces look cleaner. Yet context gets reconstructed from room to room, corrections disappear between systems, decisions lose their source, and people spend more time explaining to the stack what the stack was already supposed to know. The company has more intelligence in more places, but less shared understanding of what the work is actually trying to accomplish.
A smart component can still participate in a stupid system
This is the distinction I would make before talking about another integration: local intelligence and system intelligence are different properties. A model can be excellent at the task directly in front of it. An automation can execute perfectly. A retrieval system can return the correct document. A publishing tool can put the content in exactly the right field. None of those successes prove that the whole chain understands why the work is moving, which decision is authoritative, what changed upstream, or what the next system needs in order to act coherently.
That matters because each component tends to see only the slice of the problem it has been given. If that slice is incomplete, the component can optimize beautifully around the wrong interpretation. The car-wash answer is not unintelligent in isolation. It is locally intelligent about walking. It is systemically wrong about the job. The same thing happens when a content agent improves a piece of copy without knowing that legal already rejected the underlying claim, when a sales automation follows the standard discount logic without seeing the exception attached to the account, or when a support agent retrieves the current policy but misses the customer promise that changes how the policy should be applied.
This is why “our models are getting smarter” does not tell me whether the Human-AI System is getting smarter. System intelligence appears in the relationships between components: what they inherit, what they preserve, what they are allowed to forget, which source outranks another, how corrections travel, where human judgment enters, and whether the reason behind a decision survives long enough to inform the next one. The intelligence is not only inside the model. It is also in the route.
Connection is not continuity
A lot of AI integration is described in terms of connection count. ChatGPT connects to the CRM. The CRM connects to Make or Zapier. The automation calls another model. That model writes to a database. The database triggers an email. The email system sends information to the CMS. Everything lights up on the diagram and the stack looks impressively integrated.
Maybe it is. But a line between two boxes proves only that something can move between them. It does not prove that the right meaning moved.
If a company tells me it has connected five systems, I still want to follow one real business object through all five. Where did the original instruction come from? Which customer record did the model see? Which exception survived the first handoff? Did the receiving system know why the previous decision was made, or did it receive only the resulting text? If somebody corrected the output, did that correction become part of the source logic or did it live only in one conversation? If two documents disagree, does the next system know which one has authority? When the final action happens, can anyone reconstruct why?
If those answers fall apart halfway through, the stack may be technically connected and cognitively fragmented. That is the difference between connection and continuity. One moves data. The other preserves enough meaning for the next part of the system to understand what it is inheriting.
The farther work travels from the source, the easier it is to lose the reason
This is where fragmentation compounds. A source becomes a summary. The summary becomes instructions. An agent interprets the instructions. An automation strips away metadata that looked unnecessary. Another model receives the output and fills in missing context from the pattern it sees. A human corrects the result, but the correction never reaches the underlying source. The workflow continues. The next system treats the corrected output as though it were the original truth.
No single step has to be catastrophic. In fact, every step can look reasonable. That is what makes the failure expensive. Small losses accumulate quietly until the final system is operating fifteen miles from the reason the work started.
This is also how companies spend serious money building something that looks intelligent and still feels strangely generic. A vendor scrapes the website, loads the obvious information, writes a plausible system prompt, connects the buttons and produces an interface that speaks in the right vocabulary. The build may be technically competent. But if nobody has traced the business intelligence underneath the website, the system can end up as a beautiful button on top of another beautiful button that is not connected to the actual operating logic of the business.
The missing work is often context reconstruction. Somebody has to understand what the company means, how it makes decisions, what is canonical, what is exception, what has changed, which assumptions are dangerous, and where knowledge really lives. If that work is not designed into the system, people and models perform it repeatedly at every handoff. That is hidden integration work, and it can consume more time than the visible automation ever saves.
Memory is where the stack starts paying rent
When businesses hear “memory,” the conversation can drift toward whether a particular model remembers a user or how much context can fit inside a session. Those things matter, but the operational question is larger: does the right intelligence exist where the next decision is being made?
Does the sales agent know the relevant customer exception? Does the publishing system know why the previous headline was rejected? Does the service workflow know which policy version is current? Does the team lead know where the canonical operating document lives? Does the automation know that yesterday’s correction changed the rule? Does the technical team know which business distinction cannot safely be compressed into a generic instruction?
A company can have enormous amounts of stored information and still have a memory problem if nobody knows what should be retrieved, when, by whom, and with what authority. Old business silos do not disappear because AI arrives. They can become more complicated because now the silo may exist inside a model conversation, an agent instruction set, a private automation, a vendor environment, a departmental knowledge base or one employee’s improvised workflow.
The goal is not to give every component everything. That would create its own problems. The goal is to make memory purposeful. Some systems should know less. Some information should remain local. Some context should travel. Some decisions should become durable shared memory. Some corrections should change the system. The architecture becomes intelligent when the company knows the difference.
Your business often lives in the exception
General-purpose intelligence is very good at general patterns. Businesses, however, often become themselves in the exceptions.
There is the customer who has always been handled differently because of an old promise. The market where the normal message creates a legal problem. The product whose margin changes the standard approval logic. The founder rule that never made it into the handbook. The strange-looking workflow that everyone wants to streamline until somebody explains the failure it was designed to prevent. The client preference that sounds trivial until violating it costs the relationship.
These are not necessarily anomalies that should be removed. They may be the information that makes the business specific enough to behave like itself.
The car-wash test works because the obvious general recommendation is not the useful answer. The specific relationship changes the reasoning. Your Human-AI System has to be able to do the same thing. It needs to know when the general pattern is good enough and when the business-specific exception changes the task.
This is one reason generic website scraping and broad “train it on your company” implementations can disappoint. A website usually contains the company’s public representation. It does not necessarily contain the exceptions, correction history, operating judgment, invisible handoffs, informal source precedence or hard-earned reasons behind the work. Those are often sitting in people, old documents, conversations, habits and decisions. If the system never reaches them, it can sound exactly like the business while failing to think with enough of the business.
Follow one thing all the way through
One of the most useful diagnostics is also one of the least glamorous: follow the work.
Pick one customer request, one content object, one decision, one correction or one exception and trace it through the entire Human-AI System. Do not stop at the architecture diagram. Watch what actually happens as it moves between the human, the model, the agent, the automation, the database, the team, the publishing system and whatever comes next.
At each handoff, ask what survived, what changed, what disappeared, what had to be reconstructed and who noticed. Ask which source the next system received, whether the previous reasoning traveled with the output, whether a correction became durable, whether the human operator had enough context to challenge the machine, and whether the machine had enough context to know when to escalate back to the human. If nobody can explain the route without opening six tabs and calling the one employee who “knows how it works,” that is useful diagnostic evidence.
I would especially want team leaders and department heads involved in this tracing because they often hold the local intelligence that a centralized implementation misses. They know which exceptions are real, which shortcuts are dangerous, what the team has quietly learned, and which information another department needs but never receives. The point is not to turn every leader into an AI architect. It is to make the intelligence traversable enough that technical architecture is not built around an imaginary version of how the work happens.
This kind of trace also exposes where the human is functioning as an invisible repair layer. If someone constantly copies context from one system to another, reminds an agent what happened before, translates a correction, checks which version is current or re-explains why a decision was made, that person is doing integration work. The stack may look automated while the continuity is being held together manually.
Integration is preserved meaning, not connection count
This does not mean every workflow needs a vast memory architecture or every automation needs to carry the entire history of the business. Sometimes a technical connection is exactly enough. A narrow low-risk task can move from one system to another with very little context and still work perfectly. A disposable prototype does not need the same continuity rules as a customer-facing system that acts on business judgment.
The question is proportionality. The more consequential the decision, the more specific the business logic, and the farther the work travels from its source, the more important it becomes to preserve the meaning required for the next action. Integration should be judged by whether the system can continue to act coherently after the handoff, not by how impressive the diagram looks.
That may mean fewer connections. It may mean better source precedence. It may mean making one correction durable instead of allowing five systems to rediscover it. It may mean giving a team leader a maintained local context layer. It may mean separating systems that should not share memory. It may mean adding an explicit human decision point where the business exception cannot be safely generalized. The right architecture is not always more connected. It is more intentional about what crosses the boundary.
Before you make the stack smarter, make the route intelligible
If a company came into a Human-AI Orientation saying, “Our tools are all powerful, but nothing feels connected,” I would not start by recommending another integration platform. I would trace the movement of context, memory, decisions and authority through the stack and look for the places where the work has to be reconstructed.
Where does the original intelligence enter? What gets preserved? What gets compressed? Which decisions become shared? Which stay trapped inside one environment? Which corrections actually change the system? Where is a person compensating for a broken handoff? Which system is using a generic representation where the business requires an exception? Where has a technically elegant build drifted away from the problem it was supposed to solve?
Only after that map exists does “integration” become a useful implementation question. The next move might be a technical connection. It might be memory design, source cleanup, a team-level context layer, a governance rule, a narrower agent, a different workflow or simply stopping one automation from reconstructing something the business already knows.
The goal is not to make every component equally smart or to connect everything to everything else. The goal is to make sure the Human-AI System can still explain why it is doing what it is doing when the work arrives three rooms away from the original decision.
HUMAN-AI ORIENTATION
Where does the meaning get lost?
Bring one real business object or task that moves through the stack. We follow it end to end, record what survives, changes, disappears, or gets rebuilt, and identify whether the next fix belongs in memory, routing, ownership, or integration.
€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