Over the past three months I have made one argument in three parts.
In July, I wrote that agents now call your platform far more often than people do, and that the pressure lands on the delivery tier. By delivery tier I mean everything between the CMS and the customer: the environments, the pipelines and the infrastructure that serves every request.
In August, I argued that in most enterprises nobody owns that tier. The agent layer got a budget and a sponsor. The tier underneath it fell between the SI, the CMS vendor, the cloud provider and the internal team.
In September, I showed that leaving it unowned already costs money. That cost never appears on an invoice, so nobody manages it. Last month's piece is here: What Your CMS Vendor Forgot to Put in the Proposal.
The most common response has been a fair question. If we name an owner and fund the tier, what do we hold them to?
Naming an owner without a standard just moves the ambiguity onto one person's desk.
Below are six things a well-run delivery tier should be able to show you, and what a good and a bad answer sound like for each. They are written for whoever now runs the tier. You can put the same six to a vendor, including us, but they are most useful run against your own platform first.
There are plenty of best practice lists for running a digital platform. Most are hard to use, because they describe what a team does rather than what it can show you. Monitoring is in place. Security is reviewed. Capacity is managed. All three are true of platforms that fall over.
A standard is only useful if failing it is obvious. So each of the six below names something specific the tier should be able to produce, and what a good and a bad answer sound like. Where I can give you a number, I have. Where I cannot, I have described a bad answer, which works almost as well.
Run them against your own delivery tier. It takes an afternoon, and the pattern in the gaps usually tells you more than any single answer.
The weak version is a team that watches utilization and adds capacity when it climbs. That is reactive, and agent traffic can climb faster than the team can respond.
Ask for headroom as a multiple of current peak rather than a percentage margin, and ask for it to come from a test rather than a model. The test should look like agent traffic: steady load rather than a daily curve, mostly API calls rather than page views, and including retries, because retries are what turn a small slowdown into an outage. It should also have been rerun since your last major release.
A good answer is a number with a date on it. “We scale automatically” is a bad answer, because it tells you how scaling works without saying where it stops. So is a load test from eighteen months and three releases ago, which describes a platform you no longer run.
Most enterprises have monitoring. Far fewer can say, while something is going wrong, which part is slow and for whom.
That matters because agent traffic often fails without an error. Responses slow down, calls time out partway through a workflow, and your dashboards stay green while journeys quietly stop completing. Uptime monitoring cannot see that. You need to see into the rendering layer, the content APIs and the pipelines, joined up well enough to follow one request through all three.
The test is simple. Ask someone to take a real request from last week and trace it end to end within the length of a meeting, because that is the speed an incident demands. If it takes a week, a change request, or turning logging on first, you have reporting. Reporting tells you what happened afterwards. You are paying for the ability to act while it is happening.
Marketing and engineering feel this one from opposite ends. Most organizations have security controls. The question is whether they run automatically in the pipeline or wait for a person to approve them.
Your team should know the typical time from a finished change to it being live, and how much of that is work and how much is waiting. Waiting should be the smaller share. In most organizations it is the larger one. That waiting is the governance ceiling I wrote about in August, and it is why AI made content faster to produce while publishing stayed just as slow.
A good answer has a median, a split, and a plan to cut the waiting. The worrying answer is that halving it would take more people. That means the controls are in the wrong place, and every increase in volume makes it worse.
A CMS SLA covers the CMS being available. That is a much narrower promise than the one you need.
The SLA you need covers the platform being slow as well as being down. That means a threshold for slow as well as for outage, coverage of the rendering layer and the content APIs as well as the CMS, committed times to respond and restore, and a consequence somebody actually feels. It should have a name on it. An internal commitment counts, as long as someone signed it rather than assumed it.
The test is one question. What does our SLA say happens when the platform is up, but slow enough that agent workflows stop completing? Most SLAs say nothing about that case, and it is the one you are most likely to hit.
Rules on where data must be held keep expanding, and personalization pushes more customer data through the delivery tier every year. The questions come from auditors, from regulators and, more and more, from your own customers' procurement teams.
Good here is unglamorous. You should be able to say which cloud tenant the delivery tier runs in, which jurisdiction holds the data and who has admin access, with evidence for all three, without commissioning a project to find out. Running inside your own cloud tenant makes this much simpler, because the boundary is one you already govern. As I covered last month, it often also decides whether committed Azure spend can pay for the tier.
A good answer comes the same day, with evidence. If you would need to ask the SI or the cloud provider first, fix that before somebody external asks.
Drift is slow decay rather than sudden failure. Dependencies age, headroom shrinks, configuration moves away from what is documented, and security posture erodes quietly enough that nothing prompts a decision. Most of the costs in last month's piece trace back to it.
Staying current should be ongoing work with time set aside for it, rather than a project raised after an audit finds something. Ask for a number: how far behind current versions you are, tracked over time, reviewed by somebody monthly, and going down.
If nobody owns that number, drift is already happening. You will find out about it in a penetration test or an audit.
Each one asks for evidence: a test result with a date, a trace, a median, a signed document, a number somebody reviews monthly. A well-run tier can produce those at short notice. A tier that is only said to be well run produces a meeting.
Asking for evidence is also fair, because it does not reward whoever presents best. It works the same way on your own platform team, your current partner and anyone pitching to you. Start with your own team.
Very few delivery tiers pass all six tests. A low score does not mean you need to replace anything. It means you need to choose which gaps to close, and in what order.
In my experience capacity and observability come first, because until you can see the tier you are guessing about everything else. The release path usually pays back the most, because it is what marketing has been waiting on. The SLA and the environment questions tend to get solved together, in a contract or in a funded internal mandate. Drift usually gets fixed last, and it is often the first to cause trouble.
The underlying decision is still the one from August. Either you run the tier yourself, with real headcount, budget and tooling, or you contract it to someone who signs for it. These six apply either way, so you can make that choice on evidence rather than preference.
That standard is what we built Dataweavers to meet. The six still hold if you run the tier yourself, and they are a fair test to put to us alongside anyone else.
Across four pieces the argument is simple. The load on your delivery tier is going up, most of that load is not human, and the tier itself is usually the least governed part of an enterprise digital estate. Nobody neglected it. It was assembled by parties who were each correct about the limits of their own responsibility.
Ownership is what closes that gap, and a standard is what makes ownership mean something. Both are decisions rather than purchases.
Read the series: