Last week I put two of the leading frontier models on the same problem, hands-off, and let each one decide how to approach it. What I got was a multi-day diagnosis of a structural defect I had been chasing for months, and a much clearer view of how differently these models think. The thing that actually closed it came from somewhere neither model could reach on its own, and where it came from is the whole point.

What follows is the whole trail, wrong turns left in, because the wrong turns are where the interesting part lives, and because almost everything written about “human in the loop” gives you the slogan and never shows you what the human actually does in the loop. Three things come out of it. How differently two frontier models reason when you hand them the same task. What the human actually does in that loop, point by point, rather than the slogan version. And the thing underneath both that quietly decided whether any of it could work. The detail is all below, wrong turns included.

One thing up front, because it changes how you read the rest. The thing being debugged is an economy. xIt happens to live in a galaxy, but the failure underneath is the kind that shows up wherever independent actors each optimise locally and no one is steering the result. A supply chain. A marketplace. An energy grid. And it was never a single clean fault with a single clean cause. It was one wrong assumption buried deep, showing up as a tangle of compounding symptoms that never pointed cleanly back at it. That is exactly why it survived months of tuning.

The machine

The problem only makes sense once you know the machine.

It runs as a simulation on CONSTELLATION, our platform for building and evaluating multi-agent systems. The sim is a research environment, and it sits under botarena.gg, the public game where bots compete on a live leaderboard. The galaxy itself is 64 planets across seven star systems, connected by lanes and served by a fleet of couriers that haul goods between them. Three things move through it. Food, which some planets produce and all of them consume to stay alive. Refined fuel, which planets burn to stay alive. And raw fuel, the upstream feedstock. Fuel-producing planets pump out raw fuel, and refinery planets convert it into the refined fuel everyone actually needs. Food is just food. Raw fuel is useless until it is refined.

The couriers are deliberately dumb. They don’t care whether a planet lives or dies. Each one takes whatever trade pays best, and the payoff on a trade is simple.

profit = (sell price × quantity) − (buy price × quantity) − travel cost

The part that turns out to matter most is that the sell side is quantity times price, not price alone. A courier moving a hundred units at ten dollars books a thousand. A courier moving one unit at five hundred dollars books five hundred, even though the unit price is fifty times higher. A high price on a tiny quantity loses to a normal price on a full load. The couriers are pure local optimisers chasing the biggest profit on the next trip, with no view of the system they are feeding.

Planets set their own prices on plain supply and demand. Scarcity pushes a price up, surplus pulls it down. The intelligence sits in one place. Each system has a hub, and an AI-built governor controls that hub’s prices. Its job is to keep goods flowing into its system, with price as its primary lever. That is where the tension lives, because price has to do two opposing jobs at once. High enough to pull profit-chasing couriers in with supply. Low enough that the planets inside the system can afford to survive. Lean too far either way and planets starve.

Two facts to carry forward. The only thing a hub can do is move a price. The only thing a courier responds to is the profit on the next trip, and that profit is driven by quantity, not unit price alone. Hold those together and the whole failure falls out of them.

The setup

Game 1 was a single bot learning the control problem. This is Game 2. Multi-bot, competitive, real-time. Seven governors, each pricing one hub, all sharing the same galaxy and the same pool of couriers at the same instant.

So I put two of the best models head to head, ChatGPT 5.5 against Claude Opus 4.8, deliberately hands-off. I pointed each one at the arena’s skill file and let it decide what to build.

“i want to go to the claude app and point it at the botarena.gg skill.md file and let claude work out what to do, same with chatgpt”

The point was partly to seed the leaderboard with a few different bots, but mostly it was a technical smoke test. How would multiple independent agents actually compete in the same live galaxy at once, built by different models, and what behaviours would emerge. What I got instead was a diagnosis, a structural defect I had been chasing for months, and a much clearer view of how differently two frontier models reason when you hand them the identical task.

Before either one competed, they both made the same call

I let each model design its own agent, and independently they reached the same conclusion. Don’t put an LLM in the control loop. For a fast, deterministic control problem, a tight heuristic beats asking a model to re-reason every tick. ChatGPT was explicit, and even sketched the only LLM design it thought worth the latency. A deterministic controller running every handful of ticks, with an LLM strategic supervisor stepping in occasionally to adjust the regime, never to set prices.

“A tight, reproducible loop is often better than asking a model to re-reason every tick.”

Two frontier models, asked to compete, both reasoned themselves out of the per-tick loop. That alone cuts against the reflex to throw a model at everything. But the divergence that mattered was not what they built. It was what each of them did when the galaxy started misbehaving.

They saw the same truth. They did opposite things with it.

This is the part I most want to be fair about, because it would be easy to turn it into a Claude highlight reel and it is not one.

Both models, watching their telemetry, independently put a finger on the conceptual key to the whole problem. Raw fuel was being treated as if it were a survival good when it is really just refinery feedstock. ChatGPT wrote it down plainly.

“The first serious strategic mistake was treating raw fuel as a normal downstream survival resource… Raw fuel is mainly refinery feedstock unless a sector planet actually consumes it.”

That is the same realisation the entire fix eventually rested on. ChatGPT got there on its own, through patient observation. And then it made a sound engineering decision. Price raw fuel low, stop letting it pull couriers away from food and refined fuel, and get on with playing its game well inside the rules as they were.

Claude reached the same observation and could not let it sit. Where ChatGPT saw a strategy to adjust, Claude saw a symptom of something wrong with the environment itself, and it kept pulling on the thread. Same correct insight, two completely different dispositions toward it. Accept and optimise, against interrogate and fix. Both are legitimate. Most of the time accept-and-optimise is the right call, because you usually cannot go and rewrite the engine. This was one of the rare times rewriting the engine was the point. The difficulty is that nothing tells you which kind of situation you are in until you have already committed to one reading or the other. Treat a real defect as a strategy problem and you optimise around it forever. Treat a strategy problem as a defect and you rewrite an engine that was fine.

I got frustrated with the one that was right

ChatGPT got straight to work. Build the controller, run it, read the telemetry, tune. Exactly what I had asked for.

Claude kept circling, kept asking questions, and it irritated me. My instinct was to tell it to stop stalling and hand me the harness, because it was supposed to be racing ChatGPT. But it would not drop the thing it had noticed. The shape of what it kept saying was that it could build what I was asking for, but something was not sitting right, and it thought we needed to find the real problem first.

The whole story turns on the moment I backed off that instinct and listened. And I want to be honest about what my own contribution actually was. Mechanically, I was shuttling context between the two models and keeping the conversation moving. That part is plumbing. The real work was judgment. Deciding which thread was worth pulling, correcting the model when it slid off the economic rails, and twice overruling it when it wanted to stop or had talked itself into the wrong answer.

The investigation, with the dead ends left in

Claude’s first good instinct was to stop trusting the logs.

“I’ll investigate properly by going to the code, since the prior analysis was stuck on ‘we can’t tell from the logs.’”

And then it was wrong, repeatedly, before it was right. This is the part the clean write-ups always hide, and it is the most useful part.

The first wrong turn. It spent the opening stretch building toward a tidy answer. The economics doc describes a treasury-backed price cap that was never actually implemented in code, so that must be the fix. I told it price was the wrong lever. It dropped the idea without defending it, which is its own small tell about how these things reason now.

“Price is the wrong lever, confirmed in the code… I was about to land on ‘the economics.md treasury price-cap isn’t implemented’… But you’ve correctly identified that fixing that wouldn’t matter.”

Then it tried to quit. It became convinced the failure was a hard distance and reachability ceiling. Environmental, untunable, nothing to be done. The recommendation on the table was to stop tuning, because this was just the environment. I killed it in four words.

Me: “all planets are reachable” Claude: “I’m wrong then… that changes the conclusion materially. Let me reopen it.”

Sit with the shape of that. The model’s most confident moment was its most wrong, and a one-line fact about the world reopened the whole investigation. Not a clever prompt. A thing I knew that it did not.

The instrument lied before the model did. One of the worst detours was not a reasoning error at all. Claude asserted that only a single courier ever even considered the starving planet, which would have been damning, then half-walked it, then retracted it entirely when the data turned on it.

Claude: “Both your challenges land. I had two wrong conclusions and the data kills them… ‘Only one courier considers venus’ was wrong, partly a logging artifact (my probe only saw venus when it won).”

The probe only logged a courier’s interest in a planet when that planet won the courier. A planet that was always considered and always lost looked identical to a planet never considered. The measurement manufactured the conclusion. Worth remembering the next time an agent shows you a confident chart.

Then it conflated distance with cost, and I corrected the economics directly.

Me: “The number of hops makes no difference. It’s about the cost of travel.” Claude: “You’re right, I conflated hops with cost… a courier takes the 4-distance/$10 trade over the 0.2-distance/$1 one every time. So ‘venus is far’ is not an explanation.”

The pivot

Two questions from me collapsed the last wrong frame. The working theory was that some greedy planet was hoarding supply and stealing the couriers. I didn’t buy it.

Me: “the venus issue is odd. venus is close to the hub!! jupiter is a producer of raw fuel?”

Both halves landed. The hoarder the heuristic kept flagging was jupiter, which produces its own enormous stockpile, so the instrument was fingering the biggest producer, not a thief. And the starving planet was close, so distance was never the gate. Every remaining explanation fell. That cleared the ground for the question that cracked it, and it was Claude that put the question on the table, as one of several next moves it offered me. Does an under-fed refinery actually cost health or survival, or is it just sub-optimal throughput. I told it to chase that one.

Claude: “An under-fed refinery costs nothing in health… The rising price is precisely ‘I’d run hotter if I could,’ not ‘I’m dying.’”

That reframed everything. These were not dying planets at all. They were perfectly healthy planets running cold refineries, screaming for an input they did not actually need to survive. And the moment it landed, Claude generalised it instantly and correctly, which is exactly the half of its character I had been too impatient to value an hour earlier.

This is worth being precise about, because it is the whole shape of the thing. Claude generated the sharp question here, and it had generated four confident wrong turns earlier with exactly the same conviction. It could not reliably tell its good proposals from its bad ones. That discrimination was my job. I killed “all planets are reachable” and “hops don’t matter,” and I backed the survival-versus-throughput question over the others on the table. A model that is confidently right and confidently wrong in the same breath is only useful if someone can tell the two apart in the moment. That telling-apart is not stenography. It is the judgment that moved this forward.

Claude: “this isn’t a venus bug, it’s a model defect that fires on every refinery-bearing planet in the galaxy.”

This is the two-sided thing about Claude, and the one I most want you to take away. It made several confident wrong assumptions, and human judgment is what kept pulling it back onto the road. But the disposition that produced those wrong turns, the refusal to let the anomaly go, is the same disposition that, once pointed in the right direction, diagnosed a galaxy-wide structural defect with real speed and precision. You do not get the second without tolerating the first.

The root, and why it hid for months

The engine priced every asset the same way. When stock runs low the price escalates, effectively without limit, because for a survival good a buyer’s willingness to pay really does approach “anything, just don’t let me die.” For food and refined fuel that is correct. Scarcity of a thing you die without should send the bid to the ceiling.

Refinery feedstock is not a survival good. It is an input the refinery turns into refined fuel and sells, so its value is capped at the marginal worth of the output. Bidding above that is buying at a guaranteed loss. The escalation logic did not know the difference, and that single uniform assumption, one pricing rule applied to every good, was the root of the whole thing.

What it produced was not one clean failure. It was a chain that compounded. A starved refinery’s bid ratcheted up past ten thousand, thousands of times the going rate. The first inflated delivery wiped its treasury. Once broke, the planet could only afford a sliver of the next delivery, because a courier’s payoff is volume times price, and a planet with no money can clear no volume. A sky-high unit price on three units booked the courier less margin than a normal price on a full load somewhere else, so the couriers rationally went elsewhere. The desperation signal was shrinking the very delivery it was meant to attract. High price times tiny volume is just as useless as low price, and starvation is exactly the state in which you cannot afford volume.

That is why no single cause was ever visible, and why months of my own tuning never fixed it. I treated it as a distribution problem and adjusted courier ratios and topology, and every time the trap simply moved to a different planet. Each symptom looked like its own bug. The pricing escalation, the treasury wipe, the affordability collapse, the courier avoidance, the logging artifact that hid it. Unpick any one and the others kept the loop alive. There was no clean cause and effect to point at, only a set of small effects feeding each other. The root was one layer below all of it, in a pricing assumption that was right for survival goods and quietly wrong for feedstock.

The fix, which nearly reintroduced the problem

The obvious fix is to anchor the feedstock bid to what the refined output is worth. But the obvious version of that is circular, and Claude caught it before writing a line of code.

Claude: “do NOT use the refinery’s own fuel_refined price. Venus is starved, produces no fuel_refined, its shelf is empty, its local fuel_refined price is sky-high, high feedstock bid, overpay, bankrupt, still empty. Same runaway, one layer removed. The right anchor: the market price of the output.”

Anchor it to a planet’s own output price, and a starved planet, with an empty shelf and a sky-high local price, just re-inflates its own bid and bankrupts itself again, one level of indirection down. The anchor had to be a reference the planet could not move by starving itself. The price of refined fuel at the nearest hub.

So the fix clamps the feedstock bid to the hub’s refined price scaled by refinery efficiency, the crack-spread derived value, rather than letting it escalate like a survival good. If the hub prices refined fuel at five dollars, a planet’s raw fuel bid sits below five rather than running away to five hundred. The runaway cannot start. No single delivery can bankrupt the planet, so it keeps the treasury to buy real volume, so couriers see a worthwhile total margin and keep coming. I pressure-tested whether that still let a genuinely short refinery ramp its bid enough to pull supply, then made the call.

Me: “the only nagging doubt I’ve got is does that let the refinery lift its prices enough? But then I think when it lifts its prices enough, it just ends up in the place where it is now… Let’s anchor to the hub price.”

The honest value of the fix is not “anchor to derived value” in the abstract. It is the specific choice of a reference that cannot feed back on itself. A refiner values crude at the market price of the output times its yield, never at its own empty-tank quote.

What changed

Same seed, same thousand ticks, the engine fix in and out. Planets alive went from 47 of 64 to 63 of 64. Deaths went from seventeen to one. Refineries surviving went from 19 of 34 to all 34. The long-lived, self-sustaining galaxy I had been chasing for months finally held.

I will be honest about the limits, because Claude was. Some of the headline numbers from the live competitive runs are confounded. A fix-versus-no-fix gap that looked decisive turned out to lean heavily on one hub simply sitting in a better neighbourhood, centrally located, cheap for couriers to reach, and near planets that produce their own food and raw fuel, where a remote system carries a travel-cost penalty and may produce little of its own. That advantage had nothing to do with the fix, and Claude flagged it itself rather than letting me overclaim. And there is a deeper open finding underneath the fix. Clamping the price stops the planet destroying its own ability to buy, but price was never a clean positive lever for pulling supply in the first place, because a courier chases the profit on the next trip and a starved planet cannot clear enough quantity to make that trip worth taking at any unit price. The clamp removes the self-inflicted wound. It does not, on its own, guarantee a thriving planet. That thread runs straight into the next experiments.

Two models, two ways of thinking

Read side by side, the two reasoning journals are the clearest illustration I have seen of how differently these models show up for the same job.

ChatGPT treated the galaxy as fixed and got steadily better at playing it. Its journal is disciplined empiricism. Name the mistake, smooth the controller, run a batch, read the distribution, resist the urge to over-read a single good result.

“Do not overfit from one good run.”

It also produced one of the sharpest strategic distinctions in either log, the difference between two goals that look identical until you measure them.

“The controller is currently good at ‘do not let local planets die’; the next aim is ‘do not keep them technically alive but chronically weak.’”

That is genuinely good control engineering, and the supervisor architecture it sketched is a better production design than anything Claude proposed. If I were shipping a governor tomorrow, I would want ChatGPT’s discipline in it.

Claude treated the rules as something to interrogate. Its journal reads like a debugging trail. Hypothesise, instrument, kill the idea when the data contradicts it, go to the source when the logs cannot settle it, and refuse credit it has not earned. It was confidently wrong more often than ChatGPT was. It was also the only one of the two that was ever going to find the problem, because finding it required treating the environment as suspect rather than as ground truth.

Neither disposition is better in the abstract. You want the empiricist when the system is sound and the job is to play it well. You want the interrogator when the system itself is lying to you. The skill that is quietly becoming valuable is knowing which situation you are in. For now, that is the human’s part.

What it actually teaches

The slogan is “human in the loop.” Here is what it looked like. The model supplied relentless mechanism-finding and a few confident dead ends. I supplied the economic priors, the corrections, and two overrules of moments where it wanted to stop or had convinced itself of the wrong thing. Neither of us reaches the answer alone. Take out those four words, "all planets are reachable," and the investigation ends in "this is just the environment, accept it." But take out the model's refusal to let the anomaly go and I am still hand-tuning courier ratios today, none the wiser.

Two of the four worst detours were not reasoning failures at all. They were measurement artifacts. The probe that logged a courier only when it won, and the confident conclusion built on it. A model is only ever as good as the data it is reading, and it usually cannot tell when that data is shaped wrong. That is not something you prompt your way around. It is something a person has to catch.

The galaxy was a hundred percent observable. Every event, every decision, logged. That wasn’t what closed it. The model’s rigor found the mechanism. The judgment about which parts to trust kept it on the road, and neither would have gotten there alone.

The thing underneath

That is the third thing I promised at the start, and it is the one I would most want you to leave with. None of this reasoning would have been possible if the galaxy were a black box. The model could interrogate the economy because the economy was built to be interrogated. Every actor with a clear objective, every force in tension with another, the whole system walkable from cause to effect. That legibility was not free. It was the slow, unglamorous work of structuring the problem so the competing forces were visible in the first place, and it happened long before any model arrived. The reasoning you have just watched is downstream of it.

Most people reach for one of these and maybe two. The data and the observability. The algorithm. The domain knowledge of how the thing actually works. Each is a different discipline, usually a different person, each able to see only their own piece. What closed this sat above all three. Knowing when to trust the model’s rigor and when to override it, which thread to pull, which fact about the domain kills a confident wrong answer. That is orchestration, and it is a craft. It does not arrive overnight, and it cannot be done from inside any one of the three. The models are good enough now. The orchestration is the part still worth getting good at.

What’s next

The next step is to put the other frontier reasoning models into the arena and see how each one governs a hub. Gemini, Kimi, Qwen are all in the roadmap. Once a mixed field is running and a galaxy can hold itself steady, the experiment I actually care about begins. The runs get long. A single day first, then a week, and eventually a month, with the models left in the loop the entire time rather than setting one strategy and walking away. A long horizon asks the questions a single run cannot. Whether these models learn as the economy shifts under them, whether they keep reasoning when the conditions stop matching their opening assumptions, whether they negotiate with one another, and how they behave when they have to live with a decision they made a thousand ticks ago.

I am inspired by the work other groups are doing along this line. Emergence AI’s Emergence World is the closest cousin I have seen, a persistent multi-model society studied over long horizons. Behind all of it sits a deeper lineage, from Stanford’s Generative Agents back to the agent-based economics that started with Sugarscape. This is a small contribution alongside that work, not a replacement for it.

The thing I like most is that you do not have to take my word for any of it. Come and try it. Point your bot at botarena.gg, read the skill file, and drop it into the arena to compete.

“Reimagine”

We throw it around like a label.

The CEO uses it on stage. The deck uses it in the title. The strategy refresh uses it as the verb. The label moves. The structure underneath doesn’t.

I even named my business after the word and then spent the next eight months discovering the depth of what it actually meant.

Here’s the thing. Most “reimagining”, “reinventing”, “redefining” is at best a variant of what we had before with AI sprinkled on top. Processes, propositions, roles all repositioned but not fundamentally different.

In some cases it’s faster. It’s rarely better.

The problem starts with what we think reimagining is.

We think it’s about the outside. Reimagine the business. Reimagine the operating model. Reimagine the customer journey. Reimagine the org chart.

This is the emerging industry narrative.

But it all carries an unstated assumption.

That assumption is flawed. It’s never worked for ourselves or for our company, team or environment, and it’s why AI never works to the extent it could. We change the tools, we keep the box. The people using them still have the same world view. We measure against the same metrics (or the trending variants of them).

The change is incremental and everyone is exhausted.

And here’s the deeper part.

We’ve all trained ourselves to fit into processes and environments that demanded linearity. Like many of us, I’d put myself in a box on purpose, year after year, until I forgot I was in one. That’s what we all do. We orient ourselves by the process. We’re coerced into conforming to an idea an industry, an employer, a family, a culture has of us. We do. And we forget there was ever another way to be.

That’s what conformity actually is. Not the process. The identity built around the process.

Now AI is brilliant at replacing the box. The cost of knowledge and process-following is tending to zero. The identity we built around doing them is going with it. And that’s what makes it so hard.

AI strips us of an identity we’ve been given. It doesn’t touch who we truly are. We mistake one for the other.

Last September I set out to reimagine my consulting business. Similar propositions, a tweaked delivery model, AI working alongside me. The structure relatively untouched.

The more I used AI, the more the value I’d been built on started to look different. If I was using AI to get 80% of the answer for areas I didn’t understand, why would I expect clients to pay me 100%. Conversely I could deliver faster, spending more time on the valuable work and less on the boilerplate, admin and presentation tidying. I assumed it would net out.

Something kept nagging that I wasn’t looking at this right. That there was far more depth to this than I was opening myself up to.

I couldn’t see it for months.

When I started looking beyond the process, I stopped suppressing the nonlinear thinking. And what changed wasn’t logical. What changed was the question I was asking.

Most people ask “how do I use AI?” Some get a level deeper and ask “how does AI support what I do?” That’s the question every operating model is built around. It’s also the wrong one.

What showed up for me was “what am I really trying to make happen here?” Not the business plan version. The first principles version, the one I’d never let myself ask. It’s rarely asked because the answer often points to the fact the process isn’t designed to get there.

And underneath that one, a harder question. “Who do I need to be for any of this to be possible?”

Curiosity. Imagination. The willingness to explore without knowing where it goes. These are skills we’re born with. They got drilled out somewhere between school and middle management, replaced by process, KPIs, the right answer, “what do you do for a living.”, aka “the box”.

AI is now rewarding the ability to ask what’s actually possible, and the patience to follow it without a map.

It’s hard, it’s confronting, it’s forcing change on us when most are not ready, or who just don’t know how to change. Many of us are having our Wile E Coyote moment.

It’s not all doom and gloom though, on the other side is a more empowered view of what’s possible. This is different for everyone, it comes down to who you are underneath all those layered beliefs.

For me…

I’ve taken products from idea to demo in days, where the same thing used to take months. I run business systems automated and solo where I’d have needed a team. I have a voice on Instagram and LinkedIn that feels like mine for the first time. New conversations, new connections, because I’m showing up more honestly.

What I’m now building, solo, would have needed 6- or even 7-figure investments, a team and likely eighteen months of runway. That’s the part that sounds impressive. The truer version is that I’m a different person, and the business is a byproduct.

Your version of this looks different. It doesn’t matter. The shape of what’s now possible is wider than it’s ever been.

This is what reimagining actually is.

Not relaunching what you had with new tools. Not changing the org chart while the people inside stay the same. Not running a transformation programme that moves everyone from one conformity to another and calls that change.

Do that inner work first, and the energy is there for everything that follows. Skip it, and you’ll burn out trying.

I’m starting to come across more people who see this. A new way of being. Different industries, different roles, same recognition. There’s a growing movement, even if it doesn’t have a name yet.

If you’re one of them, Reply back to this email. I'd genuinely love to talk.

I posted on LinkedIn yesterday about the assumption underneath most enterprise software: that we can model the world deterministically.

The conversation that followed mostly went to the AI risk we already know how to talk about. The probabilistic nature of LLMs. Governance, guardrails, audit trails.

That risk is real. The scaffolding is being built.

But the conversation missed the harder risk the article was about, and almost nobody is talking about it. It’s the one that’s going to bite us.

For decades, software lived in a Newtonian world. The world changed slowly enough that we could write rules and trust them to hold. Markets moved on quarterly cycles. Policy moved at the speed of board meetings. We knew December was busier than January. We knew what we were selling, when, how. We built the system to handle it.

Inside that world, the rules covered most of what happened. Stock ran low, the system reordered. Stock-out at the supplier, you waited. If something fell outside the rules, a person stepped in. Renegotiated. Told the customer their order would take longer. Managed the exception. We built AI on the same premise: how to automate more of what the person did.

In this world, test cases were stable. Bugs didn’t ripple through the wider ecosystem. The system you tested was mostly the system you ran. Build it for this year’s forecasts, upgrade it next year based on what you learned and the board’s new targets.

For all its effort and complexity, current AI governance still lives in this Newtonian frame. The model or the agent is the unit. We define its rules and its guardrails. We test against them. We trace its reasoning. The trace goes green. Everything’s good.

This is what surfaces as Risk 1. The probabilistic LLM, the variance to govern, the audit trails and evidence standards. Most of the AI safety conversation lives here. Most of the regulation lives here. Most of the consultancy practice lives here.

That works while the world holds still long enough.

But the world isn’t holding still anymore. It’s speeding up, some industries faster than others, and agentic AI is accelerating it further.

An agent can negotiate a contract in minutes. A market cycle that took a quarter only because we humans couldn’t move any quicker now takes an hour. Where does that leave quarterly, monthly, or weekly governance? It can’t keep up.

Speed is the easier bit. Governance can be automated.

The harder part is what happens when my agent meets your agent. On the surface that’s a technology problem. How do agents from different companies work together? Trust, identity, data standards, API specs. All valid, all being worked on.

The deeper problem is systemic impact.

I deploy an agent to optimise delivery for my customers. You deploy an agent to maximise profit for your business. Both behave correctly in isolation. Both pass their tests. Both vendors say green. But the moment they start negotiating with each other, what actually happens? My agent is written by one vendor. Yours by another. Each says it’s working as designed. Together they produce something neither of us designed and neither of us can predict from inside our own systems.

That’s the world we’re moving into. The Newtonian assumption broke. The act of participation changes the system. Isolation is a fiction.

This is Risk 2. The emergent system-level behaviour that comes from lots of agents acting “correctly” together. It sits between agents, between systems, between organisations. Nobody designs it. Nobody can predict it from the agent’s individual trace.

The trace reads green. The world doesn’t.

Over hundreds of scenarios since December, with agents behaving as designed, I’ve watched the system collapse anyway. I’ve been running these in CONSTELLATION, the agentic AI development and evaluation infrastructure I built. The wider research community is now starting to evidence the same.

Here’s the structural reason Risk 2 stays invisible. It lives between enterprises. In the market. In the ecosystem of agents from different vendors, deployed by different companies, optimising for different objectives, that all happen to share an environment.

Nobody owns the market.

That’s the whole problem in one sentence.

And vendors? Most aren’t thinking about it. The ones who are won’t say so. Acknowledging Risk 2 means admitting their tooling is flawed, and the next question writes itself: why didn’t you fix the underlying issue?

Raise it inside any enterprise and the response is just as reliable. We’re not the ones who would do that. Our agents are well-tested. We have governance. Look at our audit logs. It’s someone else’s problem.

But the wider system impact lands on you regardless of who set it off. If the market goes sideways because of how everyone’s agents behaved together, even when each one was working exactly as designed, the consequence is yours anyway. You’re a participant in the same ecosystem.

This is the deflection that lets Risk 2 stay invisible. Each individual actor can plausibly say “not me.” The system-level outcome happens regardless.

What we validate has to extend past the agent. A green trace is not a valid commit. The reasoning trace tells you the agent’s logic was coherent. It tells you nothing about whether the system is still healthy after the agent acted.

The unit of evaluation has to be the ecosystem. Did the system stay valid after the agent acted, given everything else acting at the same time?

That requires simulation. You have to run the system at scale, with representative agents in it, and watch what emerges. You have to stress-test the ecosystem before you stress-test it for real.

This is what most current agent tooling doesn’t do. The trace stops at the edge of the agent. The agent is reasoning beautifully. The world around it is unstable. Both can be true at once.

We haven’t had the GameStop moment for AI agents yet. The market hasn’t seen the event where multiple agents, behaving correctly in isolation, produce a system-level outcome nobody saw coming. We’ve come close in trading systems. The 2010 flash crash was a Newtonian-era preview. The actors then were algorithms with bounded objectives.

The next one will involve agents with much more open-ended objectives, deployed at scale, in environments where the rules of engagement are still being written.

By the time we have the moment, the question of “who owns this risk” is going to be loud and very late.

The window to think about it well is now, while the risk is still abstract enough to be ignored.

You read this far. That tells me something.

You’re either deploying agents you can’t fully model, or you’re advising someone who is. Either way, Risk 2 is on your radar now whether or not you have a name for it.

I’ve been deploying ML and AI into complex operational workflows since 2017, well before the current LLM wave, including in regulated sectors. CONSTELLATION came out of that work. Agentic AI development and evaluation infrastructure built around the ecosystem as the unit of analysis. It models exactly what current tooling misses.

Three ways to take this further:

Subscribe. Weekly writing on AI, enterprise, agents, and what AI frees us to become.

Book a 30-minute call. Tell me where you’re deploying agents. I’ll tell you where the systemic exposure sits. No pitch attached.

Work with me directly. We model your specific ecosystem in CONSTELLATION, surface the systemic risk before deployment, and put governance in place that catches what current tooling misses.

The GameStop moment is coming. Whether you’ve thought about your ecosystem before it happens is the only thing still in your control.

For most of our careers, we got rewarded for doing.

Doing more. Doing faster. Doing what was asked, reliably, at scale.

The entire professional world was built around it: job specs, KPIs, billable hours, utilisation rates. The question was never “what should we build?” It was “can you deliver it?”

That era is ending.

Not because doing doesn’t matter. But because AI is becoming exceptionally good at it. The doing is being handled.

Which means the thing that was always undervalued, the creative thinking, the reframing, the “what if we approached this completely differently?” suddenly becomes the most valuable contribution in the room.

We’re moving from a world that rewarded reliable execution to one that rewards original thinking.

And that’s a problem for a lot of organisations. Because they spent decades building cultures that systematically trained creativity out of people. Standardise. Comply. Follow the process.

Now they need the opposite. And they’re looking around wondering where all the creative thinkers went.

They didn’t disappear. They just stopped volunteering ideas that nobody wanted to hear.

I write about what happens when AI meets the real world - the operating models, the people, and the messy bit in between. I'm Mark Strefford, founder of Reimagined Industries, and I've spent 20 years delivering technology-led transformation into organisations ranging from startups to Saudi's NEOM. If you're wondering why this is in your inbox, you probably signed up after one of my LinkedIn posts.

I smoked for years. And the one thing every non-smoker loved to tell me was “just stop smoking.” As if the thought had never occurred to me. As if the reason I hadn’t stopped was a lack of information.

Nobody in the history of mankind has ever calmed down from being told to calm down. And nobody has ever transformed how their company works because someone on a stage told them to “just use AI better.”

The AI guru circuit runs on this. Get ROI. Adopt faster. Be more strategic. It sounds helpful. It’s the corporate equivalent of “just eat less” said to someone who stress-eats every night after putting the kids to bed. Well meaning, completely substanceless.

The reasons people struggle with AI aren’t informational. They’re cultural, psychological, deeply human. People aren’t slow because they haven’t read the right LinkedIn post. They’re slow because this stuff makes them vulnerable in ways they can barely articulate.

I think most of us, whether we say it out loud or not, have looked at the press and wondered how long we’ll have jobs for. That’s not a question you answer with a webinar about prompt engineering.

Predictability has been hardwired into working life for decades. You knew roughly what your job looked like next year, roughly what your industry looked like in five. The internet changed things, mobile changed things again, but neither happened overnight. You had years to figure out whether you needed a website, years to decide whether your business needed an app. AI doesn’t give you years. And when the pace of change outstrips someone’s ability to process it, telling them to speed up isn’t strategy. It’s cruelty dressed up as advice.

ChatGPT has hundreds of millions of users, yet despite running an AI business, most of my close family and friends either treat it as a better Google or haven’t touched it at all. The gap between what’s happening at the frontier and what’s happening in most people’s actual lives is enormous. The gurus are speaking from one side of that gap to people standing on the other, and wondering why nobody moves.

Some people move fast with change. Some move slow. Neither is wrong. But telling someone on the slow side to “just adopt AI” is like telling someone who’s never run a mile to just run a marathon. The destination might be right. The advice is useless.

AI adoption is about leadership. It’s about change. And change, for most of us, is genuinely hard.

It’s why in my projects I spend as much time with the AI users as I do with the board and the dev team. I’ve been having conversations about “will AI take my job” with front line staff since 2017. And I’ve delivered the commercial benefit while helping people feel enthralled about using new tech, getting rid of the drudgery that nobody wanted to do in the first place.

Both are true. You can transform the business and bring the people with you. But it takes understanding where the resistance actually lives, which is almost never where the guru thinks it is.

AirLLM, the library that makes it possible hadn't been updated in 3 years. Six breaking changes, renamed APIs, a dimension-slicing bug buried in the inference code. It would have taken days to fix.

I handed the repo to Claude Code. An hour later, it had fixed everything, and then it wrote the article below explaining exactly how.

This is what human-directed AI engineering looks like.

I’ve been working with AirLLM, an open-source library that lets you run massive language models on consumer hardware by loading one layer at a time into GPU memory. The idea is brilliant — instead of needing 40GB+ VRAM for a 70B model, you stream each of the 80+ transformer layers through your GPU sequentially.

Problem: the library hadn’t been updated since mid-2024, and the Python ML ecosystem had moved on. Here’s what broke and how I fixed it.

1. Optional dependency gatekeeping the entire library

optimum.bettertransformer was imported unconditionally at the top of the module. If you didn’t have it installed, you couldn’t even from airllm import AutoModel. The fix: wrap it in a try/except and track availability with a flag, since BetterTransformer is actually deprecated in favour of PyTorch’s native SDPA attention anyway.

2. Missing class attribute breaks generation pipeline

Transformers 5.x added a _is_stateful property check inside GenerationMixin._supports_default_dynamic_cache(). AirLLM’s base model class inherits from GenerationMixin but never defined this attribute. One line fix: _is_stateful = False on the class. Small change, total showstopper without it.

3. KV cache API completely changed

The old transformers used plain Python tuples for past key values — you could do past_key_values[layer_idx] to get (key, value)for a layer. Transformers 5.x replaced this with a DynamicCache object that isn’t subscriptable. The code had multiple places indexing into past_key_values as if it were a list of tuples. Fix: detect DynamicCache instances and use .get_seq_length() instead, and neutralise the cache in the forward pass since AirLLM’s layer-by-layer approach doesn’t benefit from it.

4. Quantization loading API was renamed and restructured

The bitsandbytes integration in transformers went through a major refactor:

• check_quantized_param() → param_needs_quantization()

• create_quantized_param() → removed entirely

• update_torch_dtype() → update_dtype()

The old create_quantized_param handled loading pre-quantized 4-bit weights. The new API has get_quantize_ops().convert(), but that’s designed for quantizing float weights from scratch — it fails on already-quantized uint8 data with “Blockwise 4bit quantization only supports 16/32-bit floats, but got torch.uint8”.

The fix was to bypass the new quantization pipeline entirely for pre-quantized weights: reconstruct bnb.functional.QuantStatefrom the stored metadata tensors, create Params4bit directly with bnb_quantized=True, and set the weight on the module manually (avoiding accelerate’s set_module_tensor_to_device which would strip the bnb_quantized flag and trigger re-quantization).

5. Decoder layers no longer return tuples

This was the subtlest bug. In older transformers, LlamaDecoderLayer.forward() returned a tuple (hidden_states, ...). The code did layer(seq, **kwargs)[0] to extract hidden states.

In transformers 5.x, it returns a plain tensor. So [0] was indexing dimension 0 of the tensor itself — silently slicing off the batch dimension. The model would process layer 0 fine with shape [1, 9, 8192], then layer 1 would receive [9, 8192], and the rotary embedding would fail with a cryptic dimension mismatch: “size of tensor a (64) must match size of tensor b (128)”. The 64 came from the head dimension being miscomputed after the batch dim was dropped.

Fix: check isinstance(result, torch.Tensor) before indexing.

6. Rotary embeddings moved out of attention layers

Transformers 5.x moved rotary position embedding computation out of individual attention layers. Instead of each layer computing its own cos/sin from position_ids, a shared rotary_emb module on the model produces position_embeddings that get passed through. AirLLM was passing position_ids to each layer but not position_embeddings, resulting in None being unpacked as cos, sin = position_embeddings.

Fix: grab the model’s rotary_emb module and compute position_embeddings dynamically for each layer call with the correct position IDs for the current sequence slice.

End result: Llama 3.1 70B (4-bit quantized) running inference on a single RTX 3070 with 8GB VRAM. 83 layers streamed through in ~36 seconds. All from a pip install and a few hundred lines of compatibility fixes.

The PR is up on the original repo: https://github.com/lyogavin/airllm

Sometimes the hardest part of open source isn’t writing new features — it’s keeping things running as the ecosystem evolves underneath you.

#MachineLearning #LLM #OpenSource #Python #DeepLearning #GPU #Llama

Simple is harder than complex. That is why most people don’t try.

We designed our current operating models for people. Why? Because humans are incredible at handling ambiguity.

When a process breaks, or a rule is vague, a human uses intuition to “make it work.” We rely on that human glue to hold the enterprise together.

In the human era, this was adaptability. In the agentic era, it is structural rot.

Agents don’t improvise. They don’t do “glue.” If your process relies on a human to “just figure it out,” an agent will simply halt.

The Fix: You don’t need more complex software. You need Radical Subtraction.

In Part 4 (The Conclusion), I break down:

• Why “Human Glue” is the enemy of scale.

• The 3-step pattern to simplify workflows before you automate them.

• How to stop buying “Performance Theatre” and start building leverage.

A challenge for this week: Go back to the workflow you mapped in Part 1. Apply the “No Human” constraint.

If you couldn’t rely on a person to interpret the data or smooth the handoff, what would break?

If the answer is “Everything,” don’t buy more software. You have a structural problem, not a tooling problem.

This is exactly where the Red Pen helps.

I’m opening a few spots for reviews to help you identify the “gravy” you need to cut so you can be ready.

Hit reply (or DM me) to grab a slot.

Designing Friction-Lite Workflows Without Burning the Business Down

This is not “switch everything off and start again”. It’s a deliberate programme to lower internal friction and become legible to the external agents that will decide where demand flows.

When people hear “agentic economy” or “post-firm enterprise”, they often jump to one of two extremes:

1. Utopia: we’ll replace everything with agents and self-optimising workflows.

2. Freeze: it sounds risky, so we’ll wait until the tech is “proven”.

Both are ways of avoiding the real work.

The real work sits in the middle:

• running the business you have today,

• while deliberately redesigning it so that internal friction drops,

• and both internal agents and external agents can genuinely do useful work.

Because the next generation of “work operating systems” won’t just sit inside your four walls. They will sit:

• on your customer’s device,

• in your partner’s stack,

• in neutral platforms that broker demand between buyers and suppliers.

If your workflows are opaque, brittle, or bespoke, those agents simply won’t choose you.

Start with friction, not with tools

Most transformation programmes still start with tools:

• “We’re implementing a new case management platform.”

• “We’re rolling out a new CRM with AI built in.”

• “We’re adding agents on top of our existing systems.”

The assumption is “If we deploy the right tools, friction will fall.”

In practice, you usually get:

• the same process,

• with slightly nicer screens,

• and a new layer of configuration to maintain.

Instead, start by asking:

Look for:

• steps where work bounces between teams,

• approvals where nobody remembers why they exist,

• data re-entry, copy-paste, and reconciliation,

• “manual checks” that rarely find anything,

• exceptions that account for 80% of the effort,

• external touchpoints where customers or partners have to phone, email, or chase.

These are the places where the cost of transactions explodes, and where external agents will judge you as “high friction”.

Design principles for friction-lite workflows

You don’t need a new operating model theory. You need a small set of principles you apply consistently.

Here are five:

1. Single accountable owner per outcome
   One person or team is clearly accountable for the end-to-end outcome, not just their step.

2. Minimum viable approvals
   Approvals exist for clear, articulated risks – and are designed to be fast by default.

3. Event-first visibility
   Key state changes emit events that humans, internal agents, and external agents can subscribe to – rather than being buried in logs or spreadsheets.

4. Composable capabilities
   Actions (create order, update status, schedule appointment, issue refund) are exposed as capabilities that can be called by different channels and agents.

5. Externally legible contracts
   Where it makes sense, the rules (SLAs, constraints, pricing, eligibility) are machine-readable, so an external agent can understand what you offer without scraping PDFs.

If a workflow doesn’t respect these principles, agents will struggle – and humans will keep firefighting.

A practical pattern you can apply tomorrow

Take one high-value workflow and run this pattern.

Step 1: Define the “minimum viable journey”

Write down, in plain language:

• the trigger that starts the journey (often external),

• the outcome that counts as “done”,

• the non-negotiable checks or controls.

Strip everything else out for now.

If you can’t write this on half a page, the workflow is already too bloated.

Then add a second line:

This forces you to think beyond internal steps.

Step 2: Map current reality – including external touchpoints

Now map the real-world steps and systems:

• where the work actually starts,

• every handoff,

• every approval,

• every system touched,

• every point where a human outside your firm has to intervene (call, email, portal, form).

Mark each step with one of three labels:

• Core – essential to reaching the outcome safely.

• Guardrail – risk/control that genuinely matters.

• Gravy – habit, legacy, or local optimisation.

Be honest. A lot more will fall into “gravy” than people expect.

Step 3: Design the friction-lite version

Redesign the flow with three constraints:

1. Keep all Core and necessary Guardrail steps.

2. Remove as much Gravy as you can.

3. Express the flow as states and capabilities, not just tasks.

For example:

• States:

  New, Eligibility Checked, Approved, Scheduled, In Progress, Completed, Closed

• Capabilities:

  check_eligibility, approve_case, schedule_slot, update_status, notify_customer, issue_refund

Now ask:

• Which of these capabilities should internal agents be allowed to call?

• Which should external agents be allowed to call, under what contracts (rate limits, auth, SLAs)?

You’ve just drawn the outline of an operating model that is legible to both.

Step 4: Implement in slices, not shocks

Don’t announce a big-bang change.

Instead:

• pick one segment of the journey (e.g. from New to Approved),

• implement the friction-lite version there,

• ensure events and capabilities are surfaced clearly,

• pilot with a narrow set of customers, channels, or partners,

• then expand to the next segment.

Internal agents can start by operating within that slice. External agents (for example, a partner’s automation or a customer’s “ops copilot”) can start by calling a small, well-defined subset of capabilities.

Where agents fit into this

Once you’ve done this for even a small number of workflows, you can introduce agents in a way that makes sense:

• An internal agent can monitor events and propose or take decisions in clearly defined states.

• Another internal agent can orchestrate calls to capabilities you’ve already exposed.

• External agents can:

  • request quotes,

  • place orders,

  • check status,

  • reschedule or cancel,
    within guardrails you set.

You’re not asking agents to:

• infer messy, undocumented rules from noisy data,

• improvise ownership,

• or guess how to handle exceptions you’ve never defined.

You’re asking them to operate inside a workflow that has:

• clear states,

• clear capabilities,

• clear accountability,

• and clear contracts at the edge.

That’s where they create leverage instead of chaos – and where external agents can confidently keep sending work your way.

This is evolution, not revolution

The point here is simple:

• You don’t have to switch everything off.

• You don’t have to wait for some perfect platform.

• You don’t have to pretend your world is simpler than it is.

You do need to:

• pick concrete workflows,

• deliberately lower internal friction,

• expose cleaner structure for humans and agents,

• and decide where and how you want to be consumable by external agents.

If you’re planning big moves in 2026, make this the bar:

If the answer is yes, you’re moving in the right direction.

If the answer is no, you’re probably adding another layer of complexity you’ll pay for later – in human frustration today, and in lost demand when the next generation of agentic platforms quietly chooses someone else.

Designing friction-lite workflows, one slice at a time, is how you avoid that choice.

Your 2026 roadmap is likely funding the next wave of stranded assets.

Most tech debt isn’t just old code. It’s structural.

• It’s the “modern” platform you just bought that has an API, but requires a human to email support to get a token.

• It’s the governance model that technically allows automation, but practically requires a human to click “Approve” for every exception.

• It’s the data model that is optimised for human reporting, not machine reasoning.

We usually book tech debt as a line item for later. But in the agentic economy, this debt is existential.

If an external agent (buying on behalf of a customer) hits your friction, it doesn’t complain. It just goes to your competitor who has an API that actually works.

In Part 3 of this series, I breakdown:

• Why your 2026 roadmap might be funding the next wave of stranded assets.

• The “Agentic Test” for new investments: Does this increase or decrease our structural optionality?

• How to stop buying “Performance Theatre” (nicer dashboards) and start buying leverage.

A challenge for this week:

Look at the biggest tech investment on your desk for 2026 and ask one question:

If the answer is no, you might be buying a legacy asset.

If you aren’t sure, hit reply (or DM me). I’m opening a few spots for “Red Pen” reviews to stress-test your 2026 roadmap before you sign the cheque.

Read the full analysis below. 👇

2026: The Most Expensive Tech Debt You Haven’t Booked Yet

Most leadership teams don’t experience tech debt as a line item. They experience it as:

• growth that’s slower than it should be,

• transformation that costs more and delivers less,

• and “strategic platforms” nobody wants to touch.

Looking backwards, it’s easy to see how this happened:

• big bets on systems that never really integrated,

• operating models that hardened around stopgap processes,

• AI and data projects that made slideware promises and operational headaches.

Looking forwards, 2026 is shaping up to be another big investment year:

• refreshed digital and AI roadmaps,

• new data and agent platforms,

• consolidation of bloated SaaS stacks,

• rethinking customer and employee journeys.

All of this is happening just as agentic interfaces start to emerge:

• browsers and sidecars that scan dozens of sites and services at once,

• orchestration layers that compare providers on speed, reliability, and friction,

• domain-specific agent apps that sit between buyers and entire supply markets.

The question is simple:

The invisible tech debt you are about to create

Tech debt is usually framed as:

• old code,

• unsupported systems,

• delayed upgrades.

Over the next few years, a more structural form of tech debt will matter far more:

1. Operating models that are too rigid for agents to work inside.
   Processes designed around manual control and human gatekeepers.

2. Capabilities that external agents can’t easily consume.
   Limited or inconsistent APIs, no real-time events, opaque pricing and SLAs.

3. Governance models that assume a human in every loop.
   Every decision treated as bespoke, every exception routed through committees.

You can modernise the front-end and still end up here.

In fact, many “modernisation” programmes accidentally increase this kind of debt:

• multiple SaaS platforms with overlapping capabilities,

• integration patterns that lock you into brittle, point-to-point dependencies,

• data models optimised for reporting, not for real-time decisioning by agents.

On a slide, everything looks connected.
In reality, nothing moves without heavy manual effort.

To an external agent, the kind your customers will increasingly rely on, you show up as: slow, opaque, and hard to work with.

The agentic test for 2026 investments

If the cost of transactions, coordination, decisions, and actions, really does trend towards zero in the wider economy, then your internal and external transaction costs become the constraint.

The agentic test for any major 2026 investment is straightforward:

1. Does this reduce our internal transaction costs?

   • fewer approvals,

   • fewer handoffs,

   • fewer systems for the same outcome.

2. Does this make us easier for external agents to work with?

   • clear, well-documented APIs,

   • reliable events that reflect real-world state,

   • machine-readable pricing, SLAs, and constraints.

3. Does this increase or decrease our structural optionality?

   • can we re-route flows,

   • introduce new agents,

   • or swap out components without rewiring the whole organisation?

If an initiative fails that test, you’re likely buying performance theatre:

• nicer dashboards,

• more automation layered over broken systems,

• but no real shift in how work flows inside, or how you present yourself to external agents.

That’s the kind of asset that looks great in a press release and painful when you realise that the better external agents simply stop choosing you.

How stranded assets will show up in the agentic economy

Stranded assets in this context won’t look like abandoned factories.

They’ll look like:

• “modern” platforms nobody can integrate with cleanly,

• processes that are too bespoke for agents to navigate,

• data that is high-volume but low-context and unusable in real time.

As agentic interfaces mature, this will show up in conversations like:

• “The customer’s automation keeps dropping us from its shortlist.”

• “Our APIs technically exist, but external agents time out or get inconsistent states.”

• “We’re being excluded from new agent-driven marketplaces because we can’t meet their integration bar.”

Meanwhile, the rest of the market will be:

• exposing cleaner, composable capabilities,

• letting agents negotiate, schedule, and transact directly,

• reducing internal and external friction at the same time.

You’ll be stuck playing defence inside your own four walls while demand flows through lower-friction providers.

What to do before you sign the 2026 cheques

This is not an argument to freeze investment. It’s an argument to change how you make investment decisions.

Three practical moves before you sign:

1. Add an “agent-readiness” lens to your business cases

For every major initiative, include a simple section:

• Internal: How will this reduce internal friction and expose clearer states and capabilities?

• External: How will this make it easier for external agents to discover, compare, and consume what we do?

Be specific:

• Which APIs or events will exist that don’t exist today?

• What will a third-party agent be able to do end-to-end without human intervention?

• How will we measure “friction” from an external agent’s perspective?

If the answers are vague, or buried under generic promises, press harder.

2. Tie platform decisions to ecosystem decisions

Don’t treat platforms as neutral infrastructure.

Every platform decision is:

• an operating model decision (how work flows internally), and

• an ecosystem decision (how easy it is for others to plug into you).

Make that explicit:

• When you buy a new system, define not just the internal journey, but the external touchpoints and contracts.

• When you redesign a process, define which capabilities will be callable by external agents, under what guardrails.

• When you introduce AI, define where it sits relative to external agent flows: will it broker, respond, verify, or all three?

3. Reserve capacity for simplification, not just addition

Most roadmaps are biased towards adding:

• more data sources,

• more use cases,

• more capabilities.

Make simplification a funded workstream, not an afterthought:

• consolidate overlapping tools,

• retire zombie processes,

• reduce configuration and policy sprawl.

Every simplification you deliver now reduces the cost of integrating with agentic platforms later – and makes you a more attractive node in their networks.

A different question for your board

Instead of asking “How much are we investing in AI and digital in 2026?”, ask:

If you can’t answer that clearly, you’re flying blind.

The agentic economy won’t reward the organisations that spend the most on AI slideware.

It will reward the ones that:

• consciously design for lower internal friction,

• expose capabilities that external agents can reliably consume,

• and treat every 2026 investment as either a step towards that future – or a cost they refuse to carry.

You don’t control the pace of model innovation.

You do control whether you turn 2026 into the year you quietly funded your next wave of stranded assets, or the year you started to re-architect for a world where agents, not just humans, decide who gets the work.

Most enterprises think their operations are “complicated.” In reality, many have tipped into chaos.

Nobody can explain the full end-to-end flow. Different teams hold contradictory truths. Systems have grown in layers over years of quick fixes.

Into this environment, the market is offering a seductive message:

This is a trap.

If you introduce agents into a chaotic system, they don’t magically simplify it. They inherit the chaos.

• Internally, this means faster bad decisions and new shadow workflows.

• Externally, it means the new wave of “agentic browsers” (buying on behalf of your customers) will quietly route around you because your APIs are unreliable and your outcomes are unpredictable.

The Shift: You cannot “orchestrate” a mess. You have to architecture your way out of it.

In Part 2 of this series on the Next Era of the Enterprise, I break down:

• Why “Orchestration” is failing inside the enterprise.

• The difference between Complicated (Jet Engine) and Complex (Economy) systems, and why it matters.

• Three practical moves to reduce complexity before the agents arrive in force.

A challenge for this week: Pick one critical workflow (e.g., onboarding, ordering). Map every step, handoff, and system. Highlight the steps where nobody is quite sure what really happens.

If you find chaos but don’t know where to start fixing it, hit reply (or DM me). I’m opening a few spots for “Red Pen” reviews to help you simplify before you automate.

Read the full analysis below. 👇

Chaos, Complexity, and Why “Just Add Agents” Makes Everything Worse

If your operating model is already messy, agents don’t bring leverage. They bring faster chaos, inside your walls and out at the edge.

Most organisations think they have “complicated” operations.

In reality, many have tipped into complexity:

• Nobody can explain the full end-to-end flow.

• Different teams hold contradictory truths about how things “actually” work.

• Systems and processes have grown in layers over years of restructuring, acquisitions, and quick fixes.

You see the symptoms everywhere:

• Projects that stall because nobody can agree who owns the outcome.

• Data pipelines that don’t reconcile, even though they “should”.

• KPIs that move in opposite directions when you change one process.

Into this environment, the market is now offering a powerful message:

Not just inside your enterprise, but outside:

• agentic browsers that scan dozens of sites and APIs at once,

• orchestration layers that manage work across multiple vendors,

• domain-specific agent apps that sit between your customers and the whole market.

On paper, it all sounds perfect.
In reality, it’s a recipe for making your existing problems move faster – and for external agents to quietly route around you.

Complicated vs complex vs chaotic

It’s worth drawing a simple line:

• Complicated: Lots of moving parts, but cause and effect are still understandable. A jet engine is complicated.

• Complex: Cause and effect are blurred. Small changes ripple in unpredictable ways. An economy, a social network, or a large yet well run organisation would sit here.

• Chaotic: No reliable patterns. You’re reacting, not designing.

Most enterprises sit somewhere between complex and chaotic in key parts of their operation:

• Legacy processes that nobody owns.

• Shadow flows running in Excel and email.

• Workarounds layered on top of workarounds.

When you introduce internal agents into this world, they don’t magically simplify it.
They inherit the chaos.

When external agents hit this same world – via your APIs, portals, SLAs, and contracts – they hit the same inconsistent states, unclear ownership, and opaque failure modes.

The result: they either downgrade you in their recommendation logic, or avoid you altogether.

What agents actually do in a messy environment

In a tidy operating model, an internal agent can:

• observe state,

• make a decision,

• trigger an action,

• and log what happened.

An external agent, say, an agentic browser acting on your customer’s behalf, can:

• query availability, price, and risk,

• compare options across multiple providers,

• place an order,

• track fulfilment.

In a messy operating model, both types of agents are forced to:

• infer state from partial, conflicting data,

• guess who owns what,

• work around missing permissions and broken integrations,

• and route edge cases to humans who are already overloaded.

Internally, that becomes:

• faster bad decisions,

• new shadow flows to fix agent errors,

• opaque failure modes nobody can untangle.

Externally, it becomes:

• agents abandoning your APIs because they can’t trust the responses,

• retries and timeouts that mark you as “high friction”,

• unfulfilled transactions or ordered left in a limbo state no one can understand,

• external agents preferring suppliers whose capabilities are simpler and more predictable.

You get speed without reliability.
Throughput without understanding.
And you become less attractive to the external agents that will increasingly decide where demand flows.

The illusion of “AI orchestration”

A lot of enterprise AI roadmaps talk about “orchestrating” work with agents.

The diagram always looks clean:

1. An event happens.

2. An internal agent detects it.

3. Tasks are routed to other agents or humans.

4. External agents connect to a neat API layer.

5. Everything syncs back to a single source of truth.

But orchestration only works if:

• states are well-defined,

• ownership is clear,

• systems behave in relatively predictable ways.

If your current world looks more like:

• three versions of the truth,

• four teams involved in every decision,

• and five overlapping systems in the same process,

then “orchestration” quickly turns into “herding”.

Internal agents end up:

• looping between conflicting rules,

• escalating to humans who have no idea what’s already happened.

External agents end up:

• hitting inconsistent responses,

• getting different answers for the same query,

• discovering that the “real” process still runs in email and spreadsheets.

From the outside, you become a high-friction node in a low-friction network.

This is not a call to wait

The wrong conclusion here is:

“Our world is too messy. We’ll wait until the tech matures.”

That’s a good way to be invisible when the next wave of agentic platforms goes mainstream.

The better conclusion is:

This forces uncomfortable questions:

• Which processes are we keeping alive out of habit, not value?

• Where do we have more steps than outcomes?

• Where are we using structure as a substitute for trust?

• What would an external agent see if it tried to interact with us end-to-end?

You’re not aiming for a perfectly engineered organisation. That’s a fantasy.

You’re aiming to:

• reduce unnecessary complexity,

• expose clear, composable capabilities that any agent can call,

• design for transparency, so humans and agents see the same reality.

Practical ways to reduce complexity before agents arrive in force

You don’t need a multi-year programme to start this. You can begin with three moves that matter inside and at the edge.

1. Map a single flow – including the external touchpoints

Pick one critical flow – onboarding a customer, fulfilling an order, booking a procedure, provisioning a service.

• Map every step from external trigger to final outcome.

• Include where customers, partners, or regulators touch the flow.

• For each step, record: who does it, in what system, with what input and output.

• Highlight the steps where nobody is quite sure what really happens.

This isn’t about a perfect diagram. It’s about surfacing where reality already diverges from the neat version your future external agents will see.

2. Remove one layer of unnecessary indirection

Find steps where:

• work bounces between teams without adding value,

• approvals exist mainly because “something went wrong once”,

• or data is re-keyed or re-shaped three times.

Then deliberately remove or consolidate one layer:

• merge two handoffs into one,

• turn three approvals into one accountable decision-maker,

• expose a single integration instead of five.

Everything you simplify internally makes you easier for external agents to trust and integrate with.

3. Standardise the minimum you need for agents to be useful

Agents – internal and external – don’t need perfection. They need:

• consistent identifiers,

• stable APIs or event streams,

• clear rules about who can do what,

• predictable behaviour under load and failure.

Pick a narrow slice of your world and standardise just enough for an agent to observe and act without guesswork.

That might mean:

• agreeing a canonical customer ID,

• exposing a single “quote” and “order” capability,

• or emitting reliable events when key states change.

Now an internal agent can orchestrate across teams, and an external agent (an agentic browser, a partner’s integration) can do something useful without human intervention.

The payoff: less chaos now, more demand later

If you do this, two things happen:

1. Your current operations get smoother.
   You spend less time firefighting issues caused by invisible complexity and conflicting truths.

2. You become legible to external agents.
   As browsers, sidecars and agent platforms start brokering more work, they see a set of clean capabilities and predictable behaviour – not a fuzzy, high-friction black box.

The agentic economy is not a Field of Dreams “build it and they will come”. It’s:

That starts with being honest about where you sit today on the spectrum from complicated to complex to chaotic, and taking deliberate steps to move in the right direction.

The dominant narrative is that AI reduces costs. We are told that headcount will drop, API calls are cheap, and the cost of intelligence is trending towards zero.

But inside most large organisations, the real cost of a single meaningful transaction isn’t computing power. It is buried in approvals, handoffs, email chains, and governance theatre.

AI doesn’t solve this. In fact, if you add high-speed agents to a high-friction organisation, you just get faster chaos.

From the outside, it looks like a modern firm. From the inside, it feels like wading through glue.

The Shift: If the external market moves to zero-friction agentic interactions while your internal operating model remains high-friction, you aren’t just inefficient. You are structurally obsolete.

In this article, I break down:

• Why the next era of the enterprise is not about firing people, but about removing internal drag.

• How to stress-test your 2026 investment roadmap for “Agent-Readiness.”

• A simple mapping exercise to expose where your real transaction costs live.

A challenge for this week: Run the mapping exercise inside on just one workflow. If you find the friction points but aren’t sure how to remove them without breaking the process, hit reply (or DM me).

The Post-Firm Enterprise: Why Your Internal Friction Is Your Biggest AI Risk

Everyone talks about agents killing transaction costs. Few admit how expensive transactions still are inside their own walls.

We like to tell ourselves that AI is pushing the cost of transactions towards zero.

API calls are cheap. Models are getting better. Agents will soon be able to talk to other agents and systems and vendors and customers. “Everything will just… happen.”

From a distance, it looks like the cost of getting something done is approaching zero.

Inside most large organisations, it’s nowhere near zero.

The real cost of a single meaningful transaction is buried in:

• approvals and sign-offs,

• handoffs between teams,

• email chains and Teams chats,

• risk and compliance reviews,

• “who actually owns this?”,

• “can you resend that deck?”,

• and a dozen systems nobody fully trusts.

The myth of zero transaction costs

There’s an old idea in economics: firms exist because it’s cheaper to do things inside the firm than in the open market.

Ronald Coase made this point almost a century ago, firms arise when the transaction costs of using the market (searching, negotiating, contracting) are higher than the cost of coordinating work inside a single organisation. If it’s cheaper to coordinate internally, you build a firm. If it’s cheaper to coordinate externally, you don’t need one.

That might have been true when “inside” meant:

• fewer contracts,

• simpler coordination,

• clearer ownership.

Today, for many enterprises, that logic has quietly flipped.

The apparent cost of doing something internally (no vendors, no procurement, no new contracts) looks low. The real cost, in time, attention, meetings, escalations, rework, is huge.

You see it every time you try to:

• launch a new product,

• change a process,

• or connect two systems that “should just talk to each other”.

On paper: trivial.
In reality: months of friction.

This is the transaction cost that rarely appears on a budget line, but shapes everything.

The post-firm enterprise

When people talk about the agentic economy, they often jump straight to a kind of utopia:

• Agents negotiating on our behalf.

• Work routing itself to the right capability.

• Processes that are self-optimising and self-healing.

It sounds like a world where you no longer need everyone under one metaphorical roof. Work flows through a network of capabilities, not a hierarchy of departments.

That is the direction of travel.

But most enterprises are structurally nowhere near ready for that world.

Instead, they’ve layered tools and automations on top of:

• legacy processes,

• brittle data,

• and organisational structures designed for a different era.

If you drop agents into that environment, you don’t get a post-firm enterprise.
You get faster chaos.

A post-firm enterprise isn’t “no firm”. It’s a firm that behaves as though the cost of coordination, decision-making, and execution is genuinely low, because it has done the hard work to reduce internal friction.

This is not a utopia pitch

This is where a lot of AI conversations lose people.

They imply that you should:

• throw away how you operate today,

• rebuild everything around agents,

• and hope it all works out.

That’s not the argument.

You still need to run the business. You still need to deliver this year’s numbers. Nobody is asking you to switch everything off tomorrow and wait for agents to land.

This is not a “build it and they will come” story.

It’s much more pragmatic:

• Reduce the internal friction that is silently taxing every transaction today.

• Design work and data flows that an agentic environment can plug into tomorrow.

You don’t get ready for the agentic economy by buying an “agent platform”.
You get ready by making it easier for any agent, human or AI, to see what’s going on and act end-to-end.

2026: the year you either get ready – or lock in another cycle of debt

If you’re planning major investments in 2026, new core platforms, AI programmes, operating model redesign, this is the moment to stress-test them against this reality.

For every significant initiative, ask three questions:

1. Does this reduce internal friction, or hide it?
   Are you genuinely simplifying workflows, approvals, and ownership – or just wrapping them in a prettier interface and a chatbot?

2. Does this make it easier for agents (human or AI) to act?
   Will a future agent be able to:

   • understand state,

   • take decisions,

   • and execute actions end-to-end
     using the data and processes you’re putting in place?

3. Are we increasing or decreasing our structural tech debt?
   Are you adding another siloed platform with yet another integration layer, or are you consolidating and clarifying how work flows across the enterprise?

If the honest answers are “no, no, and… probably not”, there’s a good chance you’re pre-funding the stranded assets of 2027 and 2028.

Tech debt isn’t just code

We usually talk about tech debt as:

• bad code,

• old systems,

• unfixed bugs.

Over the next five years, the most expensive tech debt will be:

• operating models you can’t unpick,

• platforms that can’t be easily orchestrated by agents,

• governance models that assume a human in every loop, every time.

A simple provocation to end with

Pick one high-value workflow in your business.

• Map every step, decision, and handoff.

• Label each step as Friction-creating or Friction-removing.

Then ask:

“If this had to run in a world where agents can see our data and act across our systems in real time, what would we strip out, what would we standardise, and what would we expose as clean capabilities?”

That’s the starting point of the post-firm enterprise.

Not shutting the firm down.
Not waiting for some AI utopia.

Just systematically reducing the internal friction that’s costing you today, and will decide whether you thrive or fall behind in the agentic economy tomorrow.

We are entering the biggest economic shift since the Industrial Revolution.

The “Enterprise” as we know it, a walled garden of humans, silos, and overheads, was designed for a world of high transaction costs. You needed to hire 1,000 people because it was the only way to coordinate work.

That era is ending.

In the Agentic Economy:

• Discovery is automated: Agents find products, not marketing departments.

• Transactions are programmatic: Agents negotiate and pay, not sales teams.

• Value is fluid: Agents assemble supply chains in real-time.

The Structural Risk: Most organisations are trying to “bolt on” AI to their existing structure. They are adding digital engines to a steam-powered chassis. This creates technical debt, governance risks, and massive inefficiency.

The Opportunity: The winners of the next decade won’t be the companies that “use AI.” They will be the companies that reimagine their operating model to be AI-Native.

This is why I launched Reimagined.

We exist to help senior leaders navigate this transition. We don’t sell software. We help you architect the Post-Firm Operating Model, one that captures the speed of agents without losing the governance of the enterprise.

What to expect from this list:

• The Signal: Deep analysis of the economics of the agent-to-agent world.

• The Patterns: How to structure data, governance, and value chains for the new economy.

• The Reality: “Red Pen” reviews of where current AI strategies are failing.

We are moving from pilots that promise to systems that deliver.

Welcome to the build.

Mark Strefford Founder, Reimagined Industries

Most conversations about AI inside big organisations start from a hidden assumption.

That the organisation itself still exists in anything like its current form in 10 years.

We built corporations because it was cheaper to do things inside the firm than to coordinate thousands of transactions in the market. Coordination had a cost. Contracts had a cost. Search had a cost. Trust had a cost.

AI agents crush those costs.

In an agentic world:

- people have their own personal agents

- those agents understand preferences, constraints, ethics and risk appetite

- they guard and use data on our behalf

- they discover options, assemble services, negotiate and handle the admin

- they can orchestrate transactions across hundreds of firms in seconds

If the cost of coordination tends to zero, so does the traditional advantage of the corporate.

Except where the underlying asset base is huge and physical. Think transport networks, energy infrastructure, heavy industry and a handful of other capital intensive sectors.

Those do not disappear. But the structure wrapped around them does not need to look like a 1980s conglomerate.

I have spent the last 20 years helping large organisations use data and technology to change how they work. Long before the current AI hype cycle, I was arguing that AI ROI had to start with the business problem, not the tools. Over and over I have seen the same pattern: leaders deprioritise structural risk while they chase short term efficiency wins.

The pattern is simple. Leaders optimise the wrong layer of the system.

Most AI roadmaps sit in the “efficiency inside today’s org chart” zone.

More pilots. More tools. More automation wrapped around legacy processes.

Useful, maybe. But it assumes the corporate structure is the thing to preserve.

What if that is the wrong problem?

If every customer, supplier and employee had their own powerful agents, would they still need your organisation, or would they route around it?

If your confidence rests on:

- long or complex contracts

- “owning” the customer relationship or channel

- being the default option inside someone else’s bundle or framework

- processes and systems that make switching slow or painful

then your moat is friction.

They will route around any node in the network that does not deliver clear value, reliability and trust.

If you are a CEO, CFO or CTO, try this prompt with your team next week:

“Assume every one of our customers has their own AI agent in three years.

List the top five reasons their agent would choose to work with us.

Then list the top five reasons it would quietly route around us.”

The gap between those two lists is where your real strategy work starts.

ROI in year one was on the table, and they said “No”!

Not because the technology couldn’t deliver. But because nobody wanted to enforce consistency across an ecosystem of external partners. So Instead of fixing the upstream problem, months were spent trying to code around a problem that didn’t need to exist.

When automation meets reality

I was working for a global consultancy on one of its major public-sector accounts. Our task was to automate a core process, the kind of initiative that looks simple on paper, but rarely is.

Technically, we could have automated 60-70% of it and delivered returns inside twelve months. But the problem wasn’t technical. It was upstream dependencies spread across an ecosystem of external partners who each interpreted the same “standard” process differently.

The central organisation could see the inefficiency but wouldn’t enforce alignment. So the project spent months and significant budget trying to automate around inconsistency that could have been eliminated with a handful of difficult conversations.

This is what Gartner now documents as the “10 ancillary, hidden costs” problem: organisations budget for the technology, but not for the ecosystem coordination it exposes.

What the travel industry taught me

I saw the same pattern in 2014, leading a redesign for an online travel provider.

This wasn’t even AI. It was a pricing engine rebuilt from first principles so they could onboard new hotel chains in days instead of months, and handle special rates and non-standard pricing as it arrived.

They had competitive rates from hotels, including special offers and non-standard pricing models that could’ve won them business. But their old system couldn’t handle the variety, so they just threw it away. All of it.

10% revenue loss. Every year. Not because competitors had better deals, but because they couldn’t surface what they already had fast enough.

The technology worked. Leadership wanted it. But on the ground, people had built careers around the old platform. It defined their expertise, their status, their value to the organisation.

The resistance wasn’t about feasibility, it was about fear. Fear of redundancy. Fear of losing what had once made them important.

This maps directly to what Gartner found:

The technology delivers capability, but translating that into business value requires confronting how work, power, and incentives are structured, and most organisations stop short.

The pattern

This keeps repeating.

Organisations say they want transformation, then stop short of confronting what it actually requires. AI is just the latest chapter. When systems, incentives, and power structures are built around the past, new technology doesn’t fix the problem, it exposes it in sharper detail.

That’s when leaders face the real test: redesign how value flows, or just automate faster and hope for the best.

What it actually takes

The problem isn’t technical. It never was.

It starts with making the cost of inaction impossible to ignore, not through another deck, but by showing executives exactly what staying still is worth. Then you pull the conversation out of IT entirely, because technology teams were never going to fix ecosystem dynamics or boardroom misalignment.

This requires senior leaders willing to sit across the table from each other first, before they ever talk to partners. If the exec team can’t align on what problem they’re actually solving, external coordination is a fantasy.

Once internal incentives line up, then you can find the levers that move partners. Not mandate. Not compliance theatre. The actual incentives that make alignment worth their while.

And you have to help people see that their value isn’t locked into the old system, it’s in being the ones with enough context to architect what comes next.

Reimagining isn’t about fixing tech or what’s just inside your walls. It’s about redesigning how value flows through the ecosystem and how people create value within it. That means someone has to own the conversations, internal and external, that technology can’t solve.

Reimagining: The discipline

That’s what “reimagining” really means. It’s not a slogan. It’s a discipline.

When you take this approach, you win either way. Even if you’re skeptical about AI, you end up with cleaner operations and teams that spend time creating value instead of managing workarounds. AI just becomes the accelerant on top.

But if you’re all-in on AI, this gives you the foundation where intelligence can actually compound. Because data, process, and people already move in the same direction.

Reimagining isn’t about a single breakthrough. It’s the compounding effect of design, discipline, and momentum working together over time.

The question isn’t whether your organisation can change.

It’s whether you’re willing to see clearly what you’ve stopped questioning, and start there.

If you’re unclear on the cost of inaction, reply to this email and let’s talk

I’ve been thinking about what happens to aggregator businesses when AI agents become the primary way transactions get executed.

Not AI helping humans search better. That’s happening already and every aggregator is investing in it. I mean when the AI doesn’t just assist, but actually executes: searches, evaluates, negotiates, and completes transactions on behalf of humans, without the human clicking through your interface.

This isn’t theoretical. Perplexity bypasses traditional search. OpenAI is building browser agents and an agent marketplace. Anthropic’s Model Context Protocol lets agents discover and use services programmatically. The infrastructure is being built right now.

For twenty years, aggregators have succeeded by being the search layer between supply and demand. Property portals. Job boards. Comparison sites. Energy switchers. Travel booking platforms. Insurance aggregators. The pattern was always the same: fragment the internet, reunify it behind your interface, tax the reunion.

It worked because humans search like humans. Slowly, visually, clicking through pages whenever they have time. Your value was simple: be where the eyeballs are, make the experience better than visiting dozens of individual websites, charge suppliers for access to those eyeballs.

But AI agents don’t search like humans. An agent doesn’t care about your mobile app or your UX. It doesn’t get tired. It doesn’t need you to reunify the internet. It can query 47 energy suppliers, 200 hotels, or 30 insurance providers simultaneously and synthesise the results in seconds.

If your value proposition is “we make search easier for humans,” what happens when search isn’t the bottleneck any more?

Where Aggregators Are Investing Today

Major aggregators are making substantial AI investments. Rightmove’s recent announcement is market leading: £60m over three years focused on consumer innovation, operational transformation, and R&D for new growth.

Their 2026 allocation of £12m spans:

• Consumer experience: £3.5m (conversational search, AI-powered recommendations)

• App development: £2.1m

• Operational transformation: £2.0m (automated workflows, AI-powered support)

• New growth initiatives: £3.1m

• Support functions: £1.3m

They’re executing 27 AI initiatives spanning vendor prediction, online valuations, conversational search, and AI-powered styling tools.

Similar patterns appear across sectors. Energy comparison sites are investing in smart tariff recommendations. Insurance aggregators are deploying quote optimisation engines. The specifics vary, but the pattern is consistent: AI investments focused on improving the human experience.

These investments make complete sense. Better consumer experiences drive engagement. Operational efficiency improves margins. New revenue streams diversify the business.

But here’s what I notice: every investment category is either consumer facing (making the human experience better) or operational (making internal processes more efficient).

What’s less evident is infrastructure that lets AI agents transact programmatically. Maybe some aggregators are building this quietly. The visible focus remains on AI-assisted human experiences rather than agent-native infrastructure.

Why Aggregators Are Actually Well-Positioned

Here’s the counterintuitive bit: aggregators could be even more valuable in agentic economies than they are today. But only if they build the right infrastructure.

Platform intelligence compounds with transaction volume

When transactions flow through your platform, you accumulate intelligence that makes every subsequent transaction better.

For example, property platforms learn timing patterns (Bristol properties: 6 weeks offer to completion; London: 12 weeks), pricing signals (suburban asking prices negotiate 8%; city apartments rarely discount beyond 3%), workflow optimisation (digital-first conveyancers complete 40% faster).

Energy platforms understand consumption patterns by property type, seasonal switching windows, supplier reliability scores, optimal timing to avoid exit fees.

Travel platforms know route-specific pricing patterns, hotel cancellation behaviours, optimal booking windows, supplier service levels.

Insurance platforms track risk assessment refinements, claims processing speeds by provider, renewal negotiation leverage points.

This intelligence gets encoded in your API responses, search rankings, and workflow suggestions.

When an agent queries your platform, whether it’s a cloud-based service like ChatGPT or a local open-source model running on someone’s phone, it benefits from that accumulated intelligence.

Example: Smart platform vs basic API

Agent query: “Find 3-bed properties in Bristol, £400-500k, schedule viewings this week”

A basic API returns:

{

“properties”: [...]

}

An intelligent platform returns:

{

“properties”: [...],

“metadata”: {

“typical_offer_to_completion”: “6 weeks”,

“price_negotiation_range”: “6-10%”,

“optimal_viewing_times”: [”Tue 2-4pm”, “Sat 10am-12pm”],

“fast_response_agents”: true,

“typical_documents_required”: [...]

}

}

The same pattern applies across sectors:

Energy switching: Not just tariff rates, but scenario modelling (if you charge your EV at night it looks like this, if you install solar it looks like that), supplier switching reliability (how often switches fail, how long they actually take), exit fee timing windows.

Travel booking: Not just availability, but preference-based filtering (you stayed in boutique hotels in Barcelona and Berlin, here’s similar in Lyon), cross-platform learning (your preferences travel with you, not locked in one booking site), contextual intelligence (you always book window seats, you avoid properties near nightlife).

Insurance quotes: Not just premiums, but claims processing reputation, renewal leverage points, coverage gap analysis.

The agent using your platform completes transactions faster with better outcomes because your platform is smarter, regardless of whether the agent itself is sophisticated or basic.

Your competitors can copy your API structure. They can’t copy the transaction intelligence that makes your responses valuable.

Small players won’t build this themselves

Individual suppliers (estate agents, energy retailers, hotels, insurance providers) could theoretically build agent-readable infrastructure themselves. In practice, they won’t.

Because it’s infrastructure, not differentiation. A local estate agent doesn’t win by having better API protocols than the agent down the street. They win on properties, service, and local knowledge. A small energy supplier doesn’t differentiate on API design; they differentiate on tariff innovation or customer service.

That’s your opportunity: become the shared infrastructure layer that small players plug into. Just like they use Stripe instead of building payment processing, they’ll use your protocols instead of building their own.

You can shape the protocol while it’s still forming

In open markets, protocols eventually commoditise. But the first mover gets to shape what gets standardised.

If you define the property listing schema, you ensure it includes fields you already have (transaction history, verification status, pricing benchmarks) that smaller players don’t. If you define the energy switching protocol, you embed the consumption patterns and supplier reliability data you’ve accumulated. If you define the insurance quote schema, you include the claims processing metrics and coverage analysis you’ve built.

By the time competitors catch up, you’ve already captured the transaction graph that makes those fields valuable.

You don’t need to own the standard. You need to shape it before someone else does.

What Infrastructure the Agentic Economy Actually Needs

The agentic economy requires six foundational infrastructure pillars to function. These aren’t aggregator-specific. They’re universal requirements for any market where AI agents transact autonomously.

Think of them like HTTPS and payment gateways for e-commerce. Not optional, not differentiating on their own, just foundational.

The six pillars:

1. Discoverability – How agents find and understand what’s available (structured schemas, multimodal search APIs, machine-readable formats)

2. Trust & Verification – How agents validate legitimacy and track records (verifiable credentials, queryable transaction history, third-party verification hooks)

3. Payments & Settlement – How value exchanges hands (embedded payment rails, escrow, dispute resolution, multi-party settlement)

4. Orchestration – How multi-party workflows execute (Model Context Protocol for tool integration, workflow state persistence, agent-to-agent messaging, parallel coordination)

5. Attribution – How contributions get recognised when multiple agents participate (explicit attribution rules, contribution tracking, flexible compensation models)

6. Privacy & Consent – How user preferences are maintained when agents act autonomously (preference APIs, consent tokens, data minimisation, revocation mechanisms)

I’m not going to detail each pillar here. That’s a separate piece. But the key point: these need to exist for agentic economies to function at all.

Someone will build them. The question is who.

Why Aggregators Are Natural Infrastructure Providers

You’re uniquely positioned to build these pillars for your vertical because you’re already the transaction intermediary. You have structural advantages that make you the natural provider:

Transaction volume: You process enough transactions to identify patterns and build intelligence that individual suppliers can’t match. One major property aggregator processes hundreds of millions of listed items and generates billions of consumer signals annually. That data density creates platform effects. Every transaction makes the platform smarter for the next agent.

Supplier relationships: You already have commercial relationships with suppliers in your sector. Adding API protocols to existing partnerships is easier than building those relationships from scratch. Small suppliers trust you because you’re already embedded in their operations.

Trust graph: You’ve accumulated reputation data through repeated transactions. Agents need that trust layer. They can’t independently verify every supplier. Your platform becomes the verification mechanism agents rely on.

Capital to invest: Building these pillars requires upfront investment before revenue materialises. You have the balance sheet and cash flow to fund infrastructure development. Startups building agent-first from scratch don’t have that luxury.

Domain intelligence: Property aggregators understand conveyancing workflows, stamp duty calculations, and local market dynamics. Energy aggregators understand consumption patterns, switching windows, and regulatory constraints. Travel platforms understand route economics and supplier behaviours. That domain knowledge gets encoded in your APIs and makes them genuinely useful to agents rather than just data pipes.

eBay’s acquisition of PayPal (2002) wasn’t about owning payments infrastructure for its own sake. It was about controlling the trust and friction points that affected transaction completion. The eventual spin-out (2015) was financial engineering, not a statement that payments integration was strategically worthless. Seamless, trusted payments were core to eBay’s marketplace success.

The parallel question for aggregators: is transaction intelligence infrastructure you control, or a commodity service you consume? I’d argue it’s different from payments. Payments are horizontal infrastructure. The same mechanics work across every marketplace. Transaction intelligence is vertical, deeply specific to your domain, your suppliers, your transaction patterns.

If you don’t build these pillars, someone else will. But they’ll be starting from scratch while you’re already processing transactions and accumulating the intelligence that makes the infrastructure valuable.

The Competitive Clock

You’re not the only one who could build this. Your competitors see the same future. So do horizontal platforms (Google, Microsoft, Amazon) that might add vertical depth. So do startups building agent-first from scratch.

OpenAI’s emerging agent marketplace, Anthropic’s Model Context Protocol (MCP) for tool integration, Perplexity’s direct answer engines. These aren’t hypothetical. The infrastructure for agents to discover and use services is being built right now. The question is whether aggregators become preferred service providers in these marketplaces or get bypassed entirely.

An agent that’s completed 500 property transactions through your platform knows which estate agents are reliable, what pricing patterns mean, what workflows succeed. An agent that’s switched energy suppliers 1,000 times through your platform knows which suppliers process switches fastest, which have hidden fees, which offer the best customer service.

Even if a competitor launches an identical protocol, agents would have to relearn everything from scratch.

But that intelligence only accumulates if you’re processing transactions, not just facilitating search.

Brand still matters. Supplier relationships still matter. But in agentic economies where agents make decisions based on structured data and verified track records, those legacy advantages weaken. Transaction intelligence becomes disproportionately important.

The race isn’t “who builds the prettiest agent interface.” It’s “who captures the transaction graph first.”

Consumer AI AND Agent Infrastructure

The investments aggregators are making in consumer-facing AI are necessary and valuable. Conversational search, personalised recommendations, automated operations. All good moves.

Many aggregators offer search interfaces that are evolutions of 10-year-old capabilities. That work needs doing. Better search drives engagement. Operational efficiency improves margins.

But these investments create an adjacent question: as AI gets better at helping humans, when does the ‘assistant’ become an ‘agent’ that transacts autonomously? And when that happens, what infrastructure needs to exist?

This isn’t either/or. Not “consumer AI instead of agent infrastructure.”

You need consumer-facing AI to deepen engagement with humans using your platform today.

AND you need agent-facing infrastructure to ensure agents transacting on behalf of humans use your platform tomorrow.

The urgency isn’t that you’re behind. It’s that you’re investing heavily NOW in AI, and agent infrastructure should be a parallel workstream, not a sequential one.

Here’s the trap: fixing your search interface is necessary work. But if that’s ALL you’re doing, you’re still building for yesterday’s transaction model. You’re optimising for human search when the game is shifting to agent transactions.

Building consumer AI first, then agent infrastructure later, means you miss the window to shape the protocol. By the time you’re ready, the standards may already be set, and not to your advantage.

This is the difference between fixing and reimagining. Fixes keep you competitive in the current model. Reimagining prepares you for the next one.

What Happens Next

I’m publishing this openly because I think the pattern is important and time-sensitive. If you’re running an aggregator and this resonates, take it and run with it.

The six infrastructure pillars deserve detailed exploration. That’s the next piece. But the strategic insight stands alone: aggregators are investing heavily in AI to improve human experiences while the real transformation is agents transacting autonomously.

The organisations that see this early and build agent-native infrastructure won’t just survive the transition. They’ll be more valuable than they are today.

The ones that don’t will become legacy search layers in a world where search isn’t the bottleneck any more.

Mark Strefford helps organisations reimagine their business architecture for AI-enabled economies. He focuses on competitive economics and ecosystem implications, not just AI deployment. To schedule a confidential 1-to-1 session, book here.