Why closing the agentic readiness gap starts with who owns the delivery tier.
I ended the last piece on a question I didn't answer. If agentic traffic against your platform doubled tomorrow, what would break first?
Some context on why that isn't hypothetical. Imperva's 2026 Bad Bot Report puts automated traffic at more than 53% of all web traffic last year, up from 51%, with human traffic down to 47% and still falling. 27% of bot attacks now target API endpoints directly. Not all that traffic is agentic and plenty of it is hostile, but the direction holds either way. Most of what arrives at your platform already isn't a person.
Almost everyone who answered the question gave me a technical answer. The rendering layer, the content APIs, cache behavior under programmatic load. All plausible. And every one of them is cheap to fix if somebody was already watching it, which is the actual problem.
So the more useful answer is this. Whatever breaks first will be whatever nobody owns. In most enterprise stacks I see, that is the entire delivery tier.
Visibility for agents, experiences for humans
I was at Sitecore's sales kickoff recently, where the AI conversation was constant. Much of it centered on the Scrunch acquisition and content visibility, making sure a brand shows up accurately inside the AI answers where people now form a first impression. That is the right problem to be working on. It also creates a double demand that mostly goes unsaid. Content must be visible to agents and still deliver a proper experience to the humans behind them. Only one of those jobs is getting the attention.
There's a second thing about visibility work that doesn't get said out loud. It succeeds by getting agents to call you more often, which is the entire point of it. Every one of those calls lands on the delivery tier, so the better your visibility strategy performs, the more traffic arrives from systems that behave nothing like people.
The agent layer arrived with paperwork. The tier underneath didn't.
The clearest way to see this gap has nothing to do with architecture. It's a procurement question.
A new agentic capability arrives fully sponsored: an approved budget, an executive sponsor, a business case with numbers attached and a named program owner. Ask who is accountable and what happens if it underdelivers, and you get a straight answer on the spot.
Now ask the same questions about the delivery infrastructure it runs on. Who holds the budget line? Who is the executive sponsor? Who is accountable for capacity, for the security posture as it drifts, for the upgrade path, for the phone call at 2am? Most of the time you get four partial answers from four different people, and a pause.
That pause costs you in four ways.
- Detection. Nobody is watching, so problems get noticed late. With programmatic traffic that can be days after it started.
- Decision. Someone has to approve a spend, a config change or a rollback. With no clear owner it escalates, and the incident runs until the ownership question gets settled.
- Drift. Capacity headroom shrinks, dependencies age and security posture erodes, because maintaining them isn't in anyone's objectives. You find out in an audit or a penetration test.
- Dollars. This one is quiet, with no error page and no alert: agents time out mid-workflow, journeys don't complete, and the loss shows up in your conversion numbers. It looks like a marketing problem, so you can spend a quarter fixing the wrong thing.
The cost is the delay. When something breaks, the organization must work out whose problem it is before anyone starts fixing it. It was created by a decision, and it can be closed by one, so it doesn't need a rebuild.
There’s a gap no one’s owning
Nobody dropped the delivery tier. It fell between the SI, the vendor, the cloud provider and your own team. It's the predictable outcome of how these platforms get assembled, by parties who are each correct about the limits of their own responsibility.
The systems integrator built it well and scoped out at go-live, because that was the contract. The CMS vendor's SLA covers the CMS, not your rendering layer, your pipelines, or how your architecture behaves under sustained programmatic load. The cloud provider's shared responsibility model puts the workload on you. That is the deal you signed. The internal platform team then inherited the running of it, usually without dedicated headcount, a budget line, or a mandate to change anything structural.
Everyone met their contract. Nobody owned the outcome. That's the real problem, and it's why reorganizing the team, switching vendors, or renegotiating the SLA won't fix it. You can't fix an ownership gap by rearranging the people around it.
Human traffic forgave this. Agent traffic won't.
Unowned tiers can run for years without obvious trouble, because human traffic is forgiving. People arrive in patterns you can forecast, they tolerate a slow page, and when they give up they do it quietly, so the impact reads as a conversion problem rather than an infrastructure one.
Agent traffic changes that. It's programmatic, persistent and high frequency. It calls, and it calls again. When responses slow down it retries, which turns a small degradation into a larger one. Load is what surfaces an unowned tier, and at more than half of all web traffic, that load is already here.
Why unlimited authors didn't make publishing faster
There's a second version of this problem on the marketing side rather than in engineering, and it's the one most boards are already feeling without connecting it back to infrastructure.
For years the constraint was resources. Not enough developers, not enough authors, not enough hours in the release calendar. AI has effectively removed it, so publishing should be dramatically faster. In most organizations it isn't, because the bottleneck moved. It now sits in everything between a finished asset and a live experience: environments, approvals, pipelines, security review, release windows. Marketers don't spin up environments, approve code or manage pipelines, and yet every campaign they run depends on someone doing all three. Governance now sets the ceiling on what AI can practically do for a marketing team.
That's the same unowned tier from the other end of the business, which is why it lands on every digital team rather than the platform group alone. Marketing waits on it and gets asked why campaigns are slow. Engineering firefights it and gets asked why costs are up. Security inherits a posture nobody maintains. When the constraint on growth sits in a tier with no owner, it has stopped being an IT issue.
Ownership is four things, and most teams have two
Ownership gets asserted far more often than it exists. It needs four things, and they only work together.
- A named owner. One person or team. Not a committee, and not "the platform group" as a general concept.
- A budget line. If maintaining the tier competes with feature work for the same money, feature work wins every time, and the tier degrades slowly enough that nobody has to decide anything.
- An SLA somebody has signed. An internal commitment with consequences attached, or a contractual one with a third party. An expectation is not an SLA.
- Observability the owner can act on. Accountability without the ability to see inside the rendering stack, the content APIs and the pipelines while something is happening isn't accountability. It's deciding in advance who gets held responsible afterwards.
Ownership without visibility is a title. Visibility without ownership is a dashboard nobody has to look at. Put all four in place and the failures above stop being organizational problems and become engineering problems, which are much easier to solve.
A structural problem needs a structural fix
The reason I keep pushing on this is that it can't be bought as a tool. There's no product you can add to an unowned tier that makes it owned.
The fix is a decision. Either you resource the tier internally, with real headcount, a budget, a mandate and the instrumentation to run it, or you contract it to someone who signs for it. Both are legitimate, and plenty of organizations should do the first. What doesn't work is leaving it ambiguous and hoping the question never gets asked under pressure.
A further constraint is tightening at the same time. Residency and sovereignty requirements keep expanding, from Canada through most of the global markets our customers operate in. The move toward genuine 1:1 personalization pushes more customer data through the delivery tier. Where that data sits, which jurisdiction holds it, and who can prove either of those things, are now design requirements. An unowned tier can't answer them, because answering them means holding the authority to make architectural decisions about it.
The organizations handling this best often had no choice. In regulated industries an auditor made ownership explicit years ago. Someone had to be named, every change had to be provable, and nothing could be left to convention. None of it was done in anticipation of agentic AI, and it turns out to be the same discipline.
What to insist on, whoever ends up holding it
Whether you build the internal case for owning the tier or put it out to a third party, the things worth insisting on are the same. It should run inside your own cloud tenant, within your governed boundary. That gives the residency question a clear answer, and it keeps control from moving offshore along with the accountability. Observability should be deep enough to act on in the moment, not just deep enough to report on afterwards. Security posture and deployment discipline should be part of the architecture rather than a review cycle wrapped around it. And there should be a name and a signed SLA attached, with consequences that are real.
That list is what we built Dataweavers to do, so I'm not a neutral party on it. It holds regardless of who runs the tier for you, and it's a fair test to put to us or to anyone else.
A practical test
Take three questions into your next platform review.
- Who owns capacity for the delivery tier?
- Who has signed an SLA for it?
- Who gets paged when it degrades without throwing an error?
Three different names, or three versions of "it depends", and you've found the gap. Closing it is a decision about ownership.
The agent layer will keep getting better funded, and the tier underneath will keep carrying more of the load. At some point somebody has to put their name against it. Far better to do that deliberately than during a production incident.
Next month I want to put a number on what leaving it unowned costs, because in my experience it is already being paid, just not on any line item anyone is looking at.
If the ownership question is landing
We've put together a reference for exactly this conversation: the layers of an enterprise delivery tier, what each party in a typical stack is genuinely accountable for, and where the gaps usually sit.
Who Owns What: A Responsibility Map for the Enterprise Delivery Tier
