AI models continue to advance faster than enterprise deployment is able to evolve. Several recent reports say the same thing: model capability is not the real bottleneck — the surrounding architecture is what determines whether an agent can be trusted to run unsupervised in production. The gap between the two is concerning, and this is where the real engineering effort is migrating.
As the models absorb more of what used to require careful prompting, the hard work shifts into the scaffolding around them — what’s increasingly being called the “harness” — and deciding what belongs in that harness turns out to be less of a technical question than an organisational one: who owns which layer, and how the operating model itself needs to change.
VentureBeat’s enterprise agent governance research found enterprises have deployed agents well ahead of the controls needed to manage them, and that 71% of enterprises say a quarter or fewer of their deployed agents can complete multi-step work autonomously; only 10% say true agents make up the majority of what they run.
Further evidence that governance, not just capability, is a chokepoint in deployment comes from Domino Data Lab’s fifth annual survey of enterprise AI leaders. As reported by diginomica, organisations with fully-integrated AI governance are 3.9x more likely to have agents in governed production than those with partial governance, and 75% of well-governed organisations report improved delivery velocity versus 23% of poorly-governed ones.
Agentic AI adoption needs a system-builder approach
In a recent paper about the ‘deployment wall’, Fabricio Costa tries to quantify the ‘seams’ that define boundaries an AI capability must cross to function in an enterprise, which are where friction accumulates. He cites six seams that recur across engagements, corroborated by research reports and surveys:
Fragmented data
Identity & access
Security & compliance
Governance
Change management
Cost control
Taken together, these reports and analyses might suggest that enterprise agentic AI will struggle to demonstrate return on investment over the long-term, and yet the reality we are seeing in business functions is a lot more optimistic and positive about the adoption journey than surveys suggest.
Azeem Azhar and Nathan Warren shared a useful essay on this topic a few days ago, which starts by reminding us that — as with any investment J-curve — success and failure can look the same in the early stages of a cycle. And given that the upfront cost is in less visible areas like organisational learning, workflow re-design and architecture, not just software, ROI attribution can be hard to determine.
The authors contrast three archetypes of companies experimenting with AI or other general purpose technologies:
Bounded adopters find something that works, put it to work, and then stop experimenting.
The project accumulator keeps exploring, but rarely learns, launching new projects before figuring out what separates the winners from the losers.
A system builder ensures every project leaves behind infrastructure and knowledge that makes the next project easier, and that accumulated capability shows up as a rising chance that future projects succeed.
But the challenge for system builders is that the technology is changing so rapidly at every level, that even the architectural foundations are continually evolving. Forrester’s latest take on agentic architecture describes this challenge, and finds that enterprise teams are moving agentic projects to production faster than they are able to develop the architectural disciplines needed to support them, with 60% of enterprise AI decision-makers citing “agentic sprawl” as a problem. According to this report, enterprises making real progress aren’t converging on a stable target architecture at all; instead they are building modular capability designed to be re-shaped through continuous evolution.
This reminds me of the top-down construction method pioneered by the builders of the iconic Shard building in London. Because of a tight site that was bounded by critical infrastructure on all sides and unstable ground conditions, they chose to build upwards and downwards at the same time, evolving and hardening the foundation along the way so that the building’s core was 23 stories high before the subterranean structure was complete.
In building out agentic AI architecture, we should expect that the ground will continue to shift underneath us, so we don’t have the luxury of building the perfect foundations and supporting architecture before we deploy agentic systems on top. We might need to keep adding and hardening architectural layers below the surface to support what we are building, and whilst we should try to maintain a stable view of the organisational system we are aiming for, the supporting elements will flex and evolve as we go.
But what should we own as organisational foundations, and what architectural elements can be swapped out with the tooling?
What is agent harness, and what is organisational architecture?
Ken Huang recently tried to capture a definition of Harness Engineering as the Umbrella Discipline for Agentic AI. He argues activity areas such as prompt engineering, context engineering, loop engineering, and graph engineering (multi-agent orchestration), are not competing approaches but rather stacked layers that are needed to build the control plane, memory, runtime and guardrails so that agents based on probabilistic models can run reliably in production.
But with frontier AI models trying to move up the value chain to include more of these harness elements, the decision on which parts to build rather than rent or buy is not always obvious.
Hugo Bowne-Anderson’s essay Stop Overengineering Your Agent Harness argues this discourse is dominated by the hardest cases — coding agents, personal agents — when most production agents actually tend to need fewer tools to stay coordinated, and less retained context than the most complex use cases might assume:
Nicolay Gerold (Amp Code) calls this the Kirby effect: every component in a harness encodes an assumption about something the model cannot do on its own. As models improve, those assumptions expire, and the corresponding harness features can be removed.
So the question of how much harness engineering firms should do is not an easy one. As a rule of thumb, any harness layer that is all about workflows, context and knowledge specific to the firm should absolutely be owned and managed internally as organisational architecture, but more tech-specific harness layers that are about how the models work might be considered as part of the model itself - if not now, then likely in the future.
Where the line is unclear, a good question to ask is do we own the learning loop for this agent or tool?
The recognition that a lot of this learning happens above the model and even the harness is one factor that has driven model providers to adopt the approach of using Forward Deployed Engineers (FDEs) inside firms to capture more of it.
AWS’s new Forward Deployed Engineering unit sends five-to-six-person teams on 45-day client engagements, but according to diginomica’s interview with Francesca Vasquez, the deliverable AWS now emphasises isn’t the working system but the knowledge graph the engagement leaves behind, inverting the usual professional-services model where the human relationship is the retained asset.
We are also seeing more emerging tech solutions aimed at enabling agents to run their own learning loops. Yohei Nakajima’s ActiveGraph is a bet that an immutable, append-only event log — not the model — is the key unit of agent design, helping agents to replay, roll back and fork their own state. Software veteran Jon Udell’s smaller, personal version of the same idea — indexing Claude Code/Codex session logs, git commits and issues into one searchable memory layer with SQLite — shows the pattern could be relevant even to small, personal agents.
The organisational OS: building up and down from the middle of the stack
Stuart Winter-Tear brings this back towards our own focus and thesis in The Operating Model Is the Real AI Harness: if the software layer determines capability, organisational design and system design become the same exercise, which means we need leaders to focus on organisational architecture, and not just performance.
Every harness inherits the operating model it is built to serve.
That sounds abstract until you look at what a harness is actually trying to do. It has to coordinate work, retrieve knowledge, invoke tools, route decisions, escalate exceptions and operate within whatever governance exists around it. None of those responsibilities originate inside the harness. They originate in the operating model. The harness is where the operating model becomes software.
Thoughtworks made a similar argument two weeks ago about the need for an operating system for enterprise AI that puts governance, ownership and organisational learning ahead of technical architecture.
This is starting to look like a workable division of labour:
Leaders own the organisational architecture brief and how things fit together.
Function leads own and re-architect the major workflows and processes as agentic capabilities.
FDEs or internal system designers work with business functions to design, build and run the agents, models and supporting harnesses.
Knowledge and data engineers work on the piping and connectors that will provide the lifeblood for these systems to operate.
AI infrastructure teams build out the technical architecture that is needed to support the whole system, independent of models and their harnesses.
The interesting question is how can firms connect and coordinate this effort - building and re-factoring foundations below, whilst creating new capabilities on top - without reverting to old change management command-and-control methods that would kill much of the learning that is being generated by the current period of rapid discovery and evolution.
Agentic AI in the enterprise might feel slightly chaotic today, but that could be a feature, not a bug, at this early stage of the investment cycle.
The organisational-architecture point is the one I keep returning to.
Concretely, two artifacts do most of the work: a cost per successful run, and a written kill criterion signed by the budget owner on day one.
Without the first you can't defend the line item. Without the second the pilot becomes headcount and stops being reviewable at all.