There is a phrase moving quietly through engineering teams right now that names something they have been struggling to put their finger on. They call it the context tax.
It is not a term from organisational theory or executive coaching. It came from people building AI systems. Specifically, from the engineers and product teams discovering that even the most capable models fail in predictable, expensive ways when they cannot see the full picture of what is being asked of them.
That phrase travels. It describes a problem that is not unique to machines. The same dynamic, with the same name, is at work inside organisations, and at work inside the daily life of individual professionals. Once you see it in one place, you start to see it everywhere.
This article tracks that idea across three settings. We will look at how the context tax first surfaced in the world of AI, what it looks like when an organisation pays it, and what it feels like when an individual pays it. We will then turn to a question that AI engineers can answer with code but that organisations and people cannot. How do we systematically reduce the tax? That is where the MAPS framework comes in.
Where the Phrase Began: AI and the Cost of Missing Context
The phrase context tax began to circulate among practitioners working with large language models. The pattern they were describing is now well-documented in the AI engineering literature. When an AI system does not fully understand the environment, assumptions, relationships, or intent surrounding a task, it produces work that is plausible-looking but wrong, shallow, or oddly disconnected from what was actually needed.
It is not, strictly speaking, a technical error. The model is doing exactly what it was trained to do. The cost shows up because the model is operating without enough context to do that work well.
In practice, AI engineers report seeing the context tax as a recognisable set of symptoms. Wrong recommendations that look authoritative but apply to the wrong situation. Shallow outputs that summarise the surface of a problem without engaging its substance. Hallucinations, where the model fills in missing context with plausible-sounding inventions. Repetitive prompting, where a user has to re-explain the same background information over and over because the system has no way of remembering it.
Each of these symptoms is, at its root, the same problem. The model cannot see the room it is operating in. It cannot see the user’s history, the organisation’s constraints, the relationships at stake, or the unwritten rules of the domain. Lacking those, it does its best with what it has. And what it has is rarely enough.
AI engineers have responded with a discipline they now call context engineering. The phrase, like the problem, is recent. It describes the deliberate practice of designing what an AI system sees at each step of a task: just enough relevant context to do the work well, not so much that the model gets confused, and not so little that it operates in a vacuum. The discipline has become one of the most important capabilities for anyone building serious AI systems.
Here is what is worth pausing on. The engineers who coined the phrase were not, in the first instance, thinking about organisations or people. They were thinking about machines. But the pattern they named is not really about machines. It is about what happens to any decision-making system, biological or digital, when it acts without enough context. The cost is the same. The symptoms are the same. The fix is the same in principle, even if the implementation is wildly different.
Once you see the context tax clearly in AI, it becomes impossible to unsee it elsewhere.
How Organisations Pay the Context Tax
Organisations pay the context tax constantly. Most of them have no name for it, which is part of why it is so expensive. You cannot reduce a cost you cannot name.
In a large institution, the context tax shows up wherever decisions are made by people who do not have a complete reading of the environment they are deciding into. The decision-makers are not lazy or incompetent. They are often the most capable people in the building. But they are operating with partial information, missing relationships, and assumptions that have been carried in from other settings and never tested against the current one.
What the Tax Looks Like Inside a Large Organisation
Consider a development finance institution approving a multi-million-dollar programme in a country its officers have visited but never lived in. The technical design is excellent. The financial appraisal is rigorous. The theory of change is internally coherent. Eighteen months in, the programme is underperforming. Not because the funding ran out. Not because the partners were weak. Because the operating context did not match the assumptions the design was built on.
That gap has a name. I call it context-driven execution loss. It is the organisational form of the context tax. It is the predictable divergence between what a programme was designed to deliver and what it actually delivers, caused by unexamined contextual conditions at the point of commitment.
The same dynamic shows up across sectors. International NGOs designing interventions that work beautifully in pilot countries and collapse in scaling countries. Corporations expanding into new markets with playbooks built for their home market. Government agencies importing reforms from other jurisdictions and discovering, often too late, that the institutional plumbing was different in ways nobody flagged. Mergers and acquisitions where the cultural and power dynamics of the acquired entity were never read accurately, and the integration takes three times as long as the deck promised.
In each case, the organisation is intelligent, well-resourced, and acting in good faith. But the decision was made in a room that could not see the room the work would actually be done in.
Why Organisations Underestimate This Cost
The organisational context tax is hard to see because it does not appear on any single line of any budget. It shows up as time slippage on dozens of projects, as portfolio underperformance that gets attributed to country risk or partner capacity, as failed transformations that get diagnosed as change management problems. The individual symptoms are real. But the underlying cost is the same one, paid in fragments, across the institution.
When AI engineers see this pattern in their systems, they redesign the system. They invest in context engineering. They build retrieval pipelines, memory architectures, and context-aware tooling. They treat the tax as a fixable engineering problem, because it is.
Organisations rarely do the equivalent. There is no organisational role for context engineering. No budget line. No diagnostic that surfaces the cost. The tax keeps being paid, by everyone, in invisible instalments.
How Individuals Pay the Context Tax
The most personal form of the context tax is the one that lands on individual professionals. It is also, in many ways, the most painful. Because it does not present itself as a system failure. It presents itself as a personal one.
An experienced engineer arrives in a new country and watches her career stall, even though her credentials are excellent. A senior manager moves from one sector to another and finds that the moves that made her effective in the old one are misfiring in the new one. A consultant takes a role in a different organisation and discovers, six months in, that the playbook she brought with her is producing the opposite of what she intended.
None of these professionals lacks skill. None of them lacks effort. They are paying the context tax in a form that, until very recently, did not even have a name.
Why Skills Do Not Transfer Cleanly
We were raised on a story about portable skills. A good manager is a good manager anywhere. A strong engineer is a strong engineer anywhere. A capable strategist drops into any environment and performs.
The story is incomplete. Skills do not transfer cleanly. They get re-priced by context. Every time you move a capability into a new environment, you pay a context tax: the hidden cost of relearning how that capability actually works here, now, with these people, these systems, these incentives, and these unspoken rules.
The professionals who succeed fastest in new environments are not the ones with the most innate talent. They are the ones who decode the new context the fastest. That decoding skill, until recently, was treated as intuition. Some people had it. Some people did not. There was nothing in between.
That is not true. Context reading is a skill, not a trait. It can be built. The cost of not building it is the personal context tax: stalled careers, painful transitions, plans that fail not because they were bad plans but because they were built for the wrong room.
The Same Pattern, Three Scales
Notice what we have just walked through. Three very different settings. The same underlying pattern.
An AI system pays the context tax when it operates without the surrounding information it needs to interpret a task accurately. The symptoms are wrong recommendations, shallow outputs, hallucinations, repetitive prompting.
An organisation pays the context tax when it commits resources to programmes, strategies, or expansions whose underlying assumptions do not match the operating environment. The symptoms are execution loss, portfolio underperformance, failed transformations, integrations that stall.
An individual pays the context tax when their skills, plans, and approaches were built for a different environment than the one they are now operating in. The symptoms are stalled careers, ideas that die in the wrong room, relationships that fracture, transitions that take far longer than they should.
Same pattern. Same root cause. Same cost, paid in different currencies.
And here is the question that follows. If AI engineers have built a discipline to systematically reduce the cost on their side, what is the equivalent discipline for organisations and people?
Where MAPS Comes In
This is the question I built the MAPS framework to answer.
MAPS is a structured way of reading any operating environment well enough that the actions taken next are appropriate to the environment as it actually is, rather than the environment that was assumed. It is the human and organisational equivalent of context engineering.
The framework has four dimensions, and each one of them maps onto a category of context that organisations and individuals routinely miss.
M: Mind
The cognitive and interpretive frames at work in the environment you are about to act in. How do people here think about success, risk, time, trust, and authority? Mind is the layer most often missed by professionals moving between sectors or cultures, because we tend to assume that the way we think is the way thinking works.
A: Authority
How legitimacy is constituted in this environment. Who gets to say yes. Where the formal sanction for decisions actually lives. Authority is the layer most often missed when an outsider assumes the org chart is the truth, when in fact the room often has a different shape than the chart suggests.
P: Power
How influence is actually distributed, exercised, and contested. Power is not the same as authority. Authority sits on the org chart. Power sits in the hallway. Reading power means seeing who actually moves things, who quietly blocks them, and what currencies of influence are in circulation in this particular room.
S: Systems and Social Trust
The institutional plumbing that determines how things move, and the trust dynamics that either let those systems work or quietly disable them. Systems and trust are the foundation layer of any environment. When trust is high, even imperfect systems function. When trust is low, even the best-designed systems are routed around.
Reading All Four Together
Each dimension, read alone, gives you a partial picture. Read together, the four dimensions produce what I call context intelligence: the capacity to interpret an operating environment with enough resolution that the actions you take next are appropriate to that environment.
Context intelligence is the human equivalent of the discipline that AI engineers call context engineering. Both are responses to the same underlying problem. Both reduce the same hidden cost. Both turn an invisible drag on performance into a manageable, addressable variable.
MAPS does for organisations and individuals what context engineering does for AI systems. It surfaces the layers of an environment that would otherwise be invisible, gives them names, makes them readable, and creates a basis for action that is matched to the room rather than imported from a different one.
Why This Conversation Is Happening Now
It is not an accident that the phrase context tax surfaced first in the world of AI. Building AI systems made the problem unignorable. When a model produces a confidently wrong answer because it could not see the surrounding picture, the cost is right there in the output. You can measure it. You can debug it. You can do something about it.
In organisations and in individual careers, the same cost has always been there. It just hid better. It looked like bad luck, bad fit, bad timing, bad partners, bad market conditions, bad management. We did not have a vocabulary for naming what was actually going wrong.
Now we do. The AI engineers named it first. The phrase fits the human and organisational versions of the problem so well because it is, at root, the same problem. Decision-making systems, of any kind, fail in predictable ways when they act without enough context. The fix, in any setting, is to make context legible, structured, and addressable.
That is what MAPS is for. It is a method for doing context engineering on the human side of the line.
Organisations that learn to read their operating environments with MAPS reduce execution loss in their portfolios. Individuals who learn to read rooms with MAPS reduce the personal cost of transitions and the time it takes to become effective in any new environment. Both, in their different ways, stop paying a tax they did not know they were being charged.
A Final Word
The context tax is not new. What is new is the language for naming it, and the discipline for reducing it. Engineers building AI systems showed us that the cost of missing context is a fixable cost when you treat it as engineering. The same is true for organisations. The same is true for people.
Through Edify Learning Forum, my work is to take the discipline of context intelligence out of the realm of intuition and into the realm of structured practice. The MAPS framework is the tool through which we do it. The book that introduces it, The Context Tax, names the cost. The framework underneath it gives us the way to start reducing it.
Wherever you sit, building AI systems, leading an institution, navigating your own career across cultures and contexts, the same question applies. What is the cost you are currently paying for context you have not yet learned to read? And what would it be worth, to you or to your organisation, to stop paying it?
