Measurement agents: brand.json discovery and live rate queries

[bokelley]

Context

PR #1962 adds structured performance_standards and measurement_terms to guaranteed media buys. The vendor field on performance standards identifies a measurement company by brand-ref (domain). The vendor's brand.json at that domain is the discovery point for their agent capabilities — consistent with how brand_agent and rights_agent are already advertised in brand.json.

Structural Priority: brand.json agent discovery

brand.json already advertises:

• brand_agent — brand data via MCP (url + id)
• rights_agent — rights licensing via MCP (url + id + available_uses)

Measurement vendors need the same pattern. A measurement_agent entry (or a generic agents array) in brand.json would let any company advertise measurement capabilities:

{
  "house": "doubleverify.com",
  "measurement_agent": {
    "url": "https://api.doubleverify.com/adcp/measurement",
    "id": "dv_measurement",
    "supported_metrics": ["viewability", "ivt", "brand_safety"]
  }
}

This is the structural foundation that must be right before building the task interface. The vendor field on performance-standard.json already points to the domain — brand.json is where the agent URL lives.

Decision: named agents vs generic agents array

Currently brand.json uses named fields (brand_agent, rights_agent). Options:

1. Add measurement_agent as another named field (simple, consistent with existing pattern)
2. Add a generic agents array with typed entries (more extensible, but different pattern)

Recommend option 1 for now — it matches the existing pattern and measurement is a well-defined concept.

Live Measurement Data Flow

Once a buy is active with agreed performance standards, how does the seller (or buyer) query the measurement vendor for current rates?

Consistent with content standards

Content standards already solve the analogous problem:

• Content standards: validate_content_delivery — "was this ad placed next to safe content?" (batch audit of delivery records)
• Performance standards: measurement agent — "what percentage of impressions were viewable?" (live rates for active buys)

Both should use agent-to-agent workflows. The data flow pattern should be consistent:

Pull model (consistent with content standards):

1. Buyer/seller calls measurement agent with media buy reference
2. Measurement agent returns current rates per agreed performance standard
3. Rates compared against agreed thresholds; breach triggers makegood

Push model (alternative):

1. At buy creation, a callback URL is registered
2. Measurement agent pushes rate data periodically or on breach
3. Similar to existing push_notification_config pattern

The pull model is more consistent with content standards. The push model might be more practical for real-time breach detection. Both could coexist.

Scope

In this issue

• brand.json schema: add measurement_agent (or equivalent)
• Define the measurement agent task interface (query rates for a media buy)
• Ensure consistency with content standards data flow

Not in this issue (done in PR #1962)

• Performance standard schemas
• Makegood policy and remedy types
• Cancellation policy
• required_performance_standards filter on get_products
• TERMS_REJECTED error code

Follow-up issues

• Makegood workflow operational mechanics (propose/accept/dispute via update_media_buy)
• Storyboards for guaranteed buy workflows (depends on Integrate storyboard-driven testing into @adcp/client adcp-client#423)

[bokelley]

Splitting this issue

Part 1 (PR incoming): brand.json agents array

• Generic agents array on both house and brand objects, replacing the pattern of named agent fields
• New brand-agent-type enum: brand, rights, measurement, governance, creative, buying, signals
• Deprecates brand_agent and rights_agent named fields
• Establishes brand.json as the canonical source for public agent discovery

Part 2 (remaining): Measurement agent task interface

• Live rate query tasks (pull/push patterns for viewability, attention, etc.)
• Consistent data flow pattern with content standards agents
• Depends on part 1 merging first

Design decisions

• No independent AAO registry — the registry is assembled from crawled brand.json files and community-hosted brand.json
• "Add my agent" = "put it in my brand.json" — members managing agents on the AAO site are editing their (community-hosted) brand.json
• One agent per type — no "primary" flag needed; filter by type
• Sales agents stay in adagents.json — that's publisher authorization, not brand declaration
• Buying agents in brand.json — "here's my media buying agent, here's how you talk to it"