ARTF Architecture and Workflows

This page describes the core execution architecture of the Agentic RTB Framework (ARTF) and illustrates how request and response flows are structured within a host platform.

1. Legacy execution versus ARTF

In the legacy programmatic model, a single impression often triggers a sequence of external HTTP calls:

  • The host (for example, an SSP) constructs an OpenRTB bid request.
  • The request, or parts of it, are sent to multiple third-party endpoints for identity, enrichment, fraud checks, and other functions.
  • Each call typically adds tens to hundreds of milliseconds of latency.
  • The final enriched request is then forwarded to buyers, which must still respond within a strict timeout.

This "bolt-on" approach leads to high aggregate latency, uneven performance, and significant data exposure, because substantial portions of the bidstream are shared across many independent systems.

For readers familiar with the traditional SSP–DSP–data vendor chain, the following schematic shows where ARTF changes the execution layer while preserving the overall roles of supply, demand, and specialist services.

graph LR P1[Publisher or app] --> H1[Legacy host] H1 --> S1[External services] H1 --> B1[Buy side platforms] P2[Publisher or app] --> H2[ARTF Host Platform] H2 --> A1[Agent identity] H2 --> A2[Agent context] H2 --> A3[Agent fraud and quality] H2 --> B2[Buy side platforms]

ARTF reorganizes this execution pattern:

  • Third-party logic is packaged into containers and deployed inside the host platform's infrastructure.
  • The host interacts with these containers through a standardized API rather than through ad hoc external HTTP calls.
  • Calls between the host and agents are local, using high-performance RPC, which reduces end-to-end latency and allows more computation within the auction window.

2. Structural components

Within ARTF, three elements work together:

  • Host platform (orchestrator). Runs the primary auction or decisioning services, owns the environment, and is responsible for invoking agents, enforcing policy, and applying or rejecting their proposed changes.
  • Agent services. Implement specific functions such as identity resolution, fraud detection, contextual or audience enrichment, bidding logic, or analytics. Each agent is delivered as a container image with a manifest describing its capabilities and requirements.
  • Container runtime. Provides isolation and resource control for agents while allowing them to execute efficiently alongside the host's own services.

The host uses the agent manifest to understand which intents an agent supports, what resources it needs, and how it should be monitored and governed.

3. Request-side workflow example

A typical request-side workflow in an ARTF-compliant host can be summarized as follows:

  1. Impression event. A user interaction or ad slot triggers the creation of an OpenRTB bid request within the host platform.
  2. Agent selection. Based on configuration and context, the orchestrator determines which agents should run for this impression (for example, an identity agent, a contextual enrichment agent, and a fraud-detection agent).
  3. Data preparation. For each agent, the host prepares an input payload that contains only the data required for that agent's declared intents.
  4. Local RPC call. The host invokes each configured agent via gRPC (or another supported RPC mechanism defined by the framework), passing the prepared data.
  5. Agent processing. Each agent executes inside its container, applies its logic, and returns an ARTF response containing one or more OpenRTB Patch mutations, each tagged with an intent.
  6. Mutation evaluation. The host reviews the proposed mutations, applies policy, and decides which changes to merge into the live bid request.
  7. Downstream auction. The enriched and validated request is then sent to buyers using standard OpenRTB flows.

The following diagram illustrates this interaction at a conceptual level:

graph LR U[User] --> P[Publisher] P --> H[Host platform] H --> ID[Agent identity] H --> CTX[Agent context] H --> F[Agent fraud and quality] H --> B[Buy side platforms]

Because all agent calls occur within the host's environment, network overhead is substantially reduced while keeping the host in control of both data and outcomes.

4. Response-side and post-bid workflows

ARTF also supports workflows that operate on bid responses or post-bid events:

  • A host can invoke validation or optimization agents on bid responses before selecting a winner.
  • Post-bid or post-impression events can be processed by measurement or quality agents under the same containerized model, using the same standardized interfaces.

These patterns allow the same agentic infrastructure to be reused for multiple stages of the lifecycle, from pre-bid evaluation to post-bid analysis.

5. Orchestration strategies

Hosts can adopt different orchestration strategies depending on their objectives and constraints:

  • Sequential orchestration. Agents are executed in a defined order when there are dependencies between them (for example, running identity resolution before audience segmentation that relies on resolved IDs).
  • Parallel orchestration. Independent agents are invoked in parallel, and their patches are merged when all responses have been received.
  • Conditional orchestration. The host may decide which agents to invoke based on real-time context, such as supply type, geography, regulatory regime, or publisher preferences.

In all cases, the host is responsible for:

  • Enforcing time budgets for each call.
  • Logging which agents ran and which mutations were proposed and applied.
  • Ensuring that agents operate only within their declared intents and permissions.

This architecture is designed to make the programmatic execution layer more predictable, auditable, and adaptable, while remaining compatible with the existing OpenRTB data model.