[Proposal]: Intent Descriptor Extension for A2A

# Abstract

The **Intent Descriptor** is a data-only A2A extension that allows a structured business intent to be carried with an A2A message or task payload. It provides a machine-readable description of the requester’s intended business outcome, using an agreed lexicon, ontology, or semantic profile.

The goal is to help agents exchange business requests with greater clarity across enterprise and organizational boundaries. In addition to the requested intent, the descriptor may include fulfillment constraints, such as data sovereignty requirements, time windows, approval requirements, jurisdictional limits, or policy constraints.

This extension does not prescribe a single global ontology or a rigid schema for all business domains. Instead, it defines a lightweight envelope for referencing, embedding, or binding to semantic definitions that participating agents can agree on.

# Motivation

As enterprises adopt autonomous agents to execute business processes, agents increasingly need to exchange requests across organizational, platform, and vendor boundaries. Natural language alone is often insufficient for this purpose. Even structured payloads can remain ambiguous when they use generic terms such as “order,” “price,” “supplier,” “approval,” or “schedule” without a shared semantic basis.

For example, two enterprises may both use the term “purchase order,” but they may differ in whether it represents an intent to buy, an approved obligation, a legal commitment, or an ERP document already created in a system of record. Such differences can lead to incorrect delegation, failed execution, compliance risk, or unnecessary clarification loops.

The Intent Descriptor addresses this gap by attaching explicit semantic identity to business terms and actions. It allows the requesting agent to state not only what it wants done, but also how the receiving agent should interpret the intent. This supports more deterministic coordination while preserving A2A’s existing model of opaque agents collaborating through messages, tasks, and artifacts.

# Initial Technical Approach

The Intent Descriptor should be defined as an A2A extension identified by a versioned extension URI, for example:

`https://example.org/a2a/extensions/intent-descriptor/v1`

Agents that support the extension declare it in their Agent Card. Clients that wish to use it opt in through the standard A2A extension negotiation mechanism. The intent descriptor itself may be carried as message metadata, artifact metadata, or a structured data part, depending on whether it describes the request, an intermediate state, or an output artifact.

A minimal descriptor contains:

`intentType`: the semantic type of the business intent.
`ontologyRef`: a URI or identifier for the ontology, lexicon, or semantic profile used to interpret the descriptor.
`terms`: optional term bindings that map business words to stable semantic identities.
`parameters`: structured values needed to fulfill the intent.
`constraints`: optional fulfillment constraints such as time, jurisdiction, policy, data residency, budget, or approval requirements.
`confidence` or `interpretationStatus`: optional fields indicating whether the intent was directly supplied, inferred, validated, or requires clarification.

The extension is intentionally not constrained to a single rigid data schema. In many cases, two parties may already share a business lexicon or industry standard. In those cases, the descriptor can simply reference that shared semantic basis through `ontologyRef`. In more formal scenarios, the reference may point to an ontology, JSON-LD context, schema, industry profile, or enterprise semantic model.

For simpler cases, the semantic bindings may be embedded directly in the descriptor. For example, a descriptor may reference an embedded lexicon and bind the term order to a stable semantic identity such as `lexicon-id.order.v1`. This allows lightweight interoperability without requiring every deployment to adopt a full ontology stack.

Example
```json
{
"extensions": [ "https://example.org/a2a/extensions/intent-descriptor/v1" ],
"metadata": {
"https://example.org/a2a/extensions/intent-descriptor/v1": {
"intentType": "procurement.purchaseRequest.create.v1",
"ontologyRef": "https://example.org/ontologies/procurement/v1",
"terms": {
"purchaseOrder": "procurement.purchaseOrder.v1",
"supplier": "procurement.supplier.v1",
"approval": "enterprise.approval.v1",
"price": "price.us.dollar.v1",
"item": "ent.product.catalog.v3"
}, "parameters": {
"item": "laptop",
"quantity": 500,
"preferredSupplier": "contoso-supplies"
}, "constraints": {
"dataResidency": "US",
"requiresApproval": true,
"requiredBy": "2026-07-15"
}
}
}, "parts": [ { "text": "Create a purchase request for 500 laptops from the preferred supplier." } ] }
```
# Compatibility with A2A

This proposal is designed to be compatible with A2A’s existing extension model. It does not require changes to the A2A task lifecycle, transport bindings, agent discovery model, or core message structure. Agents that do not support the extension may ignore it unless the extension is marked as required by the participating agents.

The extension follows these principles:

* Use a versioned extension URI.
* Declare support through the Agent Card.
* Use A2A extension negotiation when sending a request.
* Carry the descriptor through existing metadata or structured data parts.
* Keep domain semantics outside the A2A core protocol.
* Allow domain-specific profiles to evolve independently.