The Tax Most Orgs Are Paying
"The communication tax" is a term from distributed systems engineering. When a computation is spread across multiple processors that have to coordinate, the cost of that coordination, the time spent waiting for one processor to tell another what it needs, can dominate the actual compute time. The tax shows up everywhere coordination is required. It is the thing that determines how a system actually performs in production, independent of how much raw compute is theoretically available.
The same pattern shows up inside organizations adopting AI, and it is producing a specific and recognizable failure mode. AI capability gets built or bought. Then the months-long work of changing the business processes that have to wrap around it stalls. A marketing function adopts an AI-driven targeting capability, and the downstream changes to sales qualification, onboarding, and customer service take months to converge. A finance team deploys an AI-driven anomaly detection tool, and the changes to the reconciliation process, the audit workflow, and the controls documentation take quarters. The capability is there. The throughput is bottlenecked on cross-functional coordination, not on the AI itself.
This is the move most organizations have not yet made: AI deployment is fundamentally process re-engineering, not software shipping. Wherever the AI capability touches an existing business process, every adjacent function feels the impact. Marketing changes flow to sales. Onboarding changes flow to customer support, finance, and ops. Credit underwriting changes flow to risk, compliance, legal, and customer experience. The communication tax is the cost of coordinating those process changes across function boundaries, and most organizations are paying it without realizing they are paying it.
In The Trust Gap, I argued that recommendations stall on the org floor because no single human owns the recommendation-to-decision step. This article is about the team-level mechanism that produces that pattern in the first place. The trust gap is what you see at the organization tier when communication costs across functions are high enough that accountability stays distributed because no one has the cycles to drive across function boundaries to claim it. The communication tax is the underlying mechanism. The trust gap is the symptom.
Why Organizations Adopting AI Pay More Than Most
Organizations adopting AI pay a heavier communication tax than most other change initiatives, for three structural reasons that compound.
The first is vocabulary divergence. The roles that have to coordinate to land an AI capability vary widely, and can include data scientists, engineers, product managers, marketing, sales, customer service, operations, finance, legal, and compliance, depending on what the capability touches. Each of these functions operates from a different vocabulary, a different value system, and a different time horizon. A data scientist optimizing for model precision and a sales leader optimizing for pipeline velocity are not speaking the same language about the same artifact. The vocabulary translation cost on every handoff is what makes the coordination expensive, and the cost compounds as the chain gets longer.
The second is the speed of capability change. The frontier of what AI systems can do is moving faster than most organizations' decision cadences can absorb. A capability that was technically infeasible six months ago is now table stakes; an approach that worked last quarter is being deprecated by a better one. Organizations that synchronize on a slower cadence find themselves perpetually coordinating against a stale picture of what is possible. The faster the capability surface moves, the higher the cost of any communication delay.
The third is the length of the cross-functional impact chain. Landing an AI capability is rarely a one-function operation. An AI tool for customer support might touch support training, quality assurance, ops, and finance. An AI tool for credit underwriting touches risk, compliance, ops, legal, customer experience, and the board. An AI-native software deployment adds research, engineering, product, and platform to that list. Each link in the chain has its own quality bar, its own vocabulary, its own risk tolerance. Any one weak handoff stalls the whole chain. And in most organizations, the handoffs are the things nobody owns explicitly, because each function's metrics measure their own work and not the cost of moving work to the next function.
These three drivers compound. The vocabulary cost makes each handoff more expensive. The speed of change increases the rate at which handoffs are needed. The length of the chain increases how many handoffs each capability requires. The communication tax is the sum of those three integrated over time, and it is the thing that determines whether an organization can actually absorb AI at the rate the capability surface is changing around it.
Three Handoff Patterns That Pay the Most Tax
Three handoff patterns recur across the organizations adopting AI that I have worked with, regardless of whether the org is AI-native or a traditional enterprise. They are the places where communication tax accumulates fastest.
The first is the builder-to-adopter handoff. Whoever produces the AI capability (an internal team, an outside vendor, or a research function) hands it to whoever has to use it operationally (a customer service team, a marketing team, a credit risk team, a finance team). The builder thinks in terms of model accuracy, latency, and uptime. The adopter thinks in terms of how the capability changes their daily work, what training their staff needs, what exceptions break their existing process, and how they explain the change to their customers. These are different optimization targets. The gap between them is where the most expensive coordination cost lives in most AI deployments. The builder thinks the adopter should "just use the tool." The adopter thinks the builder should "just provide something that fits the existing process." Both are wrong, and the work of translating between them is what the deployment actually requires.
The second is the process-to-adjacent-process handoff. AI capabilities rarely sit inside a single business process. An AI-driven marketing targeting tool changes which leads sales sees, which changes sales' qualification work, which changes onboarding's prep work, which changes customer service's expectations of the customer's prior exposure. A change in one process cascades to every adjacent process the underlying workflow touches, and the cost of coordinating those cascades is what determines whether the AI capability actually delivers its promised business impact. Most organizations treat the AI deployment as the change and the downstream process work as somebody else's problem, which is exactly the framing that produces the cascade failure.
The third is the pilot-to-sustained-operation handoff. A pilot is a one-time evaluation with constrained scope, a champion team, and explicit slack in the process. Sustained operation is daily use under normal load, with normal turnover, with normal exception handling, with normal monitoring and retraining. The handoff between the two is where most AI deployments quietly fail. The pilot champions declare success and move on. The operational teams inherit a tool with no documentation of its failure modes, no runbook for exception handling, no monitoring story, and no clear escalation path when the model behavior drifts. The communication tax here is paid in capability that quietly degrades back toward the pre-AI process over the following twelve to eighteen months, which most organizations never measure because the tool is still technically deployed.
The Mechanism Underneath the Trust Gap
Once the communication tax is visible, the trust-gap pattern becomes mechanical rather than mysterious. A recommendation arrives at a decision meeting. The decision requires coordination across three or four functions whose processes the recommendation touches. The coordination has a high tax. No single person on the named-owner side has the cycles to pay that tax repeatedly. So the recommendation drifts. The named owner is named. The accountability is documented. But the cross-functional work required to convert the recommendation into a shipped process change is more than any one person can drive in addition to their day job, and the recommendation expires.
This reframes what closing the trust gap actually requires. The named-owner discipline I argued for in the trust-gap piece is necessary but not sufficient. The other half is reducing the communication tax on the work the named owner has to drive. A named owner who has to navigate three high-friction function boundaries to ship a process change is a named owner who is going to fail at the rate the boundaries fail. Naming the owner is the right diagnostic for accountability. Lowering the communication tax is the right intervention for throughput. Both are required; either one without the other produces theater.
What Reduces the Tax
Four operational moves consistently reduce the cross-functional communication tax in the organizations adopting AI that I have worked with.
Shared vocabulary across functions. The Tower of Babel observation that shared definitions are a precondition for cross-functional reasoning applies directly here. Every organization deploying AI should have a working glossary that the functions whose processes get touched can agree on. The glossary should include what "accuracy" means, what "uncertainty" means, what "production-ready" means, and what "an exception" means in the context of this specific deployment. The work feels bureaucratic right up until the day a recommendation lands in a meeting where everyone uses different definitions of "accuracy" and the meeting ends without a decision.
Explicit handoff contracts. Every function-to-function handoff should have a documented expectation of what the upstream function delivers and what the downstream function accepts. This sounds like overhead. It is the cheapest cost-reducer available, because it makes the cost of any future handoff much lower than the cost of negotiating the handoff every time. The organizations that ship AI capabilities fastest tend to be the ones that have invested in handoff contracts the most explicitly.
Cross-functional working units, not just status meetings. Standing weekly working sessions that include the three or four functions whose processes any given AI capability touches. Not all-hands updates; working sessions where the handoff problems get surfaced before they become incidents. The cost of the meeting is a fraction of the cost of the coordination it replaces.
Service contracts at every interface. Where possible, the artifact one function produces should have the shape of a service contract rather than the shape of a meeting agenda. For software-native artifacts this means an API with a published failure mode and an SLO. For business-process changes it means a runbook with a defined exception-handling path and a named escalation route. The interface design is the communication design, and the discipline of designing the interface is what determines whether the downstream function can absorb the work without dragging the upstream function into every integration question.
What I Do Not Yet Know
The piece of this argument I am least confident about is whether the communication tax reduces as organizations mature in their AI adoption, or whether it stays roughly constant per handoff and just gets amortized across larger throughput. The organizations I have worked with directly span a mix of AI-native engineering orgs and traditional enterprises adopting AI, and the per-handoff cost dominates in both. The largest deployments I have seen up close are still small enough that this dominance holds.
My current hypothesis is that the organizations that ship AI capabilities most reliably have not reduced the tax so much as embedded the handoff infrastructure into shared services that the average contributor never has to think about. The handoff cost still exists; it has moved into a small group that pays it on everyone else's behalf. That is a real reduction at the individual contributor level but not at the organizational level, and it is a structural pattern worth understanding rather than copying without thought.
If you have worked inside an organization that ships AI capabilities at scale, AI-native or traditional enterprise, and you have a counter-example to either of those hypotheses, I would genuinely like to compare notes. The question of how organizations get throughput right on AI deployment is one where the operational knowledge is going to develop faster than the public writing about it for the next several years.