Four sellers are building recognisably the same thing. They disagree about whose machines it belongs on and whether any of it is new.

If you sat in several sales meetings this month, you heard the same word each time. You may have assumed, reasonably, that you were hearing about one thing.

In one sense you were. Underneath, the four large sellers using this word are doing something recognisably similar. What they do not agree on is whose machines it should run on, whether it is new, and whether the word names a product at all. Two of them have now argued about the first of those in public, by name. The standard underneath it is finished, and the body that finished it cannot consistently say when it published it.

So this is not a piece explaining what containerisation is, because the word is not yet stable enough to define once and walk away. It is a piece about what is agreed, what is contested, and which of the numbers being quoted at you is not a measurement. If you have been nodding along in those meetings and quietly wondering whether you missed something, you did not. That is the finding.

What is actually happening, before the word gets in the way

Start with the thing itself, because the thing is real and it is not complicated.

When a page loads, an auction runs for the advertising space on it, and it finishes in roughly the time it takes to blink. Historically the software deciding what to bid sat with the buyer, in their buying platform, and it talked across the internet to the exchange, which is the company running the auction on the publisher's behalf. Every one of those conversations costs time, and time is the one thing that auction does not have.

Containerisation, in the sense everybody is reaching for, means moving the deciding software so that it runs inside the exchange's own computers instead of talking to them from outside. A container is the packaging that makes that possible: a sealed bundle holding the code and everything it needs to run, which can be dropped into somebody else's infrastructure without either side having to open it. The idea is borrowed wholesale from software engineering, where it has been ordinary practice since about 2013. The IAB Tech Lab's own explainer teaches it with a shipping container and the old complaint that a thing worked fine on the developer's machine.

So far, so agreed. The disagreement starts the moment you ask where "inside" is.

Two exchanges build the same thing and have argued in public about whose floor it stands on

Here are two companies describing the same product category. Both are writing about their own live products. Both are primary sources, which is to say each is the company's own published account of what it built.

OpenX sells containerisation as a thing that happens on public cloud. Its own comparison table gives "Public Cloud-Native" every benefit on the list and marks "Self-Managed Data Center" as not included on cost of onboarding, launch speed, performance at scale, protected data and innovation. Running your own machines, in this account, is the old way and the slow way.

Index Exchange sells containerisation as a thing that happens on private machines, and says so plainly:

Index Cloud is not built on GCP, AWS, or Azure. We operate our own cloud, purpose-built for programmatic at scale. Running adjacent to the exchange is not the same as running inside it, and the difference shows up in latency, signal quality, and cost.

Read those two positions next to each other. One says the public cloud is the point. The other says the public cloud is the problem, and that what the first company calls "inside" is merely "adjacent".

And this one is not an inference. They have had the argument in public. Index Exchange's chief executive, Andrew Casale, introduced a "cloud tax" argument at the IAB's Annual Leadership Meeting on 12 February 2026. On 2 September 2026, OpenX's chief technology officer, Joel Meyer, published a direct reply. His argument is that privately managed data centres carry the very cost Index attributes to the public cloud. He put numbers next to it: three million queries a second, and container execution in about five milliseconds.

So the disagreement is real, it is named, and both sides have published. What it is not is a disagreement about what the technology does. As one trade outlet covering the exchange put it, the two are converging on the same technical destination and disagreeing about attribution. Both are running partner code inside their own auction. They are arguing about whose floor it should stand on, and about who deserves credit for the idea.

Two things belong with the Index quote. Its page is dated 21 April 2026 and carries a note saying it was last updated on 28 July 2026. And the same page calls Index Cloud "currently in closed beta with select partners" a few lines from saying it "is live today". That is its own small puzzle.

A third company sells it and says the word is doing too much work

Magnite, writing on 6 August 2026, sells containerisation and simultaneously deflates it:

containerization is not the capability itself

It is, in Magnite's account, "one deployment model for running proprietary intelligence within an RTD workflow". The capability is real-time data handling, which the same piece says "has existed for years". Partners can take it as a container or through an ordinary server-to-server connection, and Magnite treats that as a choice about delivery rather than a change in what is on offer.

Be careful not to turn this into scepticism, because it is not. Magnite runs a container product, publishes at length about it, and its chief technology officer told Digiday in June 2026 that the company thinks containers are important and is investing in them. The same executive is the source of the sharpest line about their limits, which is that for a large seller whose machines are already well placed, much of the delay containers remove has already been engineered away. Both things are his position at once, and a piece that quotes only the second one would be misleading you.

So set the three side by side. One says this is a change in how the trade is built, on public cloud. One says the same, on its own machines. One says the capability is old and the container is how you choose to deliver it. Those are not four definitions of a technology. They are one architecture and two live arguments: where it should run, and whether any of it is new. That is a more useful thing to know going into a meeting, and it is what the evidence actually supports.

The number everybody quotes is not a measurement

The figure attached to this work, everywhere, is a reduction of up to 80 per cent in the time a bid request and response takes. Here is exactly how the IAB Tech Lab wrote it on 13 November 2025, with the operative words left in:

The ARTF v1.0 framework is designed to reduce the current time for bid requests and responses up to 80%

Designed to. That is a statement of intent about what the framework is for. It is not a result. There is no published baseline, no method, no test conditions and no measured outcome behind it, and the figure does not appear in the specification's own code repository or in the post announcing the finished version.

It has not stayed a design intent for long. OpenX's product page renders it as 80 per cent, described as a reduction in speed from decision-making to auction, with "Source: IAB" underneath.

A target has become an achievement, with a standards body's name underneath it as the authority. And before anyone reaches for the comfortable conclusion that this is just vendors being vendors: IAB UK does it too. Its article of 10 March 2026, the same sober piece that tells members this is "Time to learn, not yet time to implement widely", also says the framework "Reduces latency by up to 80% by eliminating external network hops". Present tense. A property of the thing.

Meanwhile the individual speed claims in the market are four different quantities wearing the same uniform. The standards body's 80 per cent is the whole round trip, as a design target. Index Exchange's "under five milliseconds" is the container's execution window only. OpenX's "about 5 milliseconds" is the container's response only. PubMatic's "approximately one millisecond" is the model's inference only. None of these has been independently benchmarked, three of them measure a part of the process and one measures a target for the whole of it, and they are routinely compared as though they were rivals.

The most useful comparison published on this is Digiday's summary of Buonasera's point on 22 June 2026: one millisecond of network latency, it writes, covers the distance from New York to Albany. Whether that persuades you depends on whose machines you are buying, and on how far the model sits from the auction today. It is the right question to carry into the meeting, which is more than most of these numbers give you.

What is genuinely agreed, and it is a shorter list than the noise suggests

Strip out the contested parts and a real, checkable core remains.

The standard is finished. The IAB Tech Lab declared the Agentic Real Time Framework final on 12 August 2026. It opened for public comment on 13 November 2025, which is the dateline on the press release itself and the best evidenced of the four dates the body gives for that one event. The other three are below, and the body has not reconciled them. What is not in doubt is the finishing, and that matters commercially for an unglamorous reason: a draft is not something you can hold a supplier to, and a finished specification is.

The final version added something worth knowing. The body describes an orchestration layer that lets one container call others, "potentially from other organizations", and merge their responses "to a single bid request mutation". In plainer terms: the thing deciding inside the auction can now call other companies' code and blend the answers before a bid is submitted. If you were picturing one supplier's model in one box, update the picture.

The deployments are real and they are named. A pilot involving Zillow, Chalice and Index Exchange was reported in August 2025. Index Cloud and the first containerised buying platform, from Bedrock, both launched on 21 April 2026, and both companies announced it themselves. PubMatic launched its layer on 1 June 2026.

The newest one needs describing precisely, because it is the one most likely to be repeated loosely. On 10 September 2026 Index Exchange announced a pilot in which the agency PMG activates buying through Bedrock's containerised platform running inside Index Cloud, with a named curation partner, on streaming television only. PMG is not running its own model in a container. It is buying through somebody else's. No performance figures were published with it. That is still the clearest sign so far that this has reached an agency spending client money, and it is a pilot. Both are true at once.

And a lot of what these containers do, in commercial language, is curation. The standard's reference implementation lists seven actions a container may take, and five are deal and audience operations: switching audience segments on, activating deals, suppressing deals, adjusting a deal's floor price, and adjusting the deal margin. That last one is an interface for setting the curator's cut. IAB UK independently describes the same seven.

Two honest limits on how far to push that. Those seven are the reference implementation's list, not the boundary of the standard, and the IAB Tech Lab says explicitly that the specification is not limited to a fixed set of uses. Its own finalisation post names fraud detection, consent checking and viewability among the intended uses, and leads on a buyer deploying a specialised bidder.

Still, the commercial join is visible from the other end too. OpenX notes that the effect of a container is measured because supply-side decisioning "is typically activated through a dedicated deal ID". The container computes. The deal ID is how it gets bought and billed. So the honest formulation is not that containerisation is curation renamed. It is that curation already moved the choosing to the sell side, and containerisation is what moved the chooser's software there as well.

Bedrock's own company page describes its chief executive, Shane Shevlin, as an early proponent of curation "under its original guise of bid enrichment back in 2015". Bid enrichment, then curation, then containerisation. One job, three names, eleven years. That is not a scandal, and it is the most useful thing to know before you agree that any of this is new.

Three of the four sellers say the same. Magnite says the capability has existed for years. Index Exchange says it has been running containers for custom models for several years. OpenX says running logic in containers is how it has run its own platform for years.

Everyone is confused, and here is the evidence rather than the reassurance

It would be easy to say nobody understands this yet and move on. Better to show you.

The standards body cannot consistently date its own standard. Its press release is dated 13 November 2025. Its containerisation explainer says the project became the framework on 12 November 2025. Its own post announcing the finished version, in August 2026, says the framework "was originally released for public comment in February 2026", which its own press release contradicts. Its project page, modified on the same day the finished version was announced, still says the specification "was in Public Comment until January 15, 2026, and will be finalized soon". That page links to the post saying it is final.

It cannot consistently name it either. The press release headline calls it the Agentic Real Time Framework. The web address for that same release, one repository and most trade coverage call it the Agentic RTB Framework. The page title of the release renders the acronym "ATRF". There are two public code repositories under the two different names.

The reference implementation of the standard that tells exchanges how to host other people's code was written by an exchange. The original implementation in the repository is copyright Index Exchange, which also says publicly that it was one of the companies behind the framework and that its own live deployments informed the design. A second implementation, in a different programming language, arrived with the final version in August 2026.

And the trade press has noticed. AdExchanger's roundup of 20 May 2026 carried the line "AI Is Muddying How Ad Tech Describes Itself" and noted disputes about the role and future of the word itself. Digiday's explainer of 22 June 2026 offers two readings and declines to pick one. The generous reading is that several pressures landed at once and produced a real change. The less generous one is that containers are the latest way for companies to position themselves as indispensable, and that "the marketing has gotten well ahead of the engineering". Digiday's verdict on the pair: "Both things are probably true." That is a fair place for a reader to sit too.

If you have been sitting in meetings feeling underinformed, the more accurate reading is that you were paying attention.

The wrapper question, which is the sharpest thing a sceptic asks

Anybody who has worked in programmatic for a while gets to a reasonable objection quickly. A header bidding wrapper, the piece of software a publisher puts on its page to collect bids from several exchanges at once, is literally a container of other people's code. Prebid is the open-source version and most of the open web runs on it. So is this a new name for a thing we have had since roughly 2017?

No, and the way you can tell is that Prebid does not use the word. The whole Prebid.org blog and news archive, back to 2020, contains not one post using "container" or "containerisation" in any sense. Its own work on software agents runs under an entirely different banner: a sales agent project announced on 29 January 2026, and a webinar on connecting buyer and seller agents in May 2026.

The two worlds have met in one place. On 27 April 2026 somebody opened an issue on the Prebid Server code repository, titled "artf support". The body is one line and a link to the standard, asking for co-located containers to be supported directly from Prebid Server. Checked on 20 September 2026: still open, assigned, marked "Needs Requirements", with no branches and no code attached. Somebody has been asked to submit draft requirements and has not yet. It was last touched on 17 September 2026, so it is alive rather than abandoned. Five months in, it is a live intention without a specification.

There is a detail here worth a raised eyebrow rather than a conclusion. Joel Meyer, the chief technology officer of OpenX, was appointed chairman of Prebid in August 2026. He is among the most quoted voices on containerisation anywhere. Prebid's published output on the subject is, so far, one unresolved suggestion on a code repository. He has held the post about a month, so this is a thing to watch rather than a contradiction to point at. But if the word were going to cross into the wrapper community, that is the person you would expect to carry it.

One more quiet thing worth naming, carefully. The Trade Desk, the largest independent buying platform, has published no blog post or press release of its own about containerisation. It is not absent. It is named as a contributor to the standard, and one of its engineers is quoted in the IAB's press release saying the company built an early version of this with a partner and intends to implement the standard. So its position is a contributor's quote inside somebody else's announcement rather than a statement in its own voice. Given that Digiday names The Trade Desk's own direct-to-publisher product as one of the pressures that produced this moment, that is a thin public footprint for the biggest buyer in the room.

So what do you actually do about it

If you are running a marketing organisation, here is what this changes and what it does not.

What it changes. There is now a documented route by which your own model can decide what to bid. That is worth understanding, because every custom bidding tier a buying platform sells you scores impressions and then lets the platform turn that score into a price. Microsoft stopped supporting media buying through the Xandr demand-side platform on 28 February 2026, and that was the product most often named as an exception to the rule. So the sell side opened a door at roughly the moment the buy side closed one. Note the caveat the PMG pilot makes plain: buying through somebody else's container is not the same as running your own, and most of what is live today is the former.

What it does not change. No seller in this group publishes a price. The speed figures that are published are headline numbers rather than guarantees: none is a ceiling, at a stated percentile, at a stated request volume, and none has been independently benchmarked. Two of the four say their products are built to the standard, and nobody publishes a conformance test, so a container moving unchanged from one seller to another is asserted rather than demonstrated.

That combination has a name and it is not hype and it is not a con. It is a real change in how the plumbing is built, with no demonstrated commercial scale behind it yet. Those are different things and the difference is the whole of your decision.

Five questions, and they are chosen because the answers are informative either way.

1. When you say containerisation, do you mean my model running on your own machines, or in a public cloud, or the decisioning you already sold me with a new name on it? All three answers are being given today, and two of the sellers have argued about the first two in public. Ask before you compare two proposals.
2. What is your latency ceiling, at what percentile, at what request volume, and will you put it in the contract? The 80 per cent figure is a design target. This question asks for a measurement.
3. Do you build to the finished specification, and what happens when you diverge from it? It has been final since 12 August 2026, so this is now a fair question rather than an unfair one.
4. Can your container call another company's container, and if so, whose code has touched my bid? The finished version permits exactly this. Most descriptions of the product do not mention it.
5. Who owns the model, where does it execute, what may you retain, what may you derive from it, and do its decisions inform any shared or blended model of yours? Get the last one in writing. It is the term where the risk is genuinely one-sided, and it is the one least likely to come up unless you raise it.

If a seller answers all five without hesitating, you have learned that they have thought about it. If the answers arrive slowly, you have learned something more useful.

The short version

A real change is happening in where the deciding software runs. The sell side has become somewhere a buyer's model can sit, at roughly the moment the buy side stopped offering that.

Around that change sits a word carrying more than it can hold. The four large sellers broadly agree on the architecture and disagree, publicly and by name, about whose machines it belongs on and whether any of it is new. Three of the four say the capability is years old. The headline number attached to all of it was written as a design target and is now quoted as a result, including by the trade body's own UK arm. The standard's authors cannot agree when they published it. The open-source project running the wrapper it most resembles has one unresolved suggestion and no position.

None of that makes it unreal. Money is moving and an agency is live on it. It means the word is not yet a thing you can buy, and the question that gets you somewhere is not "do you do containerisation" but "what do you mean by it, and on whose machines".

A note on how this was corrected

An earlier draft of this piece described Magnite as a sceptic, presented one of Digiday's two readings as Digiday's verdict, said no seller publishes a conformance claim, and called the Index and OpenX positions a disagreement that could only be inferred. A check against the primary pages found all four to be wrong, and all four are corrected above. The corrections made the piece stronger, which is the usual result and worth recording rather than quietly fixing.