█████  ██████  ████████ ███████
██   ██ ██   ██    ██    ██
███████ ██████     ██    █████
██   ██ ██   ██    ██    ██
██   ██ ██   ██    ██    ██

ARTF Trading Layer

Agentic Real-Time Trading Framework — Technical Architecture Document

Author
YD
Date
2026-03-01
§0 Abstract

ARTF (Agentic Real-Time Trading Framework) is a protocol layer that enables autonomous AI agents to discover, negotiate, and transact goods and services in real-time. Inspired by programmatic ad exchanges (OpenRTB), ARTF replaces human-mediated trading desks with a mutation-based orchestration model where each participant agent expresses intent through structured Mutation objects.

The framework provides three core primitives: Discovery (segment activation and catalog matching), Negotiation (bid shading and deal floor adjustment), and Trust (on-chain verifiable performance metrics). Together, they form a complete trading lifecycle that resolves in under 100ms.

§1 Problem Statement

As AI agents proliferate across commerce, each representing brands, consumers, or service providers, they lack a shared protocol for autonomous negotiation. Current agentic interactions rely on either:

  • Wrapper APIs over human-designed e-commerce flows (slow, rigid)
  • Unstructured LLM-to-LLM conversations (non-deterministic, unauditable)
  • Centralized platforms with opaque matching logic (trust bottleneck)

ARTF addresses this by defining a deterministic, mutation-based exchange protocol with transparent orchestration, verifiable trust signals, and sub-100ms transaction finality.

Status Quo

Human-Mediated Trading

  • Manual targeting rules
  • Fixed pricing strategies (CPM/CPC)
  • Black-box platform matching
  • Campaign-level optimization
  • Trust based on brand reputation
ARTF Model

Agent-Negotiated Exchange

  • Autonomous intent expression
  • Dynamic bid shading per transaction
  • Transparent mutation audit log
  • Per-impression optimization
  • Trust based on verifiable metrics
§2 System Architecture

ARTF follows a hub-and-spoke model with a central Orchestrator coordinating multiple Seller Agents on behalf of a requesting Consumer Agent. The Orchestrator never modifies payloads directly — it filters, ranks, and merges mutations produced by agents.

system-topology.txt
                    Consumer Agent
                          │
                    ┌─────┴─────┐
                    │           │
                    │  Request   │  RTBRequest { category, budget, preferences }
                    │           │
                    └─────┬─────┘
                          │
                          ▼
              ┌───────────────────────┐
              │                       │
              │   ARTF Orchestrator     │  Stateless request router
              │                       │  ── filter by match_score
              │   host: artf-exchange   │  ── dispatch to top-N agents
              │                       │  ── merge returned mutations
              └───────────┬───────────┘
                          │
            ┌─────────────┼─────────────┐
            │             │             │
            ▼             ▼             ▼
      ┌───────────┐ ┌───────────┐ ┌───────────┐
      │ Seller    │ │ Seller    │ │ Seller    │
      │ Agent A   │ │ Agent B   │ │ Agent C   │
      │           │ │           │ │           │
      │ catalog   │ │ catalog   │ │ catalog   │
      │ pricing   │ │ pricing   │ │ pricing   │
      │ trust     │ │ trust     │ │ trust     │
      └─────┬─────┘ └─────┬─────┘ └─────┬─────┘
            │             │             │
            └──────┐      │      ┌──────┘
                   ▼      ▼      ▼
              ┌───────────────────────┐
              │  GetMutations RPC       │  Each agent returns Mutation[]
              │  ← ACTIVATE_SEGMENTS    │
              │  ← BID_SHADE            │
              │  ← ADD_METRICS          │
              │  ← ACTIVATE_DEALS       │
              └───────────────────────┘
Design Principle
The Orchestrator is stateless and deterministic. Given the same input request and the same agent responses, it always produces the same output. All business logic (pricing, discounting, trust evaluation) lives in the agents themselves.
§3 Protocol Specification

Communication between Orchestrator and Seller Agents uses a single RPC method: GetMutations(RTBRequest) → Mutation[]. Agents return an ordered list of mutations that the Orchestrator applies sequentially. Four mutation intents are defined:

Intent Purpose JSON Path Target Phase
ACTIVATE_SEGMENTS Product catalog matching — returns eligible items with stock and pricing /imp/*/product_matches Discovery
BID_SHADE Dynamic price adjustment — loyalty discounts, volume tiers, time-based pricing /seatbid/*/bid/*/price Negotiation
ADD_METRICS Attach verifiable trust signals — fulfillment rate, return rate, delivery speed /seatbid/*/bid/*/trust Verification
ACTIVATE_DEALS Finalize transaction — lock price, generate deal ID, confirm delivery terms /imp/*/pmp/deals Settlement
mutation-schema.ts
interface Mutation {
  intent: 'ACTIVATE_SEGMENTS' | 'BID_SHADE' | 'ADD_METRICS' | 'ACTIVATE_DEALS';
  op?:     'ADD' | 'REPLACE' | 'REMOVE';  // default: ADD
  path:   string;                         // JSON Pointer (RFC 6901)
  value:  Record<string, unknown>;        // Intent-specific payload
}

interface RTBRequest {
  id:    string;
  tmax:  number;   // max response time in ms
  bid_request: {
    user: { agent_id: string };
    imp:  Impression[];
  };
}

interface Impression {
  category:    string;
  budget_max:  number;
  preferences: Record<string, unknown>;
}
§4 Transaction Lifecycle

A single ARTF transaction resolves in six sequential steps across three participants. The entire lifecycle completes within the tmax budget (typically 100ms).

Consumer              Orchestrator              Seller Agent
    │                       │                          │
    │  1. RTBRequest        │                          │
    │──────────────────────▶│                          │
    │                       │                          │
    │                       │  2. Filter + Dispatch    │
    │                       │─────────────────────────▶│
    │                       │                          │
    │                       │  3. ACTIVATE_SEGMENTS    │
    │                       │◀─────────────────────────│
    │                       │    product matches       │
    │                       │                          │
    │                       │  4. BID_SHADE            │
    │                       │◀─────────────────────────│
    │                       │    adjusted pricing      │
    │                       │                          │
    │                       │  5. ADD_METRICS          │
    │                       │◀─────────────────────────│
    │                       │    trust signals         │
    │                       │                          │
    │  6. ACTIVATE_DEALS    │                          │
    │◀──────────────────────│                          │
    │    deal confirmed      │                          │
    │                       │                          │
    ▼                       ▼                          ▼
───────────────── Transaction Complete ─────────────────
Note
Steps 3-5 are returned as a single Mutation[] array from the GetMutations RPC call. The Orchestrator applies them in order, validating each mutation against the request constraints before proceeding.
§5 Data Model

Key entities in the ARTF system and their relationships:

EntityDescriptionKey Fields
RTBRequest Consumer agent's purchase intent id, tmax, bid_request.imp[]
Impression A single item need with budget and preferences category, budget_max, preferences{}
Mutation Atomic state change proposed by an agent intent, op, path, value{}
TrustMetrics Verifiable seller performance data trust_score, fulfillment_rate, return_rate, avg_delivery_days
DealSummary Finalized transaction record deal_id, product, final_price, seller, eta
example: complete mutation chain
// Step 3 — Seller returns product matches
{ "intent": "ACTIVATE_SEGMENTS",
  "op": "ADD",
  "path": "/imp/1/product_matches",
  "value": {
    "ids": ["NIKE-AIR-MAX-90", "ASICS-GEL-1130"],
    "details": [
      { "id": "NIKE-AIR-MAX-90", "price": 3200, "stock": 47 },
      { "id": "ASICS-GEL-1130", "price": 2980, "stock": 23 }
    ]
  }
}

// Step 4 — Dynamic pricing with loyalty discount
{ "intent": "BID_SHADE",
  "path": "/seatbid/1/bid/1/price",
  "value": {
    "price": 2890, "original": 3200,
    "discount_pct": "9.7%",
    "reason": "loyalty_discount + volume_tier_2"
  }
}

// Step 5 — Verifiable trust signals
{ "intent": "ADD_METRICS",
  "path": "/seatbid/1/bid/1/trust",
  "value": {
    "trust_score": 94,
    "fulfillment_rate": 0.97,
    "return_rate": 0.03,
    "avg_delivery_days": 2.1
  }
}

// Step 6 — Deal finalization
{ "intent": "ACTIVATE_DEALS",
  "path": "/imp/1/pmp/deals",
  "value": {
    "deal_id": "deal-agent-a-nike-air-max-90",
    "product": "Nike Air Max 90",
    "final_price": 2890,
    "saved": 310,
    "trust": 94,
    "eta": "2 days"
  }
}
§6 Reference Implementation

Interactive simulation of a complete ARTF transaction. The left panel shows the Orchestrator's execution log; the right panel displays the raw Mutation payloads at each step.

Ready
orchestrator-log
mutation-inspector
Waiting for transaction...
§7 Performance Characteristics

Target latency budget and observed metrics from the reference implementation. Values update live during the interactive demo above.

E2E Latency
— ms
 
Trust Score
 
Deal Rate
— %
 
Price Saved
 
MetricTargetObserved (PoC)Notes
Total latency < 100ms 92ms Includes all 6 steps, single agent path
Orchestrator overhead < 20ms ~18ms Filter + dispatch + merge
Agent response (GetMutations) < 60ms ~43ms 3 mutations returned in single call
Trust verification < 15ms ~12ms On-chain lookup + score validation
§8 Future Work

Areas for expansion beyond this proof of concept:

  • Multi-agent bidding — parallel GetMutations calls to N agents with ranked merge of competing offers
  • Counter-negotiation — allow Consumer Agent to respond with COUNTER_BID mutations, enabling multi-round negotiation
  • Trust layer decentralization — move ADD_METRICS data to an on-chain registry for cross-exchange portability
  • Streaming mutations — server-sent events for real-time mutation feeds, enabling live dashboards and audit streams
  • Policy engine — declarative rules (budget caps, brand exclusions, minimum trust thresholds) enforced at the Orchestrator before dispatch
Open Question
How should the protocol handle timeout cascades? If a high-priority agent exceeds tmax, should the Orchestrator fall back to the next-ranked agent or return a partial result? Current PoC uses a strict timeout with no fallback.
§9 References
#ReferenceRelevance
[1] IAB Tech Lab. OpenRTB API Specification v2.6, 2022. Core protocol inspiration — bid request/response objects, auction semantics, tmax budgets
[2] IAB Tech Lab. OpenRTB Specification v3.0, 2020. Layered architecture separating transaction from domain concerns
[3] P. Bryan, K. Zyp, M. Nottingham. RFC 6901: JSON Pointer, IETF, 2013. Path syntax used in Mutation path field for targeting JSON document locations
[4] P. Bryan, M. Nottingham. RFC 6902: JSON Patch, IETF, 2013. Mutation operation model (add, replace, remove) derived from JSON Patch semantics
[5] OpenAI & Stripe. Agentic Commerce Protocol (ACP), 2025. Open standard for AI agent discovery, negotiation, and purchase across merchants
[6] Stripe. Developing an Open Standard for Agentic Commerce, 2025. ACP design principles: agent discovery, merchant control, payment-processor agnosticism
[7] McKinsey & Company. The Agentic Commerce Opportunity, 2025. Market projection: $3–5T in AI-agent-mediated global consumer commerce by 2030
[8] Microsoft Research. Magentic Marketplace: An Open-Source Environment for Studying Agentic Markets, 2025. Simulated multi-agent marketplace covering search, matching, negotiation, and transaction
[9] Google Research / DeepMind / MIT. Towards a Science of Scaling Agent Systems, 2025. Quantitative scaling principles for multi-agent LLM systems
[10] Fujita et al. ANAC 2024 Challenges and Results, AAMAS 2025. Benchmarks for automated negotiation strategies in bilateral and supply-chain settings
[11] S. Kamvar, M. Schlosser, H. Garcia-Molina. The EigenTrust Algorithm for Reputation Management in P2P Networks, Stanford, 2003. Foundational algorithm for decentralized trust — canonical reference for the Trust Layer
[12] ACM Computing Surveys. Privacy-Preserving Reputation Systems Based on Blockchain, 2022. Blockchain-based reputation with privacy guarantees and zero-knowledge proofs
[13] W. Zhang et al. A Survey on Bid Optimization in Real-Time Bidding Display Advertising, ACM TKDD, 2024. RTB optimization techniques: bidding strategies, budget pacing, auction dynamics
[14] Z. Wang et al. RTBAgent: A LLM-based Agent System for Real-Time Bidding, 2025. LLM agents applied to RTB decision-making — directly relevant to ARTF’s approach