Methodology
A design methodology for the digital workplace. It starts with the people doing the work and the customers on the other end of it, it closes the loop around every interaction, and it produces a number.
Its foundation is the Universal Context Layer.
The full argument runs below, about ten minutes.
01. The wrong question
That question was interesting in 2023. It’s close to irrelevant now.
Frontier models are good enough for the overwhelming majority of enterprise workflows, and the gap between the best model and the third best narrows every quarter. Yet agent pilots keep stalling somewhere between the demo and production, and the reason has almost nothing to do with the model.
The binding constraint is context. An agent is only as capable as what it can see, remember and act on. A brilliant underwriting agent that can’t reach the customer’s banking history or the current compliance checklist isn’t a brilliant agent. It’s an expensive one.
So the useful question isn’t which model is smartest. It’s whether your enterprise can carry context across the systems, teams and time that a real workflow spans. That’s a digital workplace question before it’s an AI question, and the people doing the work feel the answer long before the board does.
The thing that carries that context across the business is the Universal Context Layer. It’s the part of this most often assumed and least often built, and it’s where agent programs tend to come apart in practice. Everything that follows on this page describes what has to be true around it.
02. The friction tax
You’ve seen this one. The expensive CRM the sales team quietly refuses to use because it adds ten clicks to their day. The service bot that deflects a fifth of the calls and annoys exactly the customers you least wanted to annoy.
Every time a person moves data between systems, re-explains a situation, rebuilds context after a handoff, or reconciles two records that should agree, the organization pays. Individually these look like minor annoyances. In aggregate they’re an operating cost nobody has named. Designing purely for business outcomes, without accounting for the human in the middle, is what introduces the friction in the first place.
It’s worth naming as a tax rather than as friction because a tax is paid whether or not you notice it, it compounds, and it’s calculable. Treating it as a cost rather than a frustration also changes who is responsible for it. Frustration belongs to the people doing the work. A tax belongs to the person who signs off the operating budget.
03. Three outcomes, one system
The flow premise is that durable growth requires solving for the customer and for the employee at the same time. Most organizations treat these as competing budget lines. They’re one system, and friction shows up in both ends of it for the same underlying reason.
Modernization often makes work harder. People swivel between disjointed applications and act as the manual glue between systems that were never introduced to each other. The question the methodology asks of any tool is blunt. Does this simplify someone’s day, or does it demand more data entry?
To a customer, flow looks like recognition. A bank that knows exactly where you’re in a mortgage application behaves differently from one that treats you as a stranger. Nobody should have to re-explain their situation because two of your systems can’t talk to each other.
Prioritizing the first two accelerates the third. Remove employee friction and adoption rises. Remove customer friction and retention rises. Growth becomes the output of a well designed system rather than the number you aim at directly.
This is why the methodology sits in the digital workplace rather than in AI infrastructure. Customer experience has become the rallying workflow across the industry, and it’s where the cost of friction is most visible. But the plumbing underneath serves people at both ends, and it only matters because of who is standing there.
04. Why agents raise the stakes
Fragmented systems have always cost money. What changes with autonomous agents is the speed at which that cost accrues.
People quietly work around broken systems. They know the CRM figure is stale, that the address in billing is the right one, that the ticket needs a note before it goes to the next team. That work is invisible, unpaid and, until recently, load bearing.
Drop a fast agent into that same setup and it will produce confidently wrong output at machine speed, and it will do it across every workflow you connected it to. You don’t get automation. You get your existing disorder, scaled.
This is the practical reason to measure friction before deploying agents rather than after. The Friction Tax is a readiness measure before it’s an efficiency one.
05. Context alone isn’t enough
The obvious reading of everything above is that agents need more context, so the fix is to connect more systems and open more data. That reading is wrong, and it’s expensive. Context has to carry four properties before it’s safe to act on.
It has to be true. An agent working from confidently wrong data doesn’t hesitate. It commits. Ground truth isn’t the same thing as data access, and connecting a second system that disagrees with the first just hands the agent two versions of the customer and no basis for choosing between them.
It has to be governed. An autonomous agent scanning a corporate network will eventually find the unsecured payroll file or the confidential merger folder. Deploying agents without hard boundaries isn’t a speed advantage, it’s a compliance incident with a delay on it. Perimeter defense doesn’t help, because the agent is already inside. The workable posture is identity first, where an agent receives the exact context the task requires and nothing beyond it.
It has to be accountable. Organizations have always required that a human employee be able to explain a decision. The same standard now applies to agents. If a supervisor or an auditor can’t reconstruct what an agent read, who authorized it and what it did, you don’t have an agent in production. You have an unlogged actor with write access.
It has to be sovereign. Governance decides who’s allowed to see a piece of context. Sovereignty decides where it’s allowed to exist at all, and whose law can reach it. That’s really three questions wearing one word. Where the data sits, whose courts can demand it, and what can be learned from it and carried away.
The third is the one almost nobody is regulating, and it’s the one you already know the feel of. An account manager who ran your biggest relationship for four years leaves for a competitor. No file goes missing. Nothing is copied. Two quarters later it shows up in the numbers anyway, and there was never anything to log.
A model does that without resigning, across every record you gave it, in an afternoon. A dataset that never leaves its region can still give up everything that mattered about it. Not by being copied. By being learned from. Residency governs the records. It has nothing to say about what was learned from them.
So an agent can be correctly scoped, fully audited, sitting in exactly the right region, and still be a sovereignty failure. That also leaves two things I believe in direct conflict, because context should travel with the work and there are borders it must not cross. Where those borders sit, what they cost, and why concentrating knowledge is safer than scattering it, runs in full on the Universal Context Layer page.
Handle governance and sovereignty together and they stop being the things that slow you down. They become the things that let you ship. That’s the difference between a pilot and production.
06. How the architecture runs
Continuous Flow Architecture describes what happens around an interaction, not only inside it. Every interaction has three phases. What separates an architecture that works from one that doesn’t is whether those phases form a loop or sit as disconnected stages.
The architecture carries the organization’s identity, its services, its data and its standard answers, so an agent arrives already fluent in the business it serves. It doesn’t have to be told who the business is at the start of every interaction. The agent shows up ready, in the way a well trained employee shows up ready.
When the work needs human judgment, the architecture delivers the full context to the person taking over. The customer never repeats the story and the employee never starts from scratch. The handoff is the moment where most deployments quietly fail, and it’s where this architecture earns its keep.
Analytics on what actually happened surface the gaps, and the architecture closes them over time. It becomes fluent in how the business is changing rather than how it looked on the day it was configured. Tomorrow’s agent knows more than today’s, and so does tomorrow’s employee.
Read the full breakdown of the Universal Context Layer, which is where most agent programs actually come apart.
The third phase is what makes the architecture continuous. Without it you have automation that ages from the day it ships. The pillars that follow are what has to be true underneath for the loop to close at all.
07. What has to be true underneath
The three outcomes are what you’re trying to achieve. These three pillars are what has to be true underneath for the outcomes to be reachable at all. They’re framed as failure modes rather than aspirations, because a model that only describes the destination can’t tell you where you are.
Does intent, state and history survive across tools, agents and time? The test isn’t whether records exist. It’s whether the reasoning survives. If a workflow hands off and the next system starts blank, or a user returns two days later and can’t resume, or a supervisor can’t reconstruct why an agent did what it did, context isn’t persisting.
Can agents reach ground truth without a human bridging, reconciling or guessing? This covers whether authoritative data exists at all, how quickly changes propagate, whether agents can write back or only read, and whether there’s a semantic layer defining what fields actually mean. Read-only agents working on stale data are demonstrations, not deployments.
Can the system decompose a goal and execute across vendor boundaries without a person stitching the steps together? This is where deterministic workflow automation gets mistaken for agentic execution. Automation follows a path. Orchestration adapts when the path breaks.
Most enterprises are uneven across the three, and the unevenness is the useful finding. An organization strong on data and weak on context fails differently, and needs different work, than one with the reverse profile.
08. What it produces
Each pillar is scored against five observable questions. The result is a position on four bands.
Not yet ready for agentic deployment. Agents will accelerate errors rather than outcomes.
Pockets of flow exist but the pattern hasn’t scaled. The tax concentrates at department and vendor boundaries.
The architecture works in parts of the business. Remaining friction is specific and identifiable. Ready for multi-agent workflows in contained domains.
Continuous execution. The differentiator becomes operational speed, and the discipline becomes keeping it that way.
Everyone has been on both ends of this. You explain the whole situation, you get passed to somebody else, and the first thing out of their mouth is “so tell me what’s going on.” Or you’re the one receiving it, you can tell there’s a history somewhere, you can’t get to it, so you ask.
Nothing was lost. It just didn’t travel. That moment is the thing being counted.
Take one workflow and follow five real jobs through it, start to finish. Every time the work changes hands, that’s a handoff. Every time the person picking it up has to rebuild something the business already knew, the work is being done twice. Then say it as a sentence.
That’s the finding. What it costs you follows from there.
Anybody in that process can argue with that number on the spot, which is the whole point of it. A statistic can be built to say almost anything. You can’t talk people out of remembering how many times they were asked the same question.
One boundary, because somebody always asks. If two systems pass work between them cleanly and nobody has to touch it, that isn’t a handoff. If a person had to move it along, it is.
Then there’s what it costs, and I keep the two kinds apart on purpose.
The rework I’ll price. Somebody rebuilding what you already had is paid time. Multiply it out across a year of cases and you have a real figure with the assumptions written down next to it.
The waiting I won’t price. I’ll tell you the work sat for six days and I’ll leave it there. What six days costs depends on whether you’re losing orders, losing patience or losing the customer, and you know that better than I do. This is the spot where every other model puts a multiplier. It’s where the enormous impressive number comes from, and it’s why nobody believes those numbers.
Friction shows up differently depending on where you’re standing. A hospital’s handoffs aren’t a bank’s handoffs, and a claims process and a campaign brief fall apart in different places. How you count is the same everywhere. What you count is yours.
So the first number isn’t the answer, it’s the starting line. Fix one handoff and count again. The gap between those two numbers is real whether or not anybody knows what normal looks like in your industry. If you want the average for your sector, I don’t have one, and I’d be wary of anybody who says they do.
The pillars and the bands have held steady since I started using them. How the number gets built has sharpened every time I’ve run it against real work, and it will sharpen again. I’d rather do that in the open than pretend I turned up with it finished.
The full assessment is fifteen questions, five against each pillar, and it runs inside an engagement. It returns a position on the four bands, a Friction Tax figure, and a sequenced plan for what to fix first. A shorter nine question version is published openly on the Universal Context Layer page. That one is enough to tell you whether this is your problem. It isn’t enough to tell you what to do about it.
09. Where this has been published
The February 2026 piece named the problem, arguing that agentic AI fails without an architecture of flow. Continuous Flow Architecture is that architecture, specified.
Tell me what you’re trying to decide and I will tell you where you sit across the three pillars, 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.
