Intent (ARTF)

Intent in ARTF is the reason an agent gives for an edit it wants to make to a bid request in flight. ARTF is the Agentic Real-Time Framework, one of the repositories in IAB Tech Lab’s AAMP programme and the only one released as a Tech Lab standard, at v1.0 in November 2025. It is published as agentic-rtb-framework, since renamed agentic-real-time-framework, and the old URL redirects.

Agents ship as container images, and an orchestrator runs them against live traffic and accepts or rejects each mutation they propose. That orchestrator is the party running the auction: RTBRequest carries a tmax described as the time “the exchange allows for mutations to be received”, and the originating party is typed TYPE_PUBLISHER, TYPE_SSP, TYPE_EXCHANGE or TYPE_DSP. The wire field is a protobuf enum, the framework document and the Agent Manifest each name intents their own way, and only the enum is compiled.

The Intent enum

Nine members are defined. INTENT_UNSPECIFIED is the proto3 zero value, leaving eight usable.

The enum lives in rust/proto/agenticrtbframework.proto, package com.iabtechlab.bidstream.mutation.v1, which reserves 1000 to 1999 “for experimental/test intents”. It reaches the wire twice. Mutation.intent says what one proposed edit is for, one intent per edit, on the bidstream mutation object (field 1). RTBRequest.applicable_intents is the list the orchestrator will accept, sent before the agent replies (repeated field 7).

The framework document declares a different type

Agentic_Real_Time_Framework_Version_1_0_FINAL.md declares string intent = 1; where the shipped proto declares Intent intent = 1;. The Go and Rust bindings are generated from the proto; nothing is generated from the framework document.

None of the five names the document uses in its examples and glossary exists in the enum:

pb.Intent_activateSegments does not exist, so Go source carrying a document name will not compile, and the Go agent’s federation config rejects the same string in a config file. Issue #10, opened in March 2026 and unanswered, asks how to prevent a container mutating deals it does not own, phrasing the question around “expireDeals or adjustDeals”. Both names come out of the normative document.

The Agent Manifest, a third vocabulary

A separate vocabulary rides on the container image: JSON in an image label keyed agent-manifest, where a container declares “the intents they will invoke”. The spec adds: “If the orchestrating entity cannot support the requirements and intents of a container, it should not be started.”

These are capability categories: what kind of agent this is, not what edit it wants. bidResponseGeneration and auctionOrchestration have no enum counterpart, and no enum value maps onto exactly one manifest intent, so an orchestrator matching a manifest against applicable_intents has no published mapping to follow.

The specification gives the manifest two label names. The key is agent-manifest, and a later section says “the manifest may be stored as a string with the container label com.iabtechlab.artf.descriptor with a Base64 value”, alongside com.iabtechlab.artf.container-version.

The manifest’s own intents list — a different field from Mutation.intent — differs in every file that declares one. The framework specification lists seven {name, description} capability objects, docs/00-EXAMPLE.md lists five enum names, the Go Dockerfile lists seven and omits ADD_CIDS, and rust/Dockerfile lists three in a label that is not valid JSON. No schema and no code validate the manifest, so the malformed label is never caught.

Which values each reference agent implements

The Rust bindings carry every value in the enum. The Go const block and both name maps stop at ADD_METRICS = 7, and the Go handler for the missing value says why: “ADD_CIDS intent requires protobuf regeneration to be fully supported.” That handler returns nil, nil.

applicable_intents matters more, because pre-flight negotiation is where ARTF’s governance story lives. The field is present in the Rust bindings at tag 7 and absent from the Go ones: the Go reference agent hardcodes an empty slice under the comment “For now, pass nil which means all intents are applicable”, and all five samples set a field it cannot read. A ValidIntents list in its federation config carries all eight names and matches with strings.EqualFold, so the binary accepts add_cids as configuration for a value its own bindings cannot express.

The JSON path drops the field instead. The MCP tool pulls applicable_intents out of a request as raw strings, validates none of them, and never puts them on the pb.RTBRequest it builds. Under federation those strings reach filterMutationsByIntent, which matches case-sensitively against enum names, so a request asking for activateSegments gets back zero mutations and no error.

Intent in AdCP and in AAMP’s seller agent

Four schema properties in AdCP 3.1.13 have names containing “intent”, all four inside Sponsored Intelligence, and all four free text describing a human’s request rather than an agent’s capability. si-get-offering-request.json calls its intent an “Optional natural language description of user intent for personalized results”. AdCP has no mutation vocabulary because it has no mutation object; its serve-time layer is the Trusted Match Protocol, and capability is declared at runtime through get_adcp_capabilities rather than stamped into image metadata at build time. The verbs collide too: ACTIVATE_SEGMENTS edits one auction in flight, while activate_signal provisions a durable activation_key.

Within AAMP the term is not shared either. seller-agent v2.4.1 carries NegotiationState.last_intent, an untyped Optional[str] that a chat classifier sets to pricing_inquiry, availability_inquiry, deal_request or counter_offer. It shares no type with ARTF in either direction.

Related terms: bidstream mutation, Trusted Match Protocol, activation, Sponsored Intelligence. The repository is covered file by file in AAMP Explorer.