Agentic eXecution Engine (AXE)

Agentic eXecution Engine (AXE) — AdCP’s real-time execution layer for brand suitability enforcement, frequency capping, and dynamic audience targeting at impression time.

AXE is deprecated. The Trusted Match Protocol (TMP) replaces AXE with structural privacy separation, multi-surface support (web, mobile, CTV, AI assistants, retail media), and a standardized offer model. New integrations should use TMP. Existing AXE integrations will continue to work — the axei/axex/axem segment model maps to TMP’s offers and signals.

The Agentic eXecution Engine (AXE) is AdCP’s original real-time execution layer that enables dynamic audience targeting, brand suitability enforcement, and frequency management at impression time.

AXE is how AdCP reaches impression-time execution. It enables cross-publisher frequency capping the same way OpenRTB enables programmatic decisioning: by giving the buyer or orchestrator a real-time look at each impression before the ad server decides whether to serve.

Two-Phase Workflow

AXE operates in two distinct phases: offline campaign setup and real-time ad serving.

Phase 1: Offline Setup

Before ads serve, campaigns are configured and segment data is synchronized:

What happens:

1. Buyer Agent creates campaigns with targeting and budgets via AdCP
2. Signal Agents attach contextual data (audiences, brand suitability rules, weather triggers)
3. Orchestrator maps campaigns to AXE segments and syncs data to the real-time module
4. Sales Agent creates ad server line items targeting AXE segment key-values

Phase 2: Real-Time Serving

When an ad request arrives, AXE evaluates it in real-time and returns segment decisions:

What happens:

1. User visits page, triggering ad request
2. Ad server initiates request to Prebid (or similar)
3. Prebid sends OpenRTB bid request to AXE
4. AXE evaluates user/context and returns segment values
5. Ad server matches segments to line items and serves appropriate ad

AXE Segment Types

AXE returns three types of segment values to the ad server:

Segment	Key	Purpose	Example
Include	axei	Audience targeting - user belongs to this segment	"seg_auto_intenders"
Exclude	axex	Brand suitability/suppression - block this impression	"unsafe_content"
Macro	axem	Creative personalization data	"eyJjb250ZXh0IjoiLi4uIn0="

How Segments Flow to Creatives

{
  "packages": [{
    "product_id": "premium_video",
    "targeting_overlay": {
      "axe_include_segment": "seg_auto_intenders_q1",
      "axe_exclude_segment": "seg_existing_customers"
    }
  }]
}

At impression time:

• axei is checked against axe_include_segment → must match to serve
• axex is checked against axe_exclude_segment → must NOT match to serve
• axem is passed to creative via the {AXEM} macro

Data Flow Example

Here’s a concrete example of AXE in action for a customer acquisition campaign:

Setup (Offline)

1. Buyer uploads suppression list:

Advertiser CRM
  → Hash emails (SHA256)
  → Upload to orchestrator
  → Receive segment ID: "seg_existing_customers_acme"

2. Create media buy with AXE targeting:

{
  "packages": [{
    "product_id": "premium_video_millennials",
    "budget": { "amount": 50000 },
    "targeting_overlay": {
      "axe_exclude_segment": "seg_existing_customers_acme"
    }
  }]
}

3. Sales Agent creates line item:

Line item: "Acme Q1 Acquisition"
Targeting: axex != "seg_existing_customers_acme"

Serving (Real-Time)

4. User visits publisher site:

GET /ad-request
User-Agent: Mozilla/5.0...
Cookie: uid=abc123

5. AXE lookup:

Input: uid=abc123
Check: Is abc123 in seg_existing_customers_acme?
Result: YES (hashed email matches)

6. AXE response:

{
  "axei": null,
  "axex": "seg_existing_customers_acme",
  "axem": null
}

7. Ad server decision:

Line item requires: axex != "seg_existing_customers_acme"
Current axex: "seg_existing_customers_acme"
Decision: DO NOT SERVE (user is existing customer)

Result: Acquisition budget is not wasted on existing customers.

Core Capabilities

1. Dynamic Audience Targeting

Bring your own DMP/CDP segments to publisher inventory:

• Upload audience data (hashed emails, device IDs, etc.)
• Receive segment IDs from your orchestrator
• Reference segment IDs in axe_include_segment
• AXE matches users at impression time

Use cases: Lookalike targeting, CRM activation, behavioral segments

2. Brand Suitability

Real-time content evaluation at impression time:

• Content classification - News, entertainment, sports, etc.
• Sentiment analysis - Positive/negative content detection
• Keyword blocking - Brand-specific term avoidance
• Adjacency rules - What other ads are on the page

Brand suitability rules flow from Signal Agents through the orchestrator to AXE.

3. Cross-Publisher Frequency Management

Unlike publisher-side caps, AXE tracks exposure across:

• Multiple publishers
• Multiple campaigns
• Multiple devices (with identity resolution)

AXE enforces frequency caps and returns segment decisions to the ad server. The ad server doesn’t know why a segment matched or didn’t match—it just knows whether to serve.

How Cross-Publisher Frequency Capping Works

Cross-publisher frequency capping is now handled by the Trusted Match Protocol (TMP), which uses structurally separated Context Match and Identity Match operations. The AXE segment model maps to TMP’s offers and eligibility responses.

In the AXE model, every eligible impression is checked in real time against shared exposure state:

In TMP, this same pattern is achieved with structural privacy: the Identity Match path handles frequency caps (the buyer checks exposure history without knowing what page the user is on), and the Context Match path handles content relevance (the buyer evaluates packages without knowing who the user is). The publisher joins both responses locally.

4. First-Party Data Activation

Activate your customer data without sharing PII:

1. Hash customer identifiers (emails, phone numbers)
2. Upload to orchestrator (data stays with orchestrator)
3. Reference via segment ID in campaigns
4. AXE matches at impression time
5. Publisher never sees raw customer data

Privacy by Design: Opaque Segment IDs

A key AXE design principle is that segment IDs are intentionally opaque. The ad server only sees that segment ABCD passed or failed—it doesn’t know what type of targeting the segment represents.

This could mean:

• User exceeded frequency cap
• Page failed brand suitability check
• User is in a first-party suppression list
• User matches an audience segment

This opacity protects buyer data. Publishers and ad servers cannot reverse-engineer:

• Which users are in buyer CRM lists
• Frequency cap thresholds
• Brand suitability rules
• Audience segment definitions

All the ad server knows is: “AXE says serve” or “AXE says don’t serve.”

Integration Points

For Buyers

Step	Action	Result
1	Upload audience to orchestrator	Receive segment ID
2	Include segment ID in create_media_buy	Campaign created with AXE targeting
3	Monitor delivery reports	Track segment match rates

For Publishers

Publishers don’t implement AXE directly — the orchestrator handles integration (see How AXE Reaches the Page). Publisher responsibilities:

1. Enable the orchestrator’s integration - Add RTD module (Prebid) or enable platform integration
2. Accept key-value targeting - Pass axei, axex values to ad server
3. Configure line items - Target on AXE segment key-values
4. Declare support - Indicate AXE compatibility in adagents.json

For Orchestrators

Orchestrators operate the AXE layer:

1. Segment ingestion - Accept audience data from buyers
2. Real-time lookups - Sub-10ms segment membership checks
3. Signal integration - Apply brand suitability and contextual signals
4. Frequency state - Maintain cross-campaign exposure tracking
5. Ad platform integration - Expose segments via Prebid RTD module, platform container, or server-side endpoint

How AXE Reaches the Page

AXE is a protocol-level concept. Orchestrators implement AXE and integrate it into ad serving environments. The integration path depends on the ad platform:

Integration Path	How It Works	Example
Prebid RTD module	Orchestrator distributes a Prebid module that calls the AXE endpoint during auction	exampleRtdProvider
Proprietary ad platform	AXE runs as a container or secure enclave within the platform’s infrastructure	Platform-native integration
Server-side	AXE endpoint called server-to-server by the ad platform before decisioning	Custom ad server integration

The common thread: whatever the integration path, AXE evaluates segments and returns axei/axex/axem decisions that the ad platform uses for targeting. For cross-publisher frequency capping, those impression-time calls are what let the buyer apply shared exposure rules across sellers instead of relying on one publisher’s local ad server counter.

The Chain: Orchestrator → AXE Endpoint → Segment Targeting

Ad platform calls orchestrator's AXE endpoint
  → AXE evaluates segments and returns axei/axex/axem values
  → Values used for targeting decisions (key-values, container logic, etc.)
  → Matching campaigns serve

The axe_integrations URL in a seller’s get_adcp_capabilities response tells buyers which orchestrator’s AXE endpoint the seller connects to:

{
  "media_buy": {
    "execution": {
      "axe_integrations": ["https://axe.example.com"]
    }
  }
}

Prebid Integration (Web)

For web publishers using Prebid, AXE integrates via the orchestrator’s RTD module. The module name in Prebid matches the orchestrator, not “AXE”:

test=false

// Prebid build includes: rtdModule, exampleRtdProvider, ...other modules

pbjs.setConfig({
  realTimeData: {
    auctionDelay: 100,
    dataProviders: [{
      name: 'example',       // Orchestrator's module name
      waitForIt: true,
      params: {
        // Orchestrator-specific configuration
      }
    }]
  }
});

The orchestrator’s RTD module:

1. Intercepts the auction before bids are requested
2. Sends an OpenRTB-style request to the AXE endpoint
3. Receives segment decisions (axei/axex/axem)
4. Sets targeting key-values on the ad server request

Publishers don’t need to know AXE internals — the orchestrator’s module handles everything.

Proprietary Platform Integration

AXE can also run within proprietary ad platforms as a container or secure enclave. In this model:

• The orchestrator deploys AXE logic into the platform’s infrastructure
• Segment evaluation happens within the platform’s decisioning pipeline
• No external network call is needed at impression time — reducing latency
• The platform calls AXE as part of its native ad selection process

This is particularly relevant for platforms that don’t use Prebid or where latency requirements are stricter than what an external RTD call allows.

Identifying AXE Support

The definitive check is the seller’s get_adcp_capabilities response. For Prebid-based integrations, you can also inspect the page directly:

What to look for	Where	Meaning
axe_integrations in capabilities	get_adcp_capabilities response	Seller supports AXE
axei/axex/axem key-values	Ad server request (network tab)	AXE segments flowing to ad server
Orchestrator RTD module (e.g., exampleRtdProvider) in Prebid build	Page source or pbjs.installedModules	AXE via Prebid
Orchestrator entry in realTimeData.dataProviders	pbjs.getConfig('realTimeData')	AXE is active

Different orchestrators may implement AXE through different integration paths — the segment protocol (axei/axex/axem) is the same regardless of how AXE is deployed.

Universal Macro:

Creatives can receive AXE context data for dynamic rendering:

<img src="https://cdn.brand.com/creative.png"
     data-context="{AXEM}" />

The {AXEM} macro contains base64-encoded contextual metadata:

• Weather conditions
• Content category
• User segment attributes (anonymized)
• Custom orchestrator data

See Universal Macros for details.

When to Use AXE

Scenario	Use AXE?	Alternative
Target users in my CRM	✅ Yes	—
Suppress existing customers	✅ Yes	—
Cross-publisher frequency cap	✅ Yes	—
Real-time brand suitability	✅ Yes	—
Target “millennials in California”	❌ No	Express in brief
Geographic restrictions	❌ No	Use geo_countries
Publisher’s audience segments	❌ No	Express in brief
Single-publisher frequency cap	❌ No	Publisher ad server handles this

Performance

AXE is designed for ad serving latency requirements:

Operation	Target Latency
Segment membership lookup	< 10ms
Brand suitability evaluation	< 20ms
Frequency check	< 5ms
Combined AXE decision	< 50ms

Related Documentation

• Targeting - Brief-based targeting and geographic overlays
• Signals Protocol - Signal discovery and activation
• Universal Macros - Creative-level AXE integration
• Orchestrator Design - Building orchestration platforms