How to Use IAB Tech Lab’s AAMP for Agentic AI Ad Workflows in 2026

The IAB Tech Lab’s Agentic Advertising Management Protocols (AAMP) mark a concrete shift from AI experimentation to standardized, executable ad workflows — and the integration with Kochava’s StationOne platform signals the industry is ready to operationalize. This post walks you through exactly what AAMP and its underlying Agentic Real Time Framework (ARTF) are, why they matter right now, and how to get your programmatic stack ARTF-ready today.

What This Is

AAMP: A Standards Layer for Autonomous Ad Operations

The IAB Tech Lab’s Agentic Advertising Management Protocols (AAMP) is a framework designed to standardize how AI agents interact across the programmatic advertising ecosystem. Per Digiday’s March 24, 2026 coverage, AAMP was built to “support AI-driven workflows on open, trusted standards,” according to IAB Tech Lab CEO Anthony Katsur.

At the technical core of AAMP is the Agentic Real Time Framework (ARTF), which provides the standardized architecture for AI service agents to operate inside host platforms like SSPs and DSPs. Think of ARTF as the plumbing — it defines how agents are packaged, discovered, communicated with, and how they propose changes to the bidstream.

The framework distinguishes two evolutionary stages according to the NotebookLM research report:

• Structural/Systematic Agentic: Where we are now. Service-to-service orchestration where autonomous components operate with explicit mandates. Examples include fraud detection agents or identity resolution agents that run inside DSP infrastructure with domain-specific goals.
• Autonomic Agentic: Where we’re headed. Model-to-service interactions where large language models (LLMs) directly orchestrate ad tech services using protocols like MCP (Model Context Protocol) via JSON-RPC.

The Kochava StationOne Integration

The most significant near-term implementation signal is IAB Tech Lab’s collaboration with Kochava to integrate the AAMP Buyer Agent SDK into Kochava’s StationOne platform. Digiday reports that StationOne is “a fully downloadable app that brings together various different tools with various different skills across various different AI models,” in the words of Kochava CEO Charles Manning. The platform is now exiting beta, making it one of the first commercially available buyer-side ARTF implementations.

StationOne functions as a desktop-based orchestration layer connecting AI models and ad tech tools via API keys and Model Context Protocol (MCP) integrations — bringing the ARTF’s autonomic vision into practical reach for agencies and trading desks today.

The Three Technical Pillars of ARTF

The ARTF rests on three core technical innovations that address the specific demands of real-time bidding environments:

1. OCI-Compliant Containers
Agents must be packaged as OCI-compliant containers (e.g., Docker). This “package once, deploy anywhere” model lets service providers containerize their business logic while host platforms maintain full control over data, SLAs, and operational costs. Agents run as non-root users and must implement Kubernetes-compatible health and readiness probes — the spec is explicit on both requirements.

2. OpenRTB Patch Protocol
Passing full OpenRTB payloads to multiple agents is inefficient and creates privacy risk. The OpenRTB Patch Protocol solves this by allowing agents to return only a “delta” of atomic mutations — add, replace, or remove operations on the bid request document. Each mutation is tied to an Intent — a declarative statement explaining why the change is requested, such as activateSegments or adjustBid. The orchestrating platform evaluates each mutation independently and can accept or reject it based on policy and consent signals.

3. gRPC + MCP Communication
Sub-millisecond performance requirements in auction environments mandate gRPC with Protocol Buffers over traditional JSON/REST — binary encoding is simply faster. The Model Context Protocol (MCP) is layered on top for machine-speed coordination between independent systems, enabling the autonomic agentic future where LLMs orchestrate services directly.

Why It Matters

Fragmentation Is the Enemy

The ad tech industry has been through the fragmentation problem before — multiple competing standards, a fractured ecosystem, and years of interoperability debt that practitioners are still paying down. The research report notes that competing protocols like AdCP (Ad Context Protocol) have already emerged alongside ARTF. IAB Tech Lab CEO Anthony Katsur has been direct about the stakes: “The fastest and smartest way forward is to build on an existing shared foundation, not introduce multiple new standards that create fragmentation.”

AAMP’s strategic differentiator is that it extends rather than replaces: OpenRTB, AdCOM, and VAST remain the foundation. ARTF adds a modern execution layer that existing infrastructure can adopt incrementally without a rip-and-replace migration.

The Performance Problem ARTF Solves

Programmatic advertising operates at millisecond scale. Traditional approaches to AI augmentation — calling external APIs mid-auction, routing full OpenRTB payloads through multiple vendor systems — simply do not meet latency requirements at auction speed. The ARTF’s mutation-based architecture solves this by:

• Eliminating full payload duplication across every agent in the chain
• Reducing data exposure at each hop via the least-data principle
• Using gRPC’s binary Protocol Buffers encoding instead of verbose JSON

Who Benefits and How

According to Funnel’s 2025 Marketing Intelligence Report, 55% of media buyers report having plenty of data but struggle converting it into actionable insights. AAMP is built to close that execution gap — autonomous agents that act on bidstream data in real time, without requiring constant human intervention at each decision point.

The scale of opportunity is already visible: Digiday reports that Butler/Till’s agentic media buying tests cut intermediary fees by over 80%. That figure illustrates what happens when AI executes directly on workflows rather than merely supporting human decision-making. And with 47% of in-house marketers (Funnel, 2025) finding it difficult to stay current with AI developments, the standardization AAMP provides — through boot camps, open-source reference implementations, and a neutral agent registry — directly addresses the organizational readiness gap.

The Data

ARTF vs. Traditional Programmatic vs. Competing Protocols

Sources: Digiday, March 2026, IAB Tech Lab research report

2026 ARTF/AAMP Roadmap Timeline

Sources: IAB Tech Lab research report, Digiday

Step-by-Step Tutorial: Getting Your Stack ARTF-Ready

This walkthrough covers two parallel implementation tracks: SSP/DSP operators building an orchestration layer, and service providers (identity, fraud, and data vendors) containerizing their logic as ARTF-compliant agents. Kochava’s StationOne handles the buyer/agency track as a turnkey solution.

Prerequisites

Before you start, confirm the following are in place:

• Familiarity with Docker and OCI container fundamentals
• A working OpenRTB 2.x implementation (bidder or exchange side)
• Node.js 18+, Python 3.11+, or Go 1.21+ for agent development
• gRPC tooling installed for your language (grpc-tools, grpcio-tools, or the Go gRPC plugin)
• An intent to register with the IAB Tech Lab Agent Registry (details in Phase 5)

Phase 1: Understand the Agent Manifest

Every ARTF agent declares its capabilities through an Agent Manifest — a JSON structure that the orchestrator reads before deploying your container. Per the ARTF specification, the manifest defines the agent’s capabilities, the resources it needs, and critically, its declared intents. Think of it as a contract between your agent and the orchestrating platform.

{
  "agentId": "fraud-detector-v2",
  "version": "2.1.0",
  "vendor": "YourCompany",
  "capabilities": ["fraud_detection", "invalid_traffic_filtering"],
  "intents": [
    {
      "id": "flagInvalidTraffic",
      "description": "Marks bid requests from detected IVT sources by raising the bid floor",
      "mutations": ["replace:/imp/0/bidfloor", "add:/ext/fraud_signal"]
    }
  ],
  "resources": {
    "maxMemoryMB": 256,
    "maxCPUMillicores": 500,
    "networkAccess": false
  },
  "privacy": {
    "gppCompliant": true,
    "tcfCompliant": true,
    "dataRetentionDays": 0
  }
}

Key design decisions to note here:

• intents define the why behind each mutation with declarative IDs. The orchestrator uses these to evaluate whether to permit the mutation based on platform policy and consent signals.
• networkAccess: false implements the least-privilege principle required by ARTF. Agents should not need external network calls — the host platform provides the data context the agent declared needing.
• dataRetentionDays: 0 is best practice for bid-level agents to maintain privacy compliance under GPP and TCF.

Phase 2: Containerize Your Agent

Per the ARTF technical requirements, agents must run as OCI-compliant containers. Here’s a minimal Dockerfile for a Python-based fraud detection agent:

FROM python:3.11-slim

# Run as non-root user (ARTF requirement)
RUN useradd -m -u 1000 agentuser
USER agentuser

WORKDIR /app
COPY --chown=agentuser:agentuser requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY --chown=agentuser:agentuser . .

# Health probe endpoint (Kubernetes-compatible)
EXPOSE 8080

# gRPC server port
EXPOSE 50051

CMD ["python", "agent_server.py"]

Two requirements that are non-negotiable per the spec:

1. Non-root execution — the USER agentuser directive is required. Agents running as root are a security liability the orchestrator cannot accept.
2. Health/readiness probes on port 8080 — Kubernetes orchestrators need these to validate agent availability before routing bid requests. If you skip this, the orchestrator will not route traffic to your container.

For production deployments, add a /health endpoint that returns 200 only when your model is loaded, warmed, and receiving fresh signal data — not just when the process is running.

Phase 3: Implement the gRPC Service Interface

Your agent communicates via gRPC with Protocol Buffers. Define your service in a .proto file that the orchestrator’s generated stubs will call:

syntax = "proto3";
package artf.v1;

service BidstreamAgent {
  rpc ProcessBidRequest (BidRequestContext) returns (PatchResponse);
}

message BidRequestContext {
  string request_id = 1;
  bytes openrtb_payload = 2;  // Only the fields declared in your manifest
  string intent_id = 3;
}

message PatchResponse {
  repeated Mutation mutations = 1;
  string agent_id = 2;
  int64 processing_ns = 3;  // Nanoseconds — orchestrator tracks your latency
}

message Mutation {
  string op = 1;        // "add", "replace", or "remove"
  string path = 2;      // JSON Pointer path into the bid request
  bytes value = 3;      // New value (required for add/replace)
  string intent_id = 4; // Must match a declared intent in your manifest
}

The orchestrator sends only the fields your manifest declared needing — this is the least-data principle enforced at the protocol level. Your agent returns an array of Mutation objects. The orchestrator processes each one independently, logging accepted and rejected changes for compliance audit purposes.

Phase 4: Implement the Mutation Logic

Here is a Python implementation that shows the complete server-side pattern:

import grpc
from concurrent import futures
import artf_pb2
import artf_pb2_grpc
import json

class FraudDetectionAgent(artf_pb2_grpc.BidstreamAgentServicer):

    def ProcessBidRequest(self, request, context):
        # Deserialize only the fields we declared needing in the manifest
        bid_data = json.loads(request.openrtb_payload)
        mutations = []

        # Example: flag suspicious IP ranges
        ip = bid_data.get("device", {}).get("ip", "")
        if self._is_suspicious_ip(ip):
            # Return mutations, not a modified copy of the full payload
            mutations.append(artf_pb2.Mutation(
                op="replace",
                path="/imp/0/bidfloor",
                value=json.dumps(999.99).encode(),  # Effectively blocks the bid
                intent_id="flagInvalidTraffic"
            ))
            mutations.append(artf_pb2.Mutation(
                op="add",
                path="/ext/fraud_signal",
                value=json.dumps({"score": 0.97, "reason": "ip_blocklist"}).encode(),
                intent_id="flagInvalidTraffic"
            ))

        return artf_pb2.PatchResponse(
            mutations=mutations,
            agent_id="fraud-detector-v2",
            processing_ns=self._get_elapsed_ns()
        )

    def _is_suspicious_ip(self, ip: str) -> bool:
        # Replace with your actual detection model
        return ip.startswith("185.220.")

    def _get_elapsed_ns(self):
        import time
        return time.perf_counter_ns()


def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    artf_pb2_grpc.add_BidstreamAgentServicer_to_server(
        FraudDetectionAgent(), server
    )
    server.add_insecure_port('[::]:50051')
    server.start()
    server.wait_for_termination()

if __name__ == '__main__':
    serve()

The core discipline here is that your agent never sees or modifies the full bid request document. It receives the minimum declared fields, proposes targeted mutations back via the Patch Protocol, and the orchestrator decides what to apply based on your declared intents and the platform’s consent/policy rules.

This is where the OpenRTB Patch Protocol fundamentally differs from legacy API integrations: instead of a synchronous full-payload round-trip to your API, the orchestrator calls your containerized agent locally, keeps the data within its trust boundary, and applies only the mutations you declared in advance.

Phase 5: Register Your Agent in the IAB Agent Registry

The IAB Tech Lab Agent Registry launched in early 2026 as a neutral directory for agent discovery and trust verification. As of March 11, 2026, it carries 10 active entries including Amazon Ads, PubMatic, and Equativ — an early signal of the major players committing to the standard.

Registration requires five components:

1. Legal entity verification — the registry validates company identity to establish a trust anchor for orchestrators
2. Privacy compliance IDs — your GPP Consent String Specification ID and/or TCF vendor ID must be on file
3. Deployment classification — declare your deployment tier per the three-tier taxonomy from the research report:
4. Remote: Cloud-hosted API services (example: Amazon Ads MCP)
5. Local: Downloadable software or CLI tools
6. Private: Enterprise on-premise or VPC installations (example: Optable Audience Agent)
7. Agent Manifest URL — a publicly accessible JSON endpoint serving your manifest
8. Container image reference — the OCI registry location of your published container image

Registration is the trust anchor for the ecosystem. As George Panagopoulos, CTO of Experian Marketing Services, stated: “Scale only works when interoperability is real.” Without registry verification, orchestrators building trust-based deployment policies have no reliable mechanism to validate that a third-party agent actually does what its manifest claims.

Even for internal agents, registration is worth doing early — it creates the governance paper trail that GPP and TCF compliance audits will eventually require.

Phase 6: For Buyers — Get Started with Kochava StationOne

If you are on the buy side — agency, brand, or trading desk — the most immediately accessible entry point to AAMP is Kochava’s StationOne, now out of beta with the AAMP Buyer Agent SDK integrated.

Step-by-step setup:

1. Download StationOne from Kochava’s site — it is a desktop application, not a SaaS subscription
2. Connect your DSP, measurement, and data tool API keys in the integrations panel. Each connected tool becomes an accessible capability for your AI models
3. Add MCP server connections for the ad tech tools that support Model Context Protocol — these appear as callable services the agent can interact with at machine speed
4. Define a bounded workflow — specify the campaign goal, KPIs, and the explicit decision authority the agent is permitted to exercise (e.g., bid adjustments within ±20%, or full campaign pacing reallocation)
5. Monitor mutation and action logs — StationOne surfaces every agent action with its intent declaration, creating the auditable record that justifies the AI’s decisions to clients and finance teams

One important framing note: StationOne is not a “set it and forget it” autonomous media buyer. You are configuring bounded agents that operate within parameters you define — closer to automated rules with AI-driven triggers than to a fully autonomous system. That is consistent with the ARTF’s current structural/systematic stage.

Expected Outcomes After Implementation

After completing the ARTF integration:

• Your service agent runs inside the orchestrator’s infrastructure with no full-payload exposure to third-party systems
• Every intervention is logged with its intent declaration, creating a compliance-ready audit trail
• Latency overhead per agent call is measured in microseconds — gRPC + Protobuf vs. the hundreds of milliseconds that REST API round-trips add at auction speed
• Your agent is discoverable by any ARTF-compliant orchestrator that checks the registry, opening access to new platform partners without custom integrations

Real-World Use Cases

1. SSP-Side IVT Filtering at Auction Speed

Scenario: A supply-side platform processes 500,000 bid requests per second and wants to integrate a third-party invalid traffic detection vendor without sharing full bid payloads externally.

Implementation: The IVT vendor packages their detection model as an ARTF-compliant container. The SSP deploys it inside their Kubernetes cluster. For each bid request, the container receives only device.ip, site.domain, and user.id per its declared manifest needs. It returns a mutation raising the bid floor for flagged inventory with a flagInvalidTraffic intent declaration.

Expected Outcome: Sub-millisecond fraud filtering with zero full-payload exposure to the third-party vendor. The orchestrator logs each accepted and rejected mutation, providing auditable compliance evidence. Bid quality improves without adding meaningful latency — and the IVT vendor cannot use the data for any purpose beyond the declared intent.

2. Agency Workflow Automation via StationOne

Scenario: A mid-size media agency manages 15 brand clients across three DSPs. Campaign optimization requires manual analysis of pacing reports followed by manual bid adjustments — a process consuming 2-3 hours per account manager daily.

Implementation: Using Kochava’s StationOne with the AAMP Buyer Agent SDK, the agency connects each DSP’s API and configures pacing optimization agents for each client. Agents monitor delivery velocity and propose bid adjustments with adjustBid intents, surfacing recommended changes for account manager review.

Expected Outcome: The 2-3 hour daily optimization window compresses to a 20-minute review session. Agents handle the routine data-to-action conversion; humans handle strategic exceptions. This directly addresses the Funnel finding that 55% of media buyers have data they cannot convert to action fast enough.

3. Privacy-Preserving Identity Resolution

Scenario: A DSP wants to integrate multiple identity graph providers (e.g., Unified ID 2.0, RampID) simultaneously while ensuring each provider sees only the minimum data required under GDPR and CCPA.

Implementation: Each identity provider packages an ARTF agent. The DSP orchestrator sends each agent only the declared field set — for example, a hashed email or a first-party cookie. The agent returns a mutation adding the resolved identity segment to the user.ext field with an activateSegments intent. The orchestrator validates that each activateSegments mutation is within the user’s consented purposes per their GPP/TCF signal before applying it.

Expected Outcome: Multi-provider identity resolution running at auction speed with explicit, auditable consent enforcement at the mutation level. Each provider cannot correlate data across bid requests because the agent receives only the declared minimum per call.

4. Publisher-Side Deal Activation

Scenario: A publisher wants to automatically activate programmatic guaranteed deals when real-time inventory quality thresholds are met, replacing a manual configuration-and-wait workflow that often means deals activate too late.

Implementation: A deal management agent monitors contextual quality signals and inventory characteristics in real time. When defined quality thresholds are met for a specific placement, it returns mutations with activateDeals and expireDeals intents to the SSP orchestrator, dynamically reprioritizing specific deal IDs based on current inventory conditions.

Expected Outcome: Deal fill rates improve because activation and deactivation happens at auction time rather than through manual configuration cycles. The intent-based system creates a clear audit log for publisher-advertiser deal compliance reporting, enabling post-campaign analysis of exactly when and why each deal was activated.

5. Multi-Agent Campaign Management at Butler/Till Scale

Scenario: Following Butler/Till’s reported results of cutting intermediary fees by over 80% through agentic media buying tests, a holding company wants to replicate this model across their entire client base at scale.

Implementation: Chain multiple ARTF agents in sequence within the DSP’s orchestration layer: audience qualification, fraud filtering, brand safety scoring, and bid optimization each run as separate containers. The orchestrator defines explicit handoff sequences, with each agent’s accepted mutations feeding forward to the next stage. Human review handles exception cases flagged by agents as outside defined confidence thresholds.

Expected Outcome: End-to-end campaign execution that requires minimal human touchpoints for standard media buys. The fee reduction Butler/Till documented comes from replacing manual DSP UI work — the work that currently lives between “data available” and “decision made” — with automated AAMP agent chains that execute in microseconds.

Common Pitfalls

1. Over-Declaring Required Fields in Your Manifest

The orchestrator enforces least-data delivery based on your manifest declarations. Some teams request broad field sets “just in case” — user.*, device.* — rather than the specific paths they actually need. This creates unnecessary privacy risk and may trigger consent evaluation failures. Define the exact JSON pointer paths your detection model uses and request nothing more. A well-scoped manifest also signals professionalism to orchestrators evaluating your registry entry.

2. Writing Intents That Are Too Generic

An intent called modifyBid that covers everything from fraud blocking to audience-based adjustments gives orchestrators no meaningful basis for evaluating the mutation. Per the ARTF specification, intents are declarative statements — they must precisely explain why the change is requested. Use specific intent IDs like flagInvalidTraffic, activateSegments, or adjustBidForViewability to make your agent’s behavior auditable and trustworthy.

3. Skipping Registry Registration for Internal Agents

Some operators assume the Agent Registry is only for third-party vendors. But without registry verification, there is no trust anchor for compliance auditors and no standardized governance trail. Even internal agents benefit from registration — and as GPP/TCF alignment matures through 2026, expect registry participation to become effectively mandatory for any agent handling user-level data.

4. Prototyping in REST and Planning to “Optimize Later”

Teams often build fraud or identity agents using REST APIs during prototyping and plan to migrate to gRPC before production. This migration is almost always more painful than anticipated, because the data schemas, error handling, and latency expectations all change. The ARTF’s sub-millisecond requirements are not aspirational — they are a hard ceiling in auction environments. Build with gRPC from the first sprint.

5. Building for Full Autonomic Agentic Before the Infrastructure Is Ready

The framework’s two-stage model is a practical roadmap, not a marketing aspiration. Per the research report, full LLM-to-service orchestration (autonomic agentic) is the roadmap destination for 2026 and beyond. Building production systems that depend on it today means building on immature and still-forming infrastructure. Focus current implementations on the structural/systematic stage — defined intents, bounded agents, explicit orchestration logic — and architect for extensibility to MCP-driven autonomic patterns in the future.

Expert Tips

1. Gate Your Health Probes on Model Readiness, Not Just Process Health
Don’t implement the Kubernetes health probe as a simple “is the process running?” check. Your fraud model warming up with stale signal data is technically running but functionally broken. Gate the readiness probe on model version verification and recency of your blocklist/segment data. An agent that reports healthy but is operating on day-old fraud signals will silently degrade campaign quality without surfacing any errors.

2. Version Your Intents Alongside Your Container Tags
When you update detection logic, the mutations you produce change in scope and semantics. Orchestrators that cached your manifest may be evaluating your new mutations against outdated intent descriptions. Use semantic versioning in both your container image tag and your manifest’s intents array, and register each version as a distinct entry. This also creates a clean rollback path if a new version produces unexpected mutation patterns.

3. Build a Rejected Mutations Analytics Pipeline
The orchestrator logs which of your mutations it accepts and rejects. This rejection feed is the most valuable debugging and optimization signal you have. Systematic rejections of a specific intent type usually signal one of three things: a manifest misconfiguration, a mismatch with the orchestrator’s consent policy, or a schema error in your mutation’s JSON path. None of these problems are visible without instrumenting the rejection stream.

4. Register Early — The Registry Is Still Forming Norms
The IAB Tech Lab Agent Registry had only 10 entries as of March 11, 2026. Early registrants have disproportionate visibility with orchestrators actively building ARTF integrations, and they influence how the registry’s categorization and verification norms develop. Register your agent in sandbox/staging mode before production — this also surfaces legal entity verification issues before they block a launch.

5. Participate in the Monthly Boot Camps While the Spec Is Forming
The IAB Tech Lab’s monthly Agentic AI Boot Camps, which launched February 12, 2026 at the IAB Ad Lab, are not marketing events. They are specification-shaping sessions where practitioners directly influence what the Q2 2026 open-source reference implementations will look like. If your organization has strong opinions about how buyer or seller agents should interoperate, this is the venue that matters.

FAQ

Q: What is the difference between AAMP and ARTF?
AAMP (Agentic Advertising Management Protocols) is the overarching IAB Tech Lab initiative covering the full scope of AI-driven ad workflows — including governance, standards development, industry education, and the Kochava StationOne partnership. ARTF (Agentic Real Time Framework) is the technical specification within AAMP that defines how agents are containerized, communicate via gRPC and MCP, and interact with the bidstream through the OpenRTB Patch Protocol. AAMP is the program; ARTF is the spec. Per Digiday’s coverage, AAMP is “built to support AI-driven workflows on open, trusted standards.”

Q: Does ARTF require a full rebuild of our OpenRTB bidder?
No. Per the research report, ARTF builds on OpenRTB, AdCOM, and VAST rather than replacing them. Your existing OpenRTB implementation continues to handle core bid request/response flow. ARTF adds an orchestration layer that applies agent-proposed mutations before your bid response is finalized. The adoption path is additive — you are adding a container orchestration and mutation evaluation layer, not rebuilding your bidder from scratch.

Q: Is the Agent Registry mandatory for production deployments?
Not technically mandatory in the current spec. But practically, orchestrators building trust-based deployment policies — especially those enforcing GPP and TCF consent signals — will require registry verification to validate legal identity and privacy compliance. As noted in the research report, Google Panagopoulos emphasized that “scale only works when interoperability is real” — and the registry is the mechanism that makes interoperability verifiable. Expect de facto mandatory status by the time Q2 2026 reference implementations ship.

Q: How does ARTF handle GDPR and CCPA consent enforcement?
The ARTF privacy architecture uses three enforcement layers: the least-data principle (agents receive only declared-necessary fields per the manifest), mandatory GPP/TCF compliance IDs in the registry, and intent-based mutation evaluation (orchestrators evaluate each mutation’s intent against the user’s consent signal before applying it). The ongoing 2026 roadmap includes developing formal trust, provenance, and transaction-integrity signals that will deepen this consent enforcement architecture.

Q: How do we handle the AdCP competition — should we implement both standards?
The research report and Digiday coverage both note AdCP as the primary competing standard. IAB Tech Lab CEO Anthony Katsur’s explicit position is that building on OpenRTB/AdCOM/VAST is the faster, safer path than adopting a new framework. For most ad tech operators, the practical recommendation is to follow the IAB Tech Lab roadmap as primary — the registry, the boot camps, the Q2 reference implementations — while monitoring AdCP adoption among specific walled garden partners that may prefer alternative standards. Do not invest in full parallel implementations until the landscape clarifies.

Bottom Line

The IAB Tech Lab’s AAMP and the Agentic Real Time Framework represent the most concrete, technically coherent step the programmatic advertising industry has taken toward standardized agentic AI execution. The combination of OCI containers, gRPC communication, the OpenRTB Patch Protocol, and a neutral Agent Registry creates an architecture that simultaneously solves latency, privacy, fragmentation, and trust — the four blockers that have kept AI agents at the experimentation stage. The Kochava StationOne integration confirms that working buy-side tooling is available today, not as a roadmap promise.

Anthony Katsur’s caution that practical application “will require years of market experimentation, standardization and alignment” is accurate and worth holding onto. But the infrastructure is being built now, Q2 2026 open-source reference implementations will dramatically lower the entry barrier, and the teams that understand containers, mutations, intents, and the registry today are the ones positioned to deploy confidently when the standard matures. Start with the Agent Registry, containerize your first agent, and attend a boot camp. The execution layer for the agentic era is being decided right now.