I just finished The Warrior Elite, a book about the brutal selection course Navy SEAL candidates have to survive to earn the trident. In Phase Three of BUD/S, the land warfare phase, trainees run field exercises against simulated objectives. Buildings to clear. Targets to neutralize. Communications facilities to seize.
One detail stood out to me. As the team sprints toward the objective, every set of eyes locked on what is in front of them, one guy calls out something the others do not. “I got long!”
Translation: I am watching the distance. I am looking for what the rest of you cannot see because your eyes are on the target. Somebody has to. One man’s job boils down to this: do not let the immediate threat blind you to the one coming.
That scene is playing out in enterprise AI right now, just with worse cardio and more JIRA tickets.
A lack of context portability is the threat in the distance. Almost nobody has felt it yet because almost nobody has gotten far enough to feel it. Most teams are still on the immediate objective: stand up the context, ship the first agents, get the evaluations in place, build some confidence the thing actually works. That is the right work to be doing. It is also exactly why nobody has their eye on long.
What “long” actually looks like
Think about the last time you switched phones. iPhone to Android, Motorola Razr to iPhone, whichever direction. You did not sit down with a notebook and re-enter five hundred contacts by hand. You exported them, imported them, they showed up on the new device. The contacts were yours, not the phone’s.
Context portability is the same idea, applied to the meaning of your data.
The tight version: your data’s meaning should travel with the data, not with the tool it happens to be configured inside.
Most companies do not have that today. There is no canonical source for what “active customer” actually means. What exists is a definition inside the CRM, a different one inside the BI tool, a third inside whatever the AI team is building. That is what happens by default. When there is no authoritative version, every tool invents its own, and every new tool has to invent it again.
Context portability means you define it once, and that definition travels. Your AI agent, your CFO’s dashboard, the calculation in your customer-facing app, all of them answer the same question the same way, because all of them are reading the same authoritative version.
And it is not just metric definitions. The same problem applies to everything your data means: which columns hold PII, who owns the customer table, which policy governs access to it, what counts as certified. A definition of “active customer” that does not travel gives you a wrong number. A PII classification that does not travel gives you a compliance incident. Meaning is bigger than metrics.
Why this was a smaller problem before, and why it is a bigger one now
Lock-in is not a new problem. Anyone who has migrated off a BI tool knows what it feels like to rebuild semantic meaning from scratch. LookML in Looker. Metrics in Tableau. Five hundred dashboards full of calculated fields that one analyst built and then left the company two years ago without writing anything down. Painful. But bounded. You rebuild the dashboards, you curse the previous vendor for a week, and life goes back to normal.
AI changes that. The ceiling comes off.
Three things break.
The first is that every agent needs authoritative context to function. Not “plausible” context. Not “inferred from a column name” context. The definition your business has actually agreed on, delivered to the agent at the moment it needs it. Most agents, especially the ones running in automated pipelines, batch processes, or behind a natural language query interface, do not pause to ask clarifying questions. They answer from whatever context they can reach. Even conversational agents that can ask follow-up questions will not ask “what do you mean by active customer” if the definition is not in their context to begin with. They cannot ask about something they do not know is missing. Whether your agents can ask is beside the point. What matters is whether the definition they need is reachable at query time, from the authoritative source, before the answer is generated.
The second is that the cost stops being one-time. Every new agent re-incurs it. You stand up your first agent on top of a curated dataset. It works. You stand up the second agent on a different stack, and now you are re-authoring the same business meaning a second time. The third, in a different cloud, and you are re-authoring it a third time. None of them inherit the work of the others. The investment does not compound. It restarts.
The third is that the failures stop being loud. When two dashboards disagreed, somebody eventually filed a ticket. Somebody argued. Somebody escalated. The disagreement was visible. When two agents disagree, nobody sees it. Each is answering a different question for a different audience, confidently, on a different definition. The divergence never surfaces until somebody happens to compare notes weeks later, by which point the CFO has been making decisions on the wrong number for two quarters.
The version of this I hear most often, from data leaders across very different industries, goes something like this. Getting the right context to an agent at build time is a solved problem, or close enough to one that most teams can work through it. What they cannot do is move that context everywhere else it needs to live, and pull it back down at the moment an agent actually needs it. That gap, between setting one agent up correctly and being able to do it at scale, is the thing nobody has an answer for.
The pattern underneath it is always the same. A company already has agents running on four or five different platforms. Different teams, different stacks. Every one of those agents needs to know what an “active customer” is. None of them are getting that answer from the same place. The problem is structural, and it is about to get expensive.
That is what long looks like.
The obvious response is to wait for the platforms to solve it. Every vendor in your stack is promising to hold your context for you, and every one of them means it. Notice what that is. Portability that reaches only where one vendor’s platform reaches is just lock-in with better marketing. If your definitions can only travel where one vendor’s platform reaches, you have not made your context portable. You have chosen which walled garden it lives in. Contacts became portable because they became a standard nobody owns. The meaning of your data needs the same thing: authored once, governed in one place, readable by every tool you run today and every tool you have not bought yet. That has a concrete implication most teams miss. The definitions themselves have to live in a format any engine can read, the same way open table formats are ending warehouse lock-in for the data itself. Portability is a property of where the meaning lives. It is not a feature a platform grants you.
What you actually get
Two problems get solved when context is portable.
The first is the authoring problem. Without portability, “active customer” lives in four places with four owners, which is four opportunities to drift. And they will drift. Someone updates the CRM to exclude churned trials. Nobody updates the BI tool. Nobody updates the agent. Six months later, the CFO’s board deck reports 41,000 active customers, the AI agent tells the CS team 38,500, and the head of sales is on a call asking which number is real. Nobody in that meeting is having a good time.
Portability collapses that into one definition, in one place, with one owner. Every downstream tool reads the canonical version. When it changes, it changes everywhere.
The second is the migration problem. Your stack is going to evolve. You will change BI tools, add a warehouse, adopt an AI platform that did not exist when you designed the last one. Without portability, every one of those moves means rebuilding the meaning of your data from scratch on the new tool. With portability, the tool changes and the meaning stays. When you switch phones, the numbers do not move because the phone did the work. They move because they were never really the phone’s to begin with.
Portable is not the same as governed
This is the part of the argument where I have to slow down, because it is where most portability conversations go sideways.
Making your context portable does not, by itself, make it useful. A portable definition that nobody owns is still tribal knowledge, just in a different format. If “active customer” travels between tools but nobody is on the hook for what it means, when it last changed, or who signed off on it, you have not solved the problem. You have made it easier to distribute the mess.
Three things have to travel with the definition for portability to actually matter.
Ownership. A named human is accountable for what “active customer” means. When the definition needs to change, that person owns the change. Not a Slack channel. Not a wiki page nobody has opened in eight months. A person.
Version history. Every change is captured. When a downstream agent starts giving different answers than it did last quarter, you can trace it back to the definition change that caused it, and to the moment the change happened.
Lineage. When “bookings” gets redefined, you can see every dashboard, every agent, and every model that depends on it. The change might be right. You should never be surprised by what it breaks.
Skip any of these and portability turns into distributed drift. Same definition, five places, none of them talking to each other. You made the problem worse.
Portable is not the same as delivered
There is one more thing that has to be true for portability to work. The definition has to reach the agent.
A perfectly authored, perfectly governed definition sitting in a catalog is not portable if the agent cannot read it at query time. It is documentation. Very good documentation. Not what an agent needs.
Portability requires a delivery mechanism. Something that puts the authoritative definition in front of the agent, programmatically, at the moment the agent needs it. Not baked into a system prompt six weeks ago. Not copied into a YAML file that has already drifted from source. Live, at runtime, from the canonical source.
The delivery mechanism does not have to be one thing. It can be MCP. It can be a semantic layer API. It can be a file protocol. It can be a direct query interface. What matters is that the agent is reading from the authoritative source at the moment it is being asked, not from a stale copy that got embedded somewhere along the way.
Skip the delivery mechanism and all the work of building governed, portable context produces nothing at the moment of the query, which is the only moment that actually matters.
Why one guy calls long
The SEAL who calls “long” is not solving the immediate problem. His teammates are on the immediate problem. His whole job is to make sure they get to do that job again tomorrow.
Context portability works the same way. Building it now does not make today’s agents any better. Today’s agents are working. That is not the argument. The argument is about what happens on agent number six, or agent number ten, or agent number twenty-eight. Whether they inherit the work you have already done, or they start from zero because nobody built the layer that lets the meaning travel.
Almost every enterprise AI team is going to end up with more agents than they have today. Some will have hundreds. A few will have thousands. The teams that build for that reality now are going to spend the next three years compounding their work. The teams that do not are going to spend the next three years paying the same authoring tax, agent after agent.
Compounding is worth being precise about. The case that context compounds through feedback loops has been made in these pages before. Portability is the precondition. An agent that discovers a definition produced a wrong answer in production has just generated context the next agent needs. Nothing flows back, and nothing compounds, across agents that cannot reach the same canonical source. The difference is whether your context can be written to, not just read from.
Neither team can tell you which one they are yet. Both are executing well against the immediate objective. The difference will not show up in quarter one, or quarter two, or in the first ten agents. It will show up somewhere between agents fifteen and thirty, when the cost of another re-authoring cycle stops being tolerable and everyone realizes that the way they set the problem up in year one is going to cost them the next three.
That is the guy calling long. And right now, in enterprise AI, almost nobody is calling it.
What to do about it Monday
There is a window for building this in, and it is smaller than most teams realize. Retrofitting portability onto twenty agents that were each configured against their own definitions costs more than building the layer from the start. If you have five agents today, you are in the window. If you have thirty, you are already paying the tax.
Which is why the diagnostic below matters. Run it this week.
Pick one definition your business actually argues about. Active customer. Qualified lead. Recognized revenue. Something whose interpretation carries real money, where the sales team, the finance team, and the analytics team are known to disagree.
Count the places it lives. Really count. Include the CRM. Include the semantic layer. Include the BI tool. Include the metric definitions embedded in dbt models. Include the spreadsheet the CFO’s team maintains and the Notion doc the analytics team keeps promising to update. Include the prompt of every AI agent you are already piloting.
Whatever number you get, that is your portability debt on one metric.
Now multiply by the number of agents your team plans to build in the next twelve months. That is what you are on the hook for if the layer underneath your agents cannot make one definition travel to all of them.
And remember what one unit of that multiplication costs. Standing up validated context for a single agent, finding the definitions, getting them agreed, wiring them in, runs 30 to 60 days in most enterprises I have seen. That is the cycle you are signing up to repeat.
One more thing: give the count an owner. In most organizations this lands naturally with whoever already owns data governance, because they already own the definitions. It is one person whose eyes are on the distance, not new headcount.
If the number scares you, congratulations. You just called long.
Long
Enterprise AI is going to run on agents. Lots of them. Some you will build. Some you will buy. Some are already inside tools you are paying for. Salesforce Einstein. Microsoft Copilot. Workday AI. ServiceNow Now Assist. They are already in your environment, already reasoning over your customer data, already answering questions your users are asking them. And every one of them is reading a definition of “active customer” from somewhere. The question is whether any of those somewheres is a place you have signed off on.
The teams that figure this out early are not going to look like they are doing anything special right now. They will just be the ones whose agents scale two years from now, while everyone else is stuck rebuilding the same definitions in slightly different YAML for the third time.
Somebody on your team should have their eye on long.
This article was originally published on the Context & Chaos platform.
Author Connect
Connect with Landon on LinkedIn!
The Cats of Context & Chaos
That’s all for this edition. Stay curious, keep exploring, and see you all in the next one!
About Context & Chaos
Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.
Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.
Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.
Got something on your mind? We’d love to hear from you.
Great read!!!
The 15-to-30-agent inflection point is the detail everyone will skip after doing the Monday diagnostic once and shelving it, because agent six still works fine. That's exactly the trap - the tax doesn't announce itself until you're already deep enough that retrofitting costs more than building it right the first time would have. The part I'd want pressure-tested: you list MCP, a semantic layer API, a file protocol, and a direct query interface as interchangeable delivery mechanisms. Are they actually interchangeable in practice, or does picking the wrong one now just relocate the lock-in from "which platform" to "which delivery protocol" - the same walled-garden problem one layer down?