ARTF — the Agentic Real-Time Framework — is a new IAB Tech Lab standard that lets you run your logic inside the auction, in containers, right where the bidstream lives. This means less latency, fewer hops, and better data protection.
If you’re an ad tech company (or planning to become one), here’s how to get started.
Step 1: Have a reason to exist in the auction
Before you touch a spec, answer one question: what would you do with access to every auction on the open internet, in real time, with single-digit-millisecond overhead?
Good answers tend to involve things that have always been too slow or too expensive to do during an auction. Examples include fraud detection without adding 200ms of latency, identity resolution without extra round trips, and contextual enrichment that finishes before the auction closes. And finally, outcome-based optimization at scale across the entire internet.
If you’re a startup, this is an exciting opportunity! You can build natively for this model instead of retrofitting decades of server-to-server architecture. You can focus on use cases that were previously impossible, or impossibly slow. You don’t need to limit yourself to incremental improvements. Ambition is appropriate here.
Step 2: Understand OpenRTB and how you can add value to the bidstream
ARTF rides on top of OpenRTB. Your container will receive bid request data and propose changes, called mutations, to that data. You should be clear on what you’re mutating, where in the bid request/response cycle you’re doing it, and why.
Are you activating or suppressing deals? Resolving identity? Enriching bid requests with additional signals? Adjusting floors? Scoring for fraud? Attaching measurement signals?
Each mutation in ARTF is tagged with an intent — a declaration of what the change is for.
The host platform uses that intent to decide whether to trust and apply your change. The spec defines common intents (ACTIVATE_DEALS, BID_SHADE, ADD_METRICS, ADJUST_DEAL_FLOOR, and more) but the important thing is that you can describe what you do in one sentence and map to a mutation on an OpenRTB object.
If you can’t describe your value as a change to a bid request, ARTF may not be your entry point.
Step 3: Build your decisioning logic
Your container needs to do one thing well, and it needs to be done in milliseconds. Whatever you’re running — rules engine, ML model, lookup table, scoring algorithm — it must fit within the latency budget for a real-time auction.
Your container runs inside the host’s infrastructure, sandboxed, with access to what the host explicitly provides. So, you’ll want to design for local execution: preload your models, cache your data, and minimize external dependencies.
If your current product makes three API calls and a database lookup before returning a result, that workflow needs rethinking for a containerized environment. But the encouraging news is you don’t have to figure this out alone.
Host platforms are motivated to help you succeed — they want high‑value containers running in their auctions. Expect tooling and support for capabilities such as self-service model updates, testing against live bidstream samples, and iterating on performance without a full redeployment cycle. The architecture is different from traditional partner workflows, but hosts are active collaborators in solving these challenges.
Step 4: Package it as an ARTF container and speak the spec
Your logic goes into a standardized container that communicates via gRPC or MCP. The host calls your container, passes in the relevant bid request data, and your container returns an OpenRTB Patch response — a set of proposed mutations, each tagged with an intent.
A few things to keep in mind:
- You propose, the host decides. Your mutations are suggestions. The host platform decides which ones to apply based on policy and order of operations. Design accordingly — your container should be useful even when some mutations get rejected.
- The host controls your inputs. You may not see the full bid request unless the host deems it necessary. Expect to receive only the fields relevant to your declared purpose. This is a feature, not a limitation — it means you don’t have to worry about data outside your scope.
- Certification plays a key role. Container images are cryptographically verified. Plan for a signing and review process.
The spec is open and on GitHub. The gRPC service definitions and mutation schemas are your API contract.
Step 5: Find your partners, deploy, and go
ARTF containers run inside a host platform, typically an SSP or an exchange. Your go-to-market approach is a partnership play: you need a host that wants your container in their auction. Start with the platforms already engaged with ARTF. Begin with a focused use case and demonstrate the impact; then expand.
The most productive early conversations will be with partners who already have containerized infrastructure running or are actively building toward it. At Index Exchange, we’ve had extensive experience engaging these discussions with partners, and we’re eager to continue those conversations as ARTF opens new paths to build and experiment together.
So what?
ARTF makes the programmatic auction faster and more extensible by moving computation to where the data already lives. If you have logic worth running at auction time — and the engineering chops to make it fast and self-contained — the spec is open, the community is active, and several major platforms are ready to work with you.
Go read the spec. Build something interesting.
ARTF v1.0 specification: artf.ai | IAB Tech Lab | GitHub
Michael Richardson
VP of Product
Index Exchange