Picture a company that did everything right.
It negotiated the right contract, with the exit clauses in the right places. When it decides to change AI provider, the export works: the documents come back, the conversations come back, the configurations come back, every single byte accounted for. The old provider behaved impeccably, not least because the law left it no alternative.
Three weeks later, somebody notices.
The new agent has everything and it is as if it knows nothing. It proposes again the change to the legacy module that the old system had learned not to touch without a specific check. It repeats the invoicing mistake that had been corrected in March, and again in April, and then never again. It asks for explanations of an exception nobody ever wrote down anywhere, because there was no need: the system knew it.
The company exported everything. And discovered, at that precise moment, that it had not taken away the thing that mattered most.
Grant the objection in full
Before building an alarm, a lot of ground has to be conceded to a serious objection: we already know the portability problem, and Europe is tackling it in anything but a naive way.
The Data Act, applicable since 12 September 2025, does not settle for proclaiming a generic right to get your data back. For data processing services within its scope it requires the removal of technical and contractual obstacles to switching provider. It speaks of exportable data and, interesting category, of digital assets. For certain classes of service it introduces an ambitious concept: functional equivalence, the idea that after switching, the destination service should be able to do substantially what the original one did. And from 12 January 2027 switching charges disappear entirely.
It is a far more sophisticated regulatory answer than the caricature in which Brussels is still regulating the cloud with twentieth-century categories. And the push continues: the technology sovereignty package presented on 3 June 2026 declares as its goal Europe’s capacity to develop and control strategic technologies, data and infrastructure while reducing dependencies on non-European suppliers, and a dedicated consultation on data sovereignty, open until 8 September, is mapping the dependencies that concretely limit European organisations’ ability to use and transfer their own data.
I have written more than once that sovereignty does not live in the data centre, and this policy seems to have understood that better than many of its critics. It does not confuse sovereignty with autarky. It does not demand that everything be European. It demands that dependency be reversible, which is the right demand.
And this is exactly where the problem bites.
While we learn to make data portable, the object of our dependency is changing.
The third object
With traditional software it was reasonable to think that the essential part of a system consisted of two things: the software and the data it operated on. You could change database, cloud or application, and the fundamental problem was preserving the information together with the capacity to process it. The whole discipline of portability, contracts included, is built on that pair.
With agents a third object appears, and it is much stranger: the state the system has accumulated while working.
It is not the conversation history, which exports without difficulty and is worth little. It is what the agent has learned to consider relevant. It is the syntheses built from past interactions, the conventions it treats as reliable, the relationships between entities it has inferred, the corrections received over time and absorbed. Into this state go organisational instructions, the provenance of information, rules that determine which tools to use in which circumstances.
This is not paper-ware abstraction. Microsoft now explicitly describes agent memory as something that does not merely store information but alters the system’s future behaviour, including its tool calls. And in June 2026 its security team added an observation worth more than a season of conferences: persistent memory changes the threat model. An attacker no longer needs to succeed in a single interaction; they can try to gradually alter what the agent will remember and use later. The most sensitive part, Microsoft writes, is procedural memory, the kind that can remember when a procedure applies, which checks can be skipped, which tool should be used.
Stop on that sentence, because it already contains half the essay. If procedural memory is the most dangerous to poison, that is because it is the most powerful. And if it is the most powerful, it is also the most expensive to lose.
A transformation, not an archive
Here sits the conceptual point that the portability debate has not yet brought into focus.
An agent’s memory is not a database. It is a transformation of the database.
Two organisations could hold exactly the same documents and have completely different agents, because those systems learned to treat different parts as important. Or because they consolidated past conversations differently. Or because one learned that a certain company exception overrides the standard procedure and the other did not.
Research on agent memory all points the same way: not integral archives of conversations, but systems that consolidate past interactions into reusable knowledge. The value does not lie in what was said. It lies in what the system made of it.
Traditional digital sovereignty asks: can I take my data away?
The question of the agentic era is different: can I take away what the system has learned from my data?
That is not a semantic nuance. It could become one of the most powerful forms of lock-in of the coming years.
One year in
Take a software house that uses an agent daily across dozens of repositories. It is the scenario I know best, and it has the virtue of being measurable.
At the start the agent receives the code and some instructions. A year later, it holds a far richer representation of the organisation. It knows certain legacy components are not to be touched without a specific check. It has met the recurring errors of that codebase, not recurring errors in general. It has absorbed thousands of human corrections, each of which was a small act of training that nobody logged as such. It knows exceptions that the documentation formalises badly or not at all, because real organisations work that way.
If tomorrow that software house changes provider, the repository transfers. The documentation transfers. The issues transfer. The Data Act, where it applies, will guarantee that all of this happens without obstacles and soon without charges.
But will the new agent be where the old one was?
No. It will be at day one, with a year of corrections to redo. And every redone correction is a cost no contractual clause has ever named.
Context sovereignty
This thing needs a name, and I propose one with the caution owed to new names: context sovereignty.
I would define it like this: an organisation’s capacity to control, inspect and transfer the informational state that determines the behaviour of its AI systems.
The word «informational» is chosen with care, because it avoids the anthropomorphic metaphor of the mind, which here would be pure noise. I am not claiming the organisation owns an artificial consciousness. I am saying something far more concrete: between the original documents and the agent’s decisions there now exists a persistent layer of transformations, and that layer can become economically as precious as the documents themselves.
The moment makes the question less theoretical than it sounds. In the data OpenAI published on 12 August, agentic traffic measured through Codex accounted in June 2026 for 64% of the combined output tokens produced by Codex and ChatGPT among enterprise customers. In the same dataset, weekly active Codex users outside engineering grew since February by 108 times in legal and 41 in recruiting, against 5 in engineering. It is not a measure of the whole market, and it should be read for what it is, one vendor’s data about its own customers. But the signal is unambiguous: work delegated to agents is growing faster than work merely assisted.
And the more work is delegated, the more the context accumulated by whoever performs it is worth.
The interoperability paradox
The paradox is that all this is happening while agentic infrastructure becomes more interoperable, not less.
MCP sits under the governance of the Linux Foundation’s Agentic AI Foundation, together with AGENTS.md. A2A is building a standard so that agents from different vendors can talk to each other. The foundation announced in mid-August that it has reached 247 member organisations, with names running from finance to platforms. Open standards are making real progress, and anyone dismissing them as paper conventions has not watched the speed at which they are becoming infrastructure.
But look at what they standardise. MCP describes how an agent reaches Jira. A2A lets two agents converse. AGENTS.md makes some project instructions portable. They are, in a single word, the agent’s body: its interfaces, its protocols, its tools.
None of these mechanisms guarantees that the new agent will hold the previous one’s operational state.
The possible outcome is an ecosystem perfectly interoperable at the surface, in which switching models is technically trivial and organisationally ruinous. The body can be replaced in an afternoon. The memory stays where it was.
It is a far subtler form of lock-in than the cloud’s, and it deserves saying without circumlocution: it does not stop you leaving. It makes you stupid when you leave.
The employee who leaves
The right metaphor does not come from computing. It comes from human resources.
An organisation can hold every document a person ever produced and still lose an enormous amount of knowledge when that person walks out. Not because they took files with them. Because there is a difference between owning the archive and knowing how the archive is to be read: which documents are obsolete even though nobody marked them obsolete, which exception overrides which rule, why that 2019 decision is still done that way.
For centuries we have called this tacit knowledge, and we have accepted that it is an attribute of people. Agents are industrialising it. What used to evaporate with a resignation now accumulates in a system, which would seem to be progress, and is progress, until you ask whose system it is.
The analogy also helps avoid the wrong solution. In a human organisation we do not demand a complete dump of a departing employee’s head, and not for lack of technology: because it is the wrong question. We try instead to reduce the amount of critical knowledge that exists only inside that head. We document, we formalise, we run handovers, we write the procedures down.
The same strategy can become an architectural discipline for agents.
Knowledge outside the agent
Here the argument touches how work is actually done, and I can be concrete.
The more organisational knowledge you manage to move from the agent’s implicit behaviour into explicit, versionable artefacts, the less you depend on its private memory. Instruction files like CLAUDE.md and AGENTS.md, architecture decision records, formal specifications, even a seriously documented repository: all these objects acquire a new meaning. They are not merely the way to get better answers from this week’s model. They are instruments for reducing cognitive lock-in, because they live in your repository, under your version control, and every future agent will read them the same way.
The principle fits in one line: what matters for the agent’s behaviour should exist, whenever possible, outside the agent.
That does not mean eliminating memory, which is precisely what makes an agent useful compared with a stateless model. It means distinguishing two things that are currently blurred: what the organisation deliberately wants to make persistent, which then deserves to live in an artefact of its own, and what a particular provider has inferred to make its product more effective, which remains, until somebody asks the question, a provider advantage dressed up as a service.
Declared and derived
The distinction between what the organisation persists on purpose and what the provider infers on its own deserves to be taken seriously, because the two memories have different legal and economic natures even when they inhabit the same system.
Declared memory is what somebody wrote. The user tells the assistant: remember that releases happen on Thursdays, that client X wants invoices in that format, that this folder is off limits. These are instructions. They have an author, a date, readable content. If the vendor keeps them in an inspectable form, exporting them is a modest technical problem, and whoever receives them on the other side can reload them almost without loss.
Derived memory is another matter. Nobody ever told the system that this team’s estimates should be taken with caution: it concluded that on its own, after the umpteenth slippage. Nobody wrote that the official deploy procedure gets ignored on Fridays: it observed that. These conclusions have no human author, often no stable textual form, and can be represented in ways that depend entirely on the vendor’s architecture.
The paradox is that derived memory is usually the more precious of the two. Declared memory, by definition, already exists somewhere: someone knew it well enough to dictate it. Derived memory is knowledge the organisation did not know it had, or never found the time to formulate. And it is exactly the memory that, when the contract ends, nobody today can say who owns.
There is a security angle too, and it is why Microsoft’s work on memory is not a specialists’ footnote. A memory that alters future behaviour is an attack surface: whoever manages to poison it does not compromise an answer, they compromise a disposition. But security and sovereignty, here, are two faces of one requirement. To defend the memory you must be able to inspect it, trace the provenance of what it contains, distinguish what entered it and why. Which is, word for word, the same infrastructure you would need to export it. A vendor claiming it cannot make its agents’ state transparent is also saying something about its ability to protect it.
What the Data Act says, and doesn’t
The regulatory part is more interesting than I expected when I began studying it, because the Data Act uses categories surprisingly suited to the problem, despite being born before the problem.
It does not speak only of data: it speaks of digital assets. It requires providers, in the cases foreseen, to specify which categories can be taken along during switching. And for certain classes of service it sets the goal of functional equivalence.
The question to ask is not whether the Data Act already makes agent memory portable: that would be a stronger legal conclusion than text and practice currently allow, and forcing texts is not my trade. The interesting question is another one.
What will functional equivalence mean when the service does not simply perform a function, but accumulates experience?
If I use an agentic service for three years and then replace it, which elements belong to my exportable data and my digital assets? The memories explicitly created by the user, the instructions I wrote myself, look like an easy case. Much less easy is the state built through automatic syntheses, rankings and proprietary inference. And here the regulation contains a boundary that will become contested: information tied to the provider’s internal workings and its trade secrets stays protected. A substantial part of the memory’s value may reside exactly in the proprietary way the provider consolidates it.
The provider’s objection
At this point an honest essay has to give the provider a voice, because its objection is legitimate and dismissing it would be advocacy dressed up as analysis.
If a company develops a better method for building long-term memory, why should it hand the result of its technological edge to a competitor? Interoperability cannot mean that every innovation is standardised at the moment of its birth: that would be the fastest way to stall research in a field that still needs plenty of it.
The answer is not «because sovereignty comes first». Slogan answers do not survive contact with contracts.
The answer is to distinguish the algorithm from the organisational result. There is no need to export the engine with which the provider builds memory. It is reasonable, though, to demand that the organisation can inspect and transfer a sufficiently complete representation of the state that engine has built using its activity, its documents, its corrections.
It is the same distinction we draw, without noticing, between a database and the DBMS. You do not need PostgreSQL’s source code to export a table. How the engine lays out pages on disk is its business; my rows are mine.
The territory opening here has no vocabulary yet: formats for agent memories, provenance of inferences, the distinction between user-declared and derived memory, confidence levels, mechanisms for rebuilding a context at another vendor. I will not propose a standard, because it would be premature and because premature standards do more damage than monopolies.
I propose a criterion.
The questions to ask now
While vocabulary and standards mature, something can be done immediately, and it is updating the questions put to a vendor before signing. I recognise them because they are the questions I have started asking myself.
Does the service accumulate state beyond the session? It sounds trivial, but many contracts do not even allow that one to be answered. If it does, which part is inspectable by the customer, in what form, at what granularity? Which part is exportable, and in a documented format or an opaque dump? Is the state derived from the customer’s activity used to improve the service rendered to others, or does it stay segregated? And at the end of the relationship, what happens: certified deletion, restitution, or contractual silence?
The last question is the most revealing, and it is worth asking in writing: if in three years we want to leave, what will we take with us beyond the data we gave you?
A serious vendor today will answer incompletely, because the problem is new for everyone. But there is an enormous difference between answering incompletely and discovering the question on the spot. The quality of the hesitation, in these conversations, is technical data.
The exit test
The measure of an agentic system’s sovereignty should not only be where it runs, nor only where it keeps the data.
It should be the answer to a single question: if I replace the provider tomorrow, how much organisational capability do I lose?
I wrote a few days ago, about the Digital Markets Act, that the real political content of portability is the price of leaving. Agents add a new line to that price, one no rate card displays: the cost of organisational retraining, the weeks in which the new system repeats the mistakes the old one had stopped making, the exceptions to explain again, the trust to rebuild.
This test also cuts a certain sovereignty-infrastructure rhetoric down to size. Owning European data centres matters. Having European models may matter just as much. But no infrastructure is truly sovereign if the accumulated capacity to use it implicitly belongs to another system. The Commission today defines technological sovereignty as the capacity to develop and control technologies, data and infrastructure while reducing strategic dependencies. Three correct dimensions. The agentic decade adds a fourth, which does not need to become an institutional slogan to be taken seriously: control over context.
And it is a natural continuation, not a break, of the European idea of openness without autarky. Sovereignty does not require owning everything. It requires that the cost of exit not become a form of subordination.
What makes the AI case different from every precedent is the nature of that cost. It is not a penalty, not a fee, not even the famous data migration cost the Data Act is dismantling piece by piece.
It is amnesia.
Who owns the culture
The next digital monopoly may not hold on to our data. It may let us take all of it away, down to the last byte and with a smile, knowing that what really counts is what the system has learned to do with it.
I want to close far from the regulations, because the bottom of this story is not regulatory.
Every organisation holds an enormous amount of knowledge that does not coincide with the documents it produces. It is made of sedimented interpretations, of exceptions understood slowly, of the reasons certain decisions are taken one way and not another even when nobody can quite explain why anymore. For centuries we have called this organisational culture, and considered it inseparable from the people who embody it.
AI is starting to make part of it computational. Interpretations consolidate into memory, exceptions become rules of behaviour, corrections accumulate into a state that steers future decisions. Something that was always everyone’s and no one’s, scattered across heads and corridors, is for the first time taking a technical form: inspectable, transferable, and therefore ownable.
And it is precisely at the moment culture becomes computational that the question stops being technical.
The company in the opening scene had read the contract well. It had counted the bytes. It was missing one line, the line no contract yet contains: at the end of the relationship, what the system has learned from us becomes ours again.
Until that line exists, every successful migration will keep resembling that perfect house move in which all the boxes arrive, and the new house knows nothing about us.
Key takeaways
The Data Act is a more sophisticated answer than its caricature: applicable since 12 September 2025, it requires removing technical and contractual obstacles to switching between data processing services, speaks of exportable data and digital assets, introduces functional equivalence, and from 12 January 2027 bans switching charges. The technology sovereignty package of 3 June 2026 and the data sovereignty consultation closing on 8 September complete the picture: Europe does not demand that everything be European, it demands that dependency be reversible.
While data becomes portable, the object of dependency is changing. Between an agent’s documents and its decisions a persistent layer forms: the syntheses it has built, the conventions it considers reliable, the exceptions assimilated from thousands of human corrections. It is not the conversation log, and it is not a database: it is a transformation of the database. Two organisations with the same documents can have completely different agents.
Microsoft describes agent memory as something that does not merely store information but alters future behaviour, and in June 2026 wrote that persistent memory changes the threat model: an attacker can gradually alter what the agent will remember, and procedural memory, the part that decides which checks to skip and which tools to use, is the most sensitive of all.
The paradox of the moment: agentic infrastructure is becoming interoperable, with MCP, AGENTS.md and A2A under open governance and 247 organisations in the Agentic AI Foundation, precisely while the layer no standard covers keeps growing. You can standardise the agent’s body perfectly while its memory stays proprietary: an ecosystem where switching models is technically trivial and organisationally ruinous. It is a lock-in that does not stop you leaving. It makes you stupid when you leave.
Delegation is accelerating and the value of accumulated context with it: in the data OpenAI published on 12 August, agentic traffic via Codex accounted in June 2026 for 64% of combined enterprise output tokens from Codex and ChatGPT, and weekly active users outside engineering grew 108-fold in legal and 41-fold in recruiting since February. The more work we delegate, the more what the system has learned is worth as much as the documents it learned it from.
The defence is not demanding an export of the agent’s head but reducing what exists only inside it: moving organisational knowledge from implicit behaviour into explicit, versionable artefacts. CLAUDE.md, AGENTS.md, ADRs and specifications stop being merely ways to get better answers: they become instruments for reducing cognitive lock-in. What matters for the agent’s behaviour should exist, whenever possible, outside the agent.
The measure of an agentic system’s sovereignty is not where it runs or where it stores data, but the answer to an exit test: if I replace the provider tomorrow, how much organisational capability do I lose? No infrastructure is truly sovereign if the accumulated ability to use it implicitly belongs to another system. The cost of exit, in AI, may not be economic: it may be amnesia.
Questions & answers
Doesn't the Data Act already solve the portability problem?
It solves the problem it was written for, and more elegantly than the usual telling suggests. For data processing services within its scope it requires removing technical and contractual obstacles to switching, provides for the export of data and digital assets, introduces the goal of functional equivalence for certain classes of service, and from 12 January 2027 abolishes switching charges. The open question is a different one: what will functional equivalence mean when the service does not simply perform a function but accumulates experience? Memories explicitly created by the user look like an easy case. A state built through automatic syntheses, rankings and proprietary inference is much harder, not least because the regulation protects information tied to the provider’s internal workings and trade secrets, and that is exactly where part of the value may sit.
What is an agent's «cognitive state», concretely?
It is not the conversation history. It is what the system has consolidated while working: the syntheses built from past interactions, the conventions it considers reliable, the relationships between entities it has inferred, the corrections received and absorbed, the organisational instructions and the rules that determine which tools to use in which circumstances. Microsoft describes this memory as something that does not merely store information but alters the agent’s future behaviour, including its tool calls. The least anthropomorphic formulation is also the most useful: between the original documents and the agent’s decisions there is now a persistent layer of transformations, and that layer can be worth economically as much as the documents.
Why aren't open standards like MCP and A2A enough?
Because they standardise the agent’s body, not its state. MCP describes how an agent reaches its tools, A2A lets agents from different vendors talk to each other, AGENTS.md makes some project instructions portable. These are real advances, and the fact that MCP and AGENTS.md sit under the governance of the Linux Foundation’s Agentic AI Foundation, which counts 247 organisations as of August 2026, shows that agentic interoperability is becoming infrastructure. But none of these mechanisms guarantees that the new agent will hold the previous one’s operational state. An apparently interoperable ecosystem is possible in which switching models is technically trivial and organisationally ruinous.
Isn't the provider right to protect its memory method?
It has a legitimate objection and it deserves to be taken seriously: if a company develops a better method for building long-term memory, forcing it to hand that to a competitor would mean standardising every innovation at birth. The useful distinction is between the algorithm and the organisational result. There is no need to export the engine with which the provider consolidates memory; it is reasonable, though, to demand that the organisation can inspect and transfer a sufficiently complete representation of the state that engine built using its activity. It is the same distinction we draw between a database and the DBMS: you do not need PostgreSQL’s source code to export a table.
What can an organisation actually do, today?
Apply to agents the same strategy used with people: do not demand a dump of the head of whoever leaves, reduce the amount of critical knowledge that exists only inside that head. In practice this means moving organisational knowledge from the agent’s implicit behaviour into explicit, versionable artefacts: instruction files such as CLAUDE.md and AGENTS.md, architecture decision records, formal specifications, documentation that captures exceptions instead of leaving them to the system’s memory. And it means putting to the vendor a question almost no contract provides for today: which parts of the state the service accumulates are inspectable and exportable, in what format, and what remains of them when the contract ends.
The author
