ARTF explained: agent containers inside the auction

The Agentic Real Time Framework (ARTF) is IAB Tech Lab’s standard for running partner code inside the platform that runs the auction. A partner packages its service as a container, the host (typically an SSP or exchange) runs it on its own infrastructure, calls it during the auction, and gets back proposed changes to the bid request or response that it can accept or reject. Version 1.0 is final. For publishers, it means decisions about your deals, floors and audience segments can be made by partners’ code inside your SSP, so you need to know which code and what it changes.

What is ARTF?

ARTF is a specification for “agent services which operate within a host platform and that the orchestrating platform can call directly”, in the words of the v1.0 spec. It was first published as the Agentic RTB Framework, a name that survives in the spec’s licence line and in the original repository name. IAB Tech Lab now calls it the Agentic Real Time Framework.

A few facts to place it:

Who wrote it. The IAB Tech Lab Container Project Task Force, a subgroup of the Programmatic Supply Chain Working Group. Named contributors come from Index Exchange, Chalice, The Trade Desk and OpenX.
Where it sits. ARTF is in the Agentic Foundations pillar of AAMP, IAB Tech Lab’s umbrella for agentic work. IAB Tech Lab COO Shailley Singh has written that treating ARTF “as the agentic standard, rather than just one real-time component of AAMP” is a common mistake. We cover the rest of AAMP in AAMP and AdCP compared.
What “agentic” means here. The spec says its “primary focus” is service-to-service integration, with model-driven agents “envisioned” as the technology matures. Most ARTF agents today are fast, deterministic services, not language models in the bid path.

How do agent services run inside a host platform?

The spec has three parts: a container contract, a manifest, and an API for proposing changes.

The container contract. Each agent is a standard OCI container image (Docker, Kubernetes). The rules are strict:

It runs as a non-root user and needs no privileged access.
It has no external network access. All ingress and egress is prohibited except with the host, though the two parties can negotiate specific network rules.
It exposes HTTP health and readiness probes and supports OpenTelemetry.
Images must be signed and built by an auditable CI/CD pipeline.
It follows “least privilege and least data”: the host strips private and competitive signals before the agent sees anything.

The manifest. A JSON manifest stored as an image label (com.iabtechlab.artf.descriptor, Base64) declares the agent’s name, vendor, intents, CPU and memory needs, and the services it depends on. If a host cannot meet those needs, it should not start the container.

The API. The host calls one gRPC method, RTBExtensionPoint.GetMutations. The request carries:

the lifecycle point;
the OpenRTB 2.6 bid request, and the bid response where relevant;
a tmax in milliseconds;
who originated the payload (publisher, SSP, exchange or DSP);
the intents the agent is allowed to return.

The lifecycle points in the v1 proto are the publisher bid request and the DSP bid response, with a comment that more will be added.

gRPC is mandatory. MCP “may be used”, and the spec says it “will likely be required in the future”, naming MCP version 2025-06-18 as the first fast and secure enough for real traffic. The v1.0 repository ships Go and Rust reference implementations; the Go one serves gRPC on port 50051 and MCP alongside it.

The agent replies with mutations. Each one has an intent, an operation (add, remove or replace), a semantic path and a payload. This example is from the spec:

[
  {
    "intent": "expireDeals",
    "op": "remove",
    "path": "/imp/1",
    "value": { "IDsPayload": ["deal100", "deal200"] }
  },
  {
    "intent": "adjustDeals",
    "op": "replace",
    "path": "/imp/1/deals/500",
    "value": { "AdjustDealPayload": { "bidfloor": 8.00 } }
  }
]

The v1 proto defines eight intents: ACTIVATE_SEGMENTS, ACTIVATE_DEALS, SUPPRESS_DEALS, ADJUST_DEAL_FLOOR, ADJUST_DEAL_MARGIN, BID_SHADE, ADD_METRICS and ADD_CIDS.

What does ARTF change in the auction?

Three things.

It moves partner calls inside the host. Today an SSP that wants a fraud, identity or curation partner involved in each auction makes a network call to them. ARTF puts that partner in the same data centre, server or virtual machine. IAB Tech Lab’s November 2025 announcement said this is “designed to reduce the current time for bid requests and responses up to 80%.” That is IAB Tech Lab’s claim; neither the spec nor the repository publishes a benchmark.

The host decides, one mutation at a time. A container never edits the bid request. Each mutation is atomic and the host accepts or rejects it whole. There are no transactions or ordering guarantees across mutations. Michael Richardson of Index Exchange put it as “You propose, the host decides” in his February 2026 getting-started guide. The finalised v1.0 also adds an orchestration layer, so one ARTF node can call others, possibly from other companies, and merge their answers into a single mutation.

More parties can act on each impression. The intents are not neutral. Activating or suppressing deals, adjusting a deal’s floor or margin, and shading bids all change what clears and at what price. IAB Tech Lab’s v1.0 announcement gives the example of “a buyer may deploy their own specialized bidder to an SSP as a container.” The spec does ask hosts to log requested and applied patches and says they “should provide standard reports and metrics” on acceptance and rejection rates, but whether and how any of that reaches the publisher is left to the parties.

What does ARTF mean for publishers?

In most setups you are not the host. Richardson’s guide says ARTF containers run inside “a host platform, typically an SSP or an exchange”, and the spec’s definition of an orchestrator also includes DSPs. So your exposure runs through your SSP contracts.

That fits the argument in Agents aren’t coming for the auction: the agents that negotiate and book are working on the IO side. ARTF is the exception that does sit in the auction, but as host-controlled services, not negotiators.

Prebid has not shipped ARTF support. Prebid Server issue #4754, opened on 27 April 2026, proposes supporting co-located ARTF containers directly from Prebid Server. It is still open, and a comment from a Prebid Server maintainer on 17 September said draft requirements were expected. If that lands, a publisher running its own Prebid Server could become a host. ARTF is server side, so nothing changes in Prebid.js.

Questions to put to each SSP and exchange you work with:

Do you run ARTF containers on our traffic, and whose are they?
Which intents do you accept from each? Ask specifically about ADJUST_DEAL_FLOOR, ADJUST_DEAL_MARGIN, SUPPRESS_DEALS and BID_SHADE.
Which fields from our bid requests does each container receive?
Can we see the log of applied mutations and the acceptance rates for our inventory?
Can we opt our inventory, or specific deals, out?

What version is ARTF on?

ARTF v1.0 is final:

13 November 2025. IAB Tech Lab released v1.0 for public comment, open until 15 January 2026.
July 2026. The final spec was added to the GitHub repository, which tagged v1.0 on 20 July.
12 August 2026. IAB Tech Lab announced the finalised v1.0 as “the first stable version of the protocol”, which it says “is now being used in production by various companies, including several of the organizations that helped design it.” It names none of them.

The standards page links the “Finalized ARTF Specification v1” but still carries an older line saying it “will be finalized soon.” The tagged release and the August announcement are the better guide.

Version 2.0 is in progress. The standards page says “Work on Version 2.0 is already underway”, and the Agentic Task Force is asking for proposals. In the repository, a bid-valuation branch proposes a v2 proto package with a new ADJUST_BID_VALUATION intent. It is not merged, so treat it as a sign of direction, not a spec.

One licensing note: the spec is CC BY 3.0, but the reference code is AGPL-3.0. Check that with your legal team before you build on the sample code.

BidCliq builds header bidding and agentic tools for publishers, and our sales agent is verified by AgenticAdvertising.org against AdCP 3.1.

What to do next

Send the five questions above to your SSPs and exchanges, and add ARTF to your next supply-path review.
Have an engineer read the v1.0 spec and the proto. It is short.
If you run your own Prebid Server, follow issue #4754.
Watch the repository for v2.0 drafts, especially new intents that touch pricing.

Frequently asked questions

What does ARTF stand for?

ARTF is the Agentic Real Time Framework, an IAB Tech Lab specification. It was first published as the Agentic RTB Framework, a name that still appears in the spec's licence line and the original GitHub repository name.

Where do ARTF containers run?

Inside a host platform's own infrastructure, typically an SSP or an exchange, though the spec's definition of an orchestrator also includes DSPs. Containers have no external network access by default and talk only to the host.

Is ARTF final?

Yes. IAB Tech Lab announced the finalised v1.0 on 12 August 2026, and the GitHub repository tagged v1.0 on 20 July 2026. IAB Tech Lab says work on version 2.0 is already underway.

Does Prebid support ARTF?

Not yet. An open Prebid Server issue from April 2026 proposes supporting co-located ARTF containers directly from Prebid Server, but no code has been merged. ARTF is server side, so it does not apply to Prebid.js.

Is ARTF the same thing as AAMP?

No. ARTF is one component of AAMP's Agentic Foundations pillar. AAMP also includes the buyer and seller agent SDKs, OpenProposal and the Agent Registry.

About the author

Sharad Yadav

Founder, BidCliq

Sharad Yadav is the founder of BidCliq, a publisher-first ad monetization platform that helps publishers and ad ops teams run header bidding, Prebid and programmatic across display, video, app and CTV. Before BidCliq, he led AdTech and product at GeeksforGeeks, where he built an in-house ads product that doubled programmatic revenue within nine months and an anti-adblock solution that lifted ad yield by 10%. He is a founding member of AdCP.