Beyond Skills: Introducing Intent Protocols (Role-Bound Coordination for Multi-Agent Systems)

[gNtino]

Hi all,

First off—thank you for the incredible work on A2A. The protocol is already solving a major barrier in agent ecosystems: interoperability, secure communication, and capability discovery across heterogeneous agents.

As I’ve been working with A2A, one pattern keeps emerging: skills alone aren’t enough for multi-agent coordination when intent spans multiple trust boundaries.

1. Skills Aren’t APIs (as raised in #921)

As @ognis1205 highlighted in #921, skills are descriptions, not APIs.

This leads to:

• Ambiguity: "Make a reservation"—hotel? restaurant? flight?
• Overlap: Similar skills (e.g., "Analyze doc" vs. "Summarize doc") competing for the same intent.
• Routing complexity: Larger skill catalogs degrade accuracy.

These are manageable in single-agent contexts. But when real-world intents involve multiple agents across organisational boundaries, this ambiguity quickly becomes a blocker.

2. What’s Missing: Shared Semantics and Roles (Example: Move Home)

Let’s ground this in a concrete scenario:

Say I tell my AI agent: “Move my family to Zone 1, London, by 15 August.”

This intent spans multiple independent actors and trust boundaries:

• Buyer (me) providing funds and ID.
• Lender issuing a mortgage offer (after income verification and valuation).
• Conveyancer clearing title with the Land Registry.
• Seller accepting an offer.
• Estate agent managing listings.

Today, A2A can connect these agents. But it doesn’t define:

• Shared state: Who holds the authoritative view of the property, mortgage, or title?
• Roles and responsibilities: Who is accountable for each step (valuation, title clearance, offer acceptance)?
• Preconditions/postconditions: What must be true before a mortgage offer is binding or a title can be transferred?

Without this structure, even with A2A connectivity, coordination devolves into ad hoc messaging and private state silos.

3. Intent Protocols: Structured Coordination on Top of A2A

Here’s how the same "Move Home" intent looks expressed as an Intent Protocol (Buy Property):

In this view:

• Roles: Buyer, Lender, Conveyancer, Land Registry, Seller.
• Shared objects: Listing, Offer, Property, Ownership Title, Mortgage Offer.
• Preconditions:
  -- Identity verified (buyer)
  -- Offer accepted (seller)
  -- Property valuation (for mortgage)

Each role could be filled by an A2A-compatible agent. But instead of exchanging opaque messages, they coordinate by updating shared semantic objects (e.g., mortgageOffer.status), bound by clear preconditions and consent rules.

This transforms “agent chatter” into auditable, structured multi-agent coordination.

4. Why We Call Them Intent Protocols

We call these Intent Protocols because they are defined around a shared intent (goal) and specify:

• The roles required to fulfill it.
• The preconditions and postconditions for coordinated progress.
• The shared semantic objects and signals that anchor state.
• The consent boundaries that control visibility and trust.

In enterprise contexts, these can also be framed as Business Protocols:

• Codifying trust, semantics, and accountability across firm boundaries.
• Similar to how industries adopt domain-specific standards (e.g., FHIR in healthcare, FIX in finance), but agent-compatible and intent-driven.

5. Proposal: Layering Intent Protocols on A2A

We see value in layering Intent Protocols over A2A to provide:

• Shared vocabularies: Standard objects and signals per domain (e.g., Property, MortgageOffer).
• Role binding: Agents commit to roles (e.g., SecureFinance.Lender v1.2) with explicit entry criteria.
• Pre/post conditions: Declarative constraints enforce order and trust.
• Consent scoping: Role-based visibility into shared state.

This would complement A2A:

• A2A provides secure messaging, capability discovery, and task lifecycle.
• Intent Protocols add semantics, trust, and structured coordination logic.

6. Questions for the Community

• Would A2A benefit from formalising protocol binding—agents declaring readiness for specific roles under a protocol?
• Could protocol registries help manage versioning and interoperability between agents?
• How do we preserve A2A’s flexibility while enabling structured, auditable coordination across roles?

Closing

I see this as complementary: A2A handles the pipes. Intent Protocols define the grammar for coordinated, trustworthy participation.

Thanks for the great work here—excited to hear your thoughts!

[blakebrannon]

@gNtino Love this framing of “intent” as the coordination layer—it aligns closely with some thinking I’ve been doing around how privacy context could be understood and enforced across agents. In the same way human teams operate within a shared intent (e.g., a project goal) and implicit norms for appropriate data use, I think agents need a similar contextual awareness: what behavior is aligned with purpose, acceptable within privacy and compliance boundaries, and still effective.

Curious if others have explored how “intent” could be used to scope what agents are allowed to do—not just technically, but ethically and legally. How do we give agents the right context for purpose limitation, especially when multiple agents are collaborating?

[gNtino]

I really like this framing—you're spot on that intent can serve as the anchor for privacy and purpose context, similar to how human teams implicitly share norms within a project goal.

With intent protocols, we can make those implicit norms explicit and machine-readable. When agents coordinate under a protocol (e.g., BuyProperty), the intent itself defines the shared context, roles, and boundaries:

• Purpose-limited access: while bound to BuyProperty, a lender agent can access an income document only for affordability checks, not outside that context.

• Consent scoped by role: the conveyancer sees title data but not income; the lender sees income but not title—enforced through role-based visibility within the protocol.

• Purpose-tagged objects: data can carry tags like purpose: ["mortgageAssessment"] with expiry (validUntil: 90 days), so any access is tied to the protocol’s defined purpose.

• Auditable state changes: every signal (mortgageOffer.approved, titleCleared) is logged in the context of the intent and role that triggered it.

This mirrors human collaboration: in a project, we know what’s appropriate without restating it at every step. In multi-agent systems, the protocol gives agents that same shared "frame" for both action and constraint.

The key is that when the intent (protocol) closes, those permissions and context expire automatically, removing the risk of lingering access or uncontrolled reuse.

I’m curious—do you see this enforced best within protocols (shared semantics and roles) or at the agent level, where policies interpret intent context locally?

[lukehinds]

This kind of sounds like something sematnic routing would typically cover, however in regards to Intent, its tricky to get right, unless coupled with some form of RL.

Then the system groks mismatched outcomes and learns and adjusts accordingly.

To give a bad example: An Agent gets an Uber Agent Car to take me to "Clive's Cuts" for a haircut, and I arrive at "Clive's Cuts" the Steakhouse, where I end up with a 12oz ribeye rather than a trim to my noggle. In a traditional semantic routing system, this might just be logged as an error. However, with the RL component, the system would apply a penalty to this routing decision, effectively learning that despite potential semantic similarities (both establishments named "Clive's," both involve "cuts"), the context and intent are fundamentally different.

Over time, these penalties would train the system to better distinguish between superficially similar but functionally distinct destinations or actions. The RL aspect allows the system to not just recognize patterns, but to actively improve its routing decisions based on real-world outcomes - moving beyond pure semantic similarity to incorporate practical consequences and user satisfaction into its decision-making process.

I guess this would be YELP for agents lol. Apologies if I am taking this off-track, its a great point and I love seeing disucssions like this 🙏

[gNtino]

I really like your "Clive’s Cuts" example because it highlights where semantic routing fits and where intent protocols add structure.
Here’s how I’d frame it using sense → make sense → act:

Sense (Clarify intent and select protocol)

First, clarify the intent and select the appropriate intent protocol.
With "Book at Clive’s Cuts," the system must decide: is this BookHaircut or BookDinner? Semantic routing (and RL) help here—hairdresser vs. steakhouse—so we select the BookHaircut intent protocol as the governing frame.
A2A today focuses on discovering agents with advertised skills and routing requests to them. What we’re proposing shifts this up a level: first select the intent protocol that frames the coordination (e.g., BookHaircut), and then discover and bind agents to its roles. Skills are still used, but now scoped within roles defined by the protocol rather than competing globally.

Make Sense (Apply preconditions and bind agents to roles)

Inside the BookHaircut protocol, we bind roles:

• Customer (the user or their personal agent),
• Hairdresser (the salon’s agent),
• Transportation (Uber’s agent).

Semantic routing still applies, but now it’s scoped: only agents meeting a role’s preconditions can bind.

• The Hairdresser must be a licensed salon and expose a BookHaircut skill aligned with the protocol.
• The Transportation agent must be a verified provider. etc

Each role also defines postconditions that gate progress:

• The Hairdresser must emit appointment.confirmed before Transportation is triggered.
• The Hairdresser then emits haircut.completed, which closes the core BookHaircut protocol.
• A return Transportation.trip.completed can still run, but as a follow-on task—it doesn’t hold up the protocol’s completion.

If an agent fails preconditions (e.g., Clive’s Steakhouse can’t satisfy Hairdresser), it simply doesn’t bind, keeping the space open until a valid agent fills the role.

Act (Execute with verified roles and shared state)

With roles bound and pre/postconditions satisfied, signals flow (appointment.confirmed, haircut.completed), shared state updates, and any ancillary actions (like the Uber return) execute without blocking the protocol’s closure. The sequence—book haircut, confirm, complete the appointment, and optionally trigger transport—runs in order, verifiable and without a coordinator holding private state.

Why This Matters

By selecting the intent protocol first, we anchor everything in a shared frame (roles, objects, pre/postconditions). Semantic routing still drives discovery and refinement, but both intent clarification and agent binding now happen within explicit constraints—eliminating the haircut vs. steakhouse error before any action occurs.

This also shifts the load away from a single “personal agent” orchestrating across others (the coordinator pattern), toward agents binding directly into the protocol and coordinating through shared state and signals.

The same pattern scales to broader intents like "Move Home": first select the appropriate protocol—BuyProperty, RentProperty, or even TemporaryAccommodation—depending on the situation. Then bind roles (Buyer or Tenant, Lender, Conveyancer, Land Registry, Transportation) with pre/postconditions gating progress (identity verified → valuation or lease checks completed → mortgage approved or tenancy confirmed → title or lease finalized).

Whether you’re buying, renting, or arranging short-term accommodation, intent protocols frame coordination first and then bind agents into roles—turning discovery into structured, verifiable action.

[lukehinds]

Right! I got it, love it.

You're right, something like this would fit very well into the Agent ecosystem. it makes me think of eths smart contracts!

Agent: Hairdresser
  Skills: ["BookHaircut", "Cut-Hair"]
  Verified: true
  Licenses: ["SalonLicense123"]

Agent: Transportation
  Skills: ["TransportToLocation", "TransportFromLocation"]
  Verified: true
  ProviderStatus: "verified"

Step 1: Hairdresser emits appointment.confirmed
→ Condition: Hairdresser must be a licensed salon
→ Effect: Unlocks Transportation.initiatePickup

Step 2: Hairdresser emits haircut.completed
→ Condition: Hairdresser must complete the BookHaircut protocol
→ Effect: Protocol is marked as complete

Optional: Transportation emits trip.completed (return trip)
→ Condition: None (can be async follow-on)
→ Effect: Logged for tracking, not blocking

if (msg.sender == hairdresser && isLicensedSalon(hairdresser)) {
    emit AppointmentConfirmed(client);
    enableSkill(transportAgent, "TransportToLocation");
}

if (msg.sender == hairdresser && haircutDone) {
    emit HaircutCompleted(client);
    completeProtocol("BookHaircut", client);
}

if (msg.sender == transportAgent && returnTripDone) {
    emit ReturnTripCompleted(client); // Non-blocking
}

Are you planning on building a prototype @gNtino or feeling out the nuances first?

[gNtino]

Love the smart contract analogy—it captures the essence perfectly: roles, gated actions, and verifiable state transitions.

Right now, my focus is on refining the intent protocol specification layer: defining roles, shared objects, and pre/postconditions clearly so they can be exercised against A2A’s agent/skill model. The BuyProperty and BookHaircut specs are designed to be immediately testable in a lightweight simulation or mock A2A setup.

I see prototypes as the next step, using existing A2A task lifecycles and skill-binding to:

• Bind agents to roles (e.g., Lender, Conveyancer),
• Emit signals (mortgageOffer.approved, titleCleared),
• Progress protocol state visibly.

I’d love to collaborate with anyone already working in A2A on wiring these worked examples into a small proof-of-concept. The parallels to smart contracts—gated state changes triggered by verified roles—are exactly how we see this scaling into verifiable agent coordination.

[ognis1205]

I’m not yet fully familiar with the entire scope, advantages, and disadvantages of the protocol being proposed here, but I believe similar research has been conducted in the field of classical (not in a negative sense) NLU. It might be worthwhile to look into prior work. If the protocol proves to be useful, those findings could also be valuable when drafting the specification.

[gNtino]

Thanks for raising this—you're absolutely right that classical NLU (Frame Semantics, slot filling, dialogue state tracking) offers relevant foundations for representing intent and progression.

Classical NLU tackled the problem of interpreting an utterance, mapping it to an intent (e.g., BookFlight), filling slots (e.g., destination=Paris, date=March 5), and executing it within a single system or service boundary. Intent protocols build on that foundation but extend intent into multi-agent coordination across trust boundaries, where multiple independent agents (e.g., buyer, lender, conveyancer) bind to roles, act on shared semantic objects, enforce preconditions, and progress collaboratively toward a goal.

Here’s a draft spec showing how classical NLU concepts—slots, frame roles, and state tracking—translate into intent protocol form:

intent protocol: BuyProperty
version: 1.0
description: >
  Coordinate the purchase of a property to move a household to Zone 1, London by a specified date.

intent:
  exampleUtterance: "Move my family to Zone 1, London by 15 August"
  slots:                       # <-- Derived from NLU slot filling
    location: "Zone 1, London"
    deadline: "2024-08-15"

roles:                         # <-- NLU "frame roles" become multi-agent roles
  Buyer:
    requiredSkills:
      - submitOffer
      - provideIdentity
  Lender:
    requiredSkills:
      - applyForMortgage
      - approveMortgage
  Conveyancer:
    requiredSkills:
      - verifyTitle
      - registerOwnership
  LandRegistry:
    requiredSkills:
      - updateOwnership
  Transportation:               # Ancillary but scoped to the same intent
    requiredSkills:
      - bookMoveService

objects:                        # <-- Shared semantic state, like NLU slot schemas
  Property:
    fields:
      address: string
      location: string
      valuation: number
      status: enum [searching, offer_made, offer_accepted, title_cleared]
  MortgageOffer:
    fields:
      amount: number
      status: enum [pending, approved, declined]
  Title:
    fields:
      status: enum [pending, cleared, transferred]

preconditions:                  # <-- Inspired by dialogue state gating
  - Lender.applyForMortgage requires Buyer.identityVerified = true
  - Lender.approveMortgage requires Property.valuation != null
  - Conveyancer.verifyTitle requires MortgageOffer.status = approved

postconditions:
  - Lender.approveMortgage emits MortgageOffer.status = approved
  - Conveyancer.verifyTitle emits Title.status = cleared
  - LandRegistry.updateOwnership emits Title.status = transferred

stateMachine:                   # <-- Derived from Dialogue State Tracking
  states:
    - init
    - identity_verified
    - mortgage_approved
    - title_cleared
    - completed
  transitions:
    - from: init
      to: identity_verified
      condition: Buyer.identityVerified = true
    - from: identity_verified
      to: mortgage_approved
      condition: MortgageOffer.status = approved
    - from: mortgage_approved
      to: title_cleared
      condition: Title.status = cleared
    - from: title_cleared
      to: completed
      condition: Title.status = transferred

This bridges NLU and agent coordination: NLU informs intent parsing and slot grounding, while intent protocols govern multi-agent binding, shared state, and auditable progression.

These NLU formalisms (e.g., Frame Semantics, Dialogue State Tracking) could directly shape how we define protocol schemas and state machines in a formal specification. I’d be keen to hear which prior NLU work you think best fits as a reference point to frame the Intent protocol specification structure