Continuous Flow Architecture

The Universal Context Layer

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.

01. What it is

It is not a database. It is the layer that decides what an agent knows.

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 is not the same thing as context. An agent that can reach forty systems and cannot tell which of them is right about the customer is not better informed. It is 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

Agent Amnesia is the default condition, not a defect.

Ask most enterprise agents to pick up where the last one left off and they cannot. 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 is not a flaw in any particular product, and swapping vendors does not fix it. It is 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 do not compensate. They execute.

03. It has to be true

Contextual Ground Truth is not the same thing as data access.

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 are authoritative.

Gartner is blunt about the scale of it. Sixty three percent of organizations either do not have, or are not sure whether they have, the right data management practices for AI, based on a survey of 1,203 data management leaders. Gartner goes further and predicts that through 2026, organizations will abandon 60 percent of AI projects that are not supported by AI ready data. Those figures are worth sitting with, because the same organizations are spending heavily on models.

Relying on disconnected databases does not 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

The naked agent will find the payroll file.

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 is not a speed advantage. It is a compliance incident with a delay on it. Perimeter defense does not 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

Residency is where the data sits. Sovereignty is whose law can reach it.

These two get blurred constantly, usually by people selling infrastructure. Residency is geographic and concerns where servers physically are. Sovereignty is jurisdictional and concerns which government’s courts can compel access. Storing European customer data in Frankfurt satisfies residency. It does not settle sovereignty if the company that would receive the legal order is incorporated somewhere else.

For an agent estate 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.

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 is not one policy applied everywhere. It is 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.

Where the regulation stands, as of July 2026

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 did not. Organizations that treat the deferral as permission to postpone data governance will reach the new date with the same fragmented estate and considerably less time to fix it.

06. It has to route

Not every question deserves a frontier model.

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 estate is the sensible end state, with a frontier model for the hard reasoning and smaller specialized models for the routine volume. That is 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

No single vendor is going to own your agent stack.

Marketing runs one model, engineering runs a different coding assistant, service runs whatever came bundled with the contact center. That is not disorder, it is the normal shape of a large enterprise, and it is not 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 is the same problem again, with agents acting on it at speed and with authority.

The layer is the universal translator in that estate. It gives disparate agents and legacy databases a shared language, which is also the only credible defense against lock-in, because it means replacing a model vendor is a configuration change rather than a rebuild.

08. What it is for

The point of all this is a person who no longer has to go looking.

It would be easy to read the preceding sections as an infrastructure argument. It is not. 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 is 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 is the whole of it. A customer cannot see your architecture and does not care about it, but they can tell instantly whether you remembered them.

09. How to tell whether you have one

Nine questions. Answer them honestly.

Most organizations that believe they have a context layer have a set of integrations and a naming convention. These questions separate the two.

01

When a workflow hands off, does the next system start with the reasoning, or only with the record?

02

When two systems disagree about the same customer, does something resolve it, or does the agent simply pick one?

03

Can you state what a specific agent was permitted to see last Tuesday, and reconstruct why?

04

Do your agents write back into systems of record, or only read from them?

05

Is there a semantic definition somewhere of what your fields actually mean, or does each system hold its own?

06

Can you route a routine task to a cheaper model without rebuilding the workflow around it?

07

If you replaced your primary model vendor next quarter, what breaks and how long does it take?

08

Can a customer resume something two days later without explaining it again from the start?

09

Does your architecture know which jurisdiction a given piece of context belongs to, and will it refuse to process it outside that boundary without a person having to notice?

If you cannot answer at least six of these cleanly, you do not have a context layer. You have integrations, and integrations do not 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.

Find out whether your context layer is real.

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 are most exposed to, and what the first fix should be.

The first call is free and runs thirty minutes. Paid consultations and workshops are available when you want to go deeper.