Continuous Flow Architecture
The connective tissue underneath Continuous Flow Architecture. It sits below the applications, gives agents and people a common language for the same work, and decides what any given agent is allowed to know.
The full argument runs below, about ten minutes.
01. What it’s
Most enterprises respond to an agent project by connecting more systems. More connectors, more integrations, more data made reachable.
That instinct is understandable and it produces a mess, because access isn’t the same thing as context. An agent that can reach forty systems and can’t tell which of them is right about the customer isn’t better informed. It’s more confidently wrong.
A Universal Context Layer sits beneath the applications rather than beside them. It bridges systems that were never designed to speak to each other, and it gives autonomous agents and human workers a common language for the same piece of work. Where an integration moves records between two named systems, this layer holds the meaning of the work itself. The intent, the state, the history, and the permissions that any participant in a workflow needs before acting.
The distinction has a commercial edge to it. Integration projects are scoped by system, which is why they never finish. A context layer is scoped by workflow, which is why it can.
02. The problem it solves
Ask most enterprise agents to pick up where the last one left off and they can’t. Each interaction starts from nothing. The customer explains the situation again. The next system in the chain receives a record but not the reasoning behind it. A supervisor reviewing a decision three weeks later finds an outcome with no trail underneath it.
I call this Agent Amnesia. It isn’t a flaw in any particular product, and swapping vendors doesn’t fix it. It’s what happens when context lives inside applications rather than underneath them. Every application holds its own fragment of the story and none of them holds the thread.
People have always compensated for this quietly. They remember that the figure in the CRM is stale, that the address in billing is the one to trust, that the ticket needs a note before it moves on. That compensation was invisible, unpaid, and until recently it was load bearing. Agents don’t compensate. They execute.
03. It has to be true
Data fragmentation is the roadblock enterprise leaders name first, and decades of disjointed data management are why. Intelligence sits trapped in silos that each believe they’re authoritative.
Gartner is blunt about the scale of it. Sixty three percent of organizations either don’t have, or aren’t sure whether they have, the right data management practices for AI, based on a survey of 1,203 data management leaders. Gartner predicted in February 2025 that through 2026, organizations would abandon 60 percent of AI projects not supported by AI ready data. That forecast window is closing now, which makes it checkable rather than speculative, and worth checking against your own portfolio before you commit to the next project.
Relying on disconnected databases doesn’t slow an agent down. It lets the agent hallucinate at speed and with complete composure, which is considerably worse than a system that simply fails.
Contextual Ground Truth is the requirement that the layer resolve disagreements rather than pass them downstream. Connecting a second system that contradicts the first hands the agent two versions of the customer and no basis for choosing between them. Somewhere in the architecture, something has to decide which one is true, and that decision has to be inspectable afterwards.
This is also where the semantic question lives. A field called status means four different things in four different systems. Until the layer knows which meaning applies to this workflow, the agent is guessing in a way that reads, on screen, exactly like knowing.
04. It has to be scoped
An autonomous agent scanning a corporate network will eventually reach the unsecured payroll folder or the confidential merger documents. Not through malice. Through diligence. It was asked to find relevant information and it did exactly that.
Deploying agents without hard operational boundaries isn’t a speed advantage. It’s a compliance incident with a delay on it. Perimeter defense doesn’t help here, because the agent is already inside the perimeter and holding credentials you gave it.
The workable posture is identity first. An agent receives the exact context the task requires and nothing beyond it, and the layer authenticates every request dynamically against the active workflow rather than handing the agent a standing role it keeps between tasks. Scope the context to the task and the blast radius of any single failure stays small.
Done this way the boundary becomes part of how the agent works, rather than a gate somebody has to stop it at. Scope is cheap to enforce at the moment of a request and expensive to reconstruct afterwards.
05. It has to respect borders
Sovereignty gets used as one word for three separate questions. They fail independently, and an architecture can pass the first two cleanly while losing badly on the third, which is roughly where most enterprises are standing right now.
Residency is geographic. Where the servers physically are. It’s the easiest of the three to satisfy, the easiest to audit, and it’s most of what the regulation actually regulates.
Jurisdiction is legal. Which government can compel access through its courts. Residency doesn’t settle this. Storing European customer data in Frankfurt satisfies residency and does nothing about sovereignty if the company that would receive the legal order is incorporated somewhere else. This is the distinction blurred most often, usually by people selling infrastructure, and usually not deliberately.
Extraction is epistemic. What can be learned from context and carried away. Nothing has to cross a border for this to happen, which is why almost no regulation addresses it, and every enterprise already knows how it feels. An account manager of four years leaves for a competitor. No file goes missing, nothing is copied, and the loss is real enough to show up in the numbers two quarters later. There’s nothing to log. Organizations have always absorbed that quietly as a cost of employing people.
A model does the same thing without resigning, across every record you gave it, in an afternoon. A dataset that never leaves its region can still surrender everything that mattered about it, through inference, through embeddings, through fine-tuning that leaves a model measurably different than it was before it saw your data. Residency governs the records. It has nothing to say about what was learned from them.
The first two are compliance problems, with owners and deadlines and auditors. The third is a strategy problem, and there’s no regulatory backstop arriving for it any time soon.
Once agents are in the picture this matters far more than it does for a database, because agents move. A record sitting still in a compliant region is a simple problem. A workflow that reads that record, enriches it against a model hosted elsewhere and writes the result back has moved that data three times and quite possibly crossed a border doing it. The movement is the exposure, and it happens at machine speed with nobody approving each step.
Where the thinking happens is a separate question from where the data lives. A record can sit still in a compliant region for its entire life while every decision made about it happens on infrastructure somewhere else. Residency is satisfied. The inference was never resident at all. This is becoming the binding version of the problem rather than the theoretical one, because specialized compute is scarce and unevenly distributed, so the region holding your data frequently doesn’t have the capacity to reason over it. An architecture that treats model location as an implementation detail will find out it was a jurisdictional one.
The context layer is the only sensible place to enforce this. Residency rules written into individual integrations, or applied at the network edge, drift out of alignment within a quarter and nobody notices until an audit. The layer already knows which jurisdiction a piece of context belongs to, which models are permitted to process it, and where a result may be written. It can refuse at the point of request rather than flagging the breach six weeks later in a report.
For an organization operating across several regions, the design goal isn’t one policy applied everywhere. It’s one architecture that can hold several policies at once. A customer should be able to arrive through any channel in any region and be recognized immediately, while the context behind that recognition stays inside the boundary the law draws around it. Those two requirements only coexist if the boundary travels with the context rather than sitting in a document somebody wrote during procurement.
If the context layer is where sovereignty gets enforced, then who controls the layer is itself a sovereignty question, and it’s the one least often asked. A layer operated by a vendor puts the enforcement point inside the party you would be enforcing against. That isn’t an accusation of bad faith. It’s a structural observation, and it holds even when everybody involved is honest, because a constraint you can’t inspect is a constraint you can’t rely on.
The practical test isn’t whether the vendor is trustworthy. It’s whether you could demonstrate a violation without their cooperation, and whether you could leave. Exit capability belongs in the same conversation as jurisdiction. An organization that can’t realistically replace a platform has already ceded something, whatever the contract says about who owns the data.
It would be convenient to end this section by saying the architecture solves it. It doesn’t. Full sovereignty means running your own models on your own infrastructure under your own law, and that is available to governments, to a handful of very large enterprises, and to almost nobody else. Everyone else is buying capability somebody else built faster and cheaper, and accepting a dependency in exchange.
That trade is frequently the right one. What isn’t defensible is making it without knowing you made it. The useful question for most organizations isn’t how to become sovereign. It’s which specific pieces of context they can’t afford to lose control of, and whether the architecture treats those any differently from everything else. A deliberate dependency is a strategy. An unexamined one is an exposure with a delay on it.
Everything else on this page argues for gathering context into one layer. It’s worth being honest about what that does to the extraction problem, because the objection is a real one and I would rather make it myself than wait for it.
A context layer concentrates knowledge by design. Resolved truth, connected history, meaning that holds across systems. Every property that makes the layer valuable to an agent is a property that makes it worth taking. Building one doesn’t create the risk, because the knowledge was always in the business, but it does gather it, organize it and make it legible, which is a materially easier thing to extract than forty disconnected systems that disagree with each other.
The answer isn’t to leave it scattered. Scattered knowledge isn’t protected knowledge, it’s unobserved knowledge, and it leaks continuously through every integration nobody is watching. Concentration is the precondition for observation. The layer is the only place in the architecture that can know what was read, by which model, under whose jurisdiction, and what was derived from it. Fragmentation doesn’t prevent extraction. It prevents you from ever finding out that it happened.
That only holds if the property is designed in. A layer assembled accidentally out of connectors concentrates the knowledge and delivers none of the visibility, which is the worst available outcome and the most common one.
The EU’s Digital Omnibus on AI entered into force on 27 July 2026, deferring the AI Act’s high risk obligations for standalone systems to 2 December 2027, and to 2 August 2028 for AI embedded in products already covered by EU product safety law. Read that carefully before relaxing. The deadline moved. The architecture problem didn’t. Organizations that treat the deferral as permission to postpone data governance will reach the new date with the same fragmented systems and considerably less time to fix it. And note what none of it addresses. Residency law asks where the data sits, and the AI Act asks how systems are classified and disclosed. Neither one asks what a model retained from your data once the processing was over.
06. It has to route
Routing a simple record lookup through a frontier model wastes processing power and money, and at enterprise volume it wastes a great deal of both. A model trained narrowly on your own data can execute a narrow workflow for a fraction of the token budget.
This changes how the spending has to be understood. Token consumption behaves like a utility bill, not a license fee. Finance teams that book it as a standard software line item will forecast badly and be surprised quarterly, because the cost scales with how much work the agents actually do rather than with how many seats you bought.
A multi-model setup is the sensible end state, with a frontier model for the hard reasoning and smaller specialized models for the routine volume. That’s only practical if something holds the context centrally and hands each task to the cheapest model capable of finishing it. That something is the layer.
07. It has to translate
Marketing runs one model, engineering runs a different coding assistant, service runs whatever came bundled with the contact center. That isn’t disorder, it’s the normal shape of a large enterprise, and it isn’t going to resolve itself into one platform.
Vendors have always had an incentive to build closed ecosystems, because trapped data is retained data. Open protocols push the other way, and standards like the Model Context Protocol exist precisely because the demand for universal connectivity became impossible to ignore.
I have watched this argument before. From my early days at Gartner covering messaging and collaboration, interoperability was the thorny problem that hampered every workflow that crossed a boundary, whether that boundary was between departments or between companies. It’s the same problem again, with agents acting on it at speed and with authority.
The layer is the universal translator across all of it. It gives disparate agents and legacy databases a shared language, and it means replacing a model vendor is a configuration change rather than a rebuild. The standards have moved quickly. The Model Context Protocol connects agents to tools and resources. Google Cloud published the Open Knowledge Format in June 2026, which goes a step further and specifies how the knowledge itself gets written down, as plain Markdown with structured metadata that any agent can read without a translation step.
There’s a serious objection to all of this and it isn’t a technical one. Giving a layer away is a strategy rather than generosity. The pattern is old and well documented. Whoever gives away the complement makes the scarce thing standing next to it more valuable, which is why Chrome and Android were free, and it’s a reason to look carefully at who is publishing the standards for how your knowledge gets written down.
Follow that through and the conclusion is uncomfortable. If every organization ends up expressing its knowledge in the same open format, context stops being scarce. Context that isn’t scarce isn’t an advantage. The scarce thing left in the stack is the model that reads it, and the companies publishing the formats are also the companies selling the models.
I think that is right about the industry and incomplete about the enterprise, and the two keep getting collapsed into a single claim.
Open context formats do two opposing things at the same time. They raise your leverage against any single model vendor, because substitution stops being a rebuild and starts being a decision. They lower the leverage of enterprises collectively against the model layer as a category, because standardized abundant context is worth less than scarce proprietary context. A company negotiating a renewal next quarter is helped by this. An industry negotiating with the model layer over the next decade isn’t. Both are true, and which one you’re living in depends on the timescale you’re budgeting against.
What the argument leaves out is the alternative. Refusing to make knowledge readable doesn’t preserve a moat. It preserves inaccessibility, and it does so while competitors who did the work compound the benefit. There was never a version of this where the knowledge stayed valuable and unread. So the question was never whether to open the knowledge. It’s which knowledge, and almost nobody is asking that one deliberately.
Most organizations hold a small amount of context that is genuine advantage and a very large amount that merely feels sensitive. Treating the two identically is the actual failure. The first belongs inside a boundary, processed by models you control, and it can be worth accepting a less capable model to keep it there. The second belongs in the open format, because the cost of it being cheap is far lower than the cost of your agents being blind. An architecture that can’t tell those apart will default to one or the other, and both defaults are wrong.
08. What it’s for
It would be easy to read the preceding sections as an infrastructure argument. It isn’t. Every one of those properties exists so that a person on either end of the work has a better time of it.
Give an employee instant, trustworthy context and the job changes shape. They stop being the manual glue between systems that were never introduced to each other, and they stop spending their day searching across applications for something that should have arrived with the request. What’s left is the work that actually needed a human, which is the judgment, the empathy, and the decisions somebody has to be accountable for.
On the other side, the customer stops repeating themselves. That’s the whole of it. A customer can’t see your architecture and doesn’t care about it, but they can tell instantly whether you remembered them.
09. How to tell whether you have one
Most organizations that believe they have a context layer have a set of integrations and a naming convention. These questions separate the two.
When a workflow hands off, does the next system start with the reasoning, or only with the record?
When two systems disagree about the same customer, does something resolve it, or does the agent simply pick one?
Can you state what a specific agent was permitted to see last Tuesday, and reconstruct why?
Do your agents write back into systems of record, or only read from them?
Is there a semantic definition somewhere of what your fields actually mean, or does each system hold its own?
Can you route a routine task to a cheaper model without rebuilding the workflow around it?
If you replaced your primary model vendor next quarter, what breaks and how long does it take?
Can a customer resume something two days later without explaining it again from the start?
Does your architecture know which jurisdiction a piece of context belongs to, will it refuse to process it outside that boundary without a person having to notice, and can you say what a model learned from it?
If you can’t answer at least six of these cleanly, you don’t have a context layer. You have integrations, and integrations don’t survive contact with an autonomous agent.
These nine are the public version. The instrument I run inside an engagement is fifteen questions, five against each of the three pillars, and it produces a scored position, a Friction Tax figure and an order of operations. These nine are enough to know whether you should be worried. Working out what to do first needs the scored version, and somebody to argue with about the answers.
10. Where this argument was published
This page develops the argument made in CIO.com in April 2026. The February piece sets up the problem it answers.
Bring me the nine questions above and your honest answers to them. I will tell you which of the three pillars is your weakest, which failure mode you’re most exposed to, and what the first fix should be.
The first conversation runs thirty minutes and carries no charge. Paid work is scoped from there.
