feat: AXE-27 add unified assets field for better asset discovery

[BaiyuScope3]

Add unified assets field to format schema for better asset discovery

Ticket: https://linear.app/scope3-projects/issue/AXE-27/adcp-protocol-fix-fix-document-improve-assets-discovery-for-tracker

Problem

Currently, buyers and AI agents have no way to discover what optional assets a creative format supports. The assets_required array only tells them the minimum assets needed, but formats often support additional assets that enhance the creative:

• Companion banners for video ads
• Third-party impression trackers for measurement
• End cards for video formats
• Secondary logos or background images

Without asset discovery, AI agents building creatives miss opportunities to create richer experiences.

Solution

Since each asset in assets_required already has a required boolean field, we introduced a unified assets array:

• required: true - Asset MUST be provided for a valid creative
• required: false - Asset is optional, enhances the creative when provided

This is cleaner than having two separate arrays (assets_required + assets_optional).

Example

{
  "format_id": { "agent_url": "https://creative.adcontextprotocol.org", "id": "video_30s" },
  "assets": [
    { "item_type": "individual", "asset_id": "video_file", "asset_type": "video", "required": true },
    { "item_type": "individual", "asset_id": "end_card", "asset_type": "image", "required": false },
    { "item_type": "individual", "asset_id": "impression_tracker", "asset_type": "tracking_pixel", "required": false }
  ]
}

Changes

• Schema: Add assets field, deprecate assets_required (still supported)
• Server: Include both assets and assets_required in format responses
• Documentation: Update format docs, asset-types, implementing-creative-agents, and task references
• Version: Bump to 2.6.0

Migration

Non-breaking change. assets_required is deprecated but still supported for backward compatibility. New implementations should use assets.

!! `assets_required` field will be formally removed in next major version release

[bokelley]

We have a "required" field already, so I think the better approach might be to rename assets_required to just assets, and have the required field determine which are needed. This would also let us do something like 'one of' in the future. I think we should deprecate assets_required but continue to support it until we fully migrate.

[BaiyuScope3]

We have a "required" field already, so I think the better approach might be to rename assets_required to just assets, and have the required field determine which are needed. This would also let us do something like 'one of' in the future. I think we should deprecate assets_required but continue to support it until we fully migrate.

Definitely agree 👍 I hesitated initially since it’s a somewhat invasive change, but it’s clearly better to make this adjustment early. I'll update the PR
we can still preserve the old assets_required field for backward compatibility.

The adcp-client PR will be posted after this is merged :)
@bokelley could you also grant me the push permission for the creative-agent repo 🙏

[bokelley]

overall - do we split out a 2.6.x branch so we can have ongoing patches to 2.5.x?

[bokelley]

why do we have to do this map anyway? why can't we just return directly from the JS client here? and shouldn't it be smart about this and map assets_required to assets.required = true so the client is magically compatible?

[BaiyuScope3]

Correct me if I was wrong, this won't be used by any adcp client, this seems used in the member page (https://agenticadvertising.org/members), where when user on a creative agent in the member directory, it opens a modal and calls loadAgentFormats(url)

In the client there is no http call needed, everything enforced by the type(schema) already, we will add logic to make the migration happens behind scene.

• So all historical data are automatically compatible
• the new creatives will automatically mapped to the new field even if they're using the old spec

[BaiyuScope3]

This PR has been moved to #490
We’re creating a separate release branch for 2.6.x. The current main branch will remain as the patch branch for 2.5.x.