> ## Documentation Index
> Fetch the complete documentation index at: https://agenticadvertisingorg-feature-feedback.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

<Warning>
  AXE is deprecated. The [Trusted Match Protocol (TMP)](/docs/trusted-match) 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.
</Warning>

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:

```mermaid theme={null}
flowchart TB
    subgraph offline["Offline Setup Phase"]
        direction TB

        buyer["**Buyer Agent**<br/>• Campaigns<br/>• Budgets<br/>• Targeting"]
        signal["**Signal Agent**<br/>• Audiences<br/>• Contextual<br/>• Suitability"]
        orch["**Orchestrator**<br/>• Map to AXE segments<br/>• Sync to RTD"]
        sales["**Sales Agent**<br/>Create line items<br/>with AXE targeting"]

        buyer --> orch
        signal --> orch
        orch --> sales
    end
```

**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:

```mermaid theme={null}
flowchart TB
    subgraph realtime["Real-Time Serving Phase"]
        direction TB

        page["**Page**<br/>User visits"]
        adserver1["**Ad Server**<br/>GAM / Kevel"]
        prebid["**Prebid**<br/>OpenRTB request"]
        axe["**AXE**<br/>Segment lookup"]

        page --> adserver1 --> prebid --> axe

        axeresponse["**AXE Response**<br/>axei: Include segment<br/>axex: Exclude (suitability)<br/>axem: Creative macro data"]

        axe --> axeresponse

        adserver2["**Ad Server**<br/>Match segments to line items<br/>→ Serve ad"]

        axeresponse --> adserver2
    end
```

**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

```json theme={null}
{
  "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:**

```json theme={null}
{
  "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:**

```json theme={null}
{
  "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

<Note>
  Cross-publisher frequency capping is now handled by the [Trusted Match Protocol (TMP)](/docs/trusted-match), which uses structurally separated Context Match and Identity Match operations. The AXE segment model maps to TMP's offers and eligibility responses.
</Note>

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

```mermaid theme={null}
flowchart LR
    pubA["**Publisher A**<br/>Impression opportunity"]
    pubB["**Publisher B**<br/>Impression opportunity"]
    pubC["**Publisher C**<br/>Impression opportunity"]
    req["**OpenRTB-style request**<br/>user, placement, context"]
    axe["**AXE**<br/>Evaluate cap eligibility"]
    state["**Exposure store**<br/>cross-publisher history"]
    decision["**Decision**<br/>serve or suppress"]

    pubA --> req
    pubB --> req
    pubC --> req
    req --> axe
    state --> axe
    axe --> decision
```

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](#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`](/docs/protocol/get_adcp_capabilities) response tells buyers which orchestrator's AXE endpoint the seller connects to:

```json theme={null}
{
  "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":

```javascript test=false theme={null}
// 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: {AXEM}

Creatives can receive AXE context data for dynamic rendering:

```html theme={null}
<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](/docs/creative/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](/docs/media-buy/advanced-topics/targeting)** - Brief-based targeting and geographic overlays
* **[Signals Protocol](/docs/signals/overview)** - Signal discovery and activation
* **[Universal Macros](/docs/creative/universal-macros)** - Creative-level AXE integration
* **[Orchestrator Design](/docs/building/implementation/orchestrator-design)** - Building orchestration platforms