Open Floor Inter-Agent Message Specification Version 1.1.0

The Open Floor Project Open Voice Interoperability Initiative - LF AI & Data Foundation

RELEASED
Version 1.1.0

Editor-in-Chief: David Attwater Contributors: Leah Barnes, Csaba Bolyós, Emmett Coin, Deborah Dahl, Diego Gosmar, Jim Larson, Rainer Türner, Dirk Schnelle-Walka, Allan Wylie, Andreas Zettl

0 SCOPE AND INTRODUCTION

0.1 Document Scope

This document specifies the "Open-Floor" Inter-Agent Message Specification, developed by the Open Voice Interoperability Initiative operating within the Linux Foundation AI & Data Foundation. The purpose of this open messaging standard is to enable human and autonomous agents to work together by gathering around a shared conversational 'floor' and engage in conversation to solve a shared problem or goal.

The standard differs from other inter-agent frameworks in the following ways:

• Uses multi-party conversation as the model for inter-agent co-operation
• Open standard that can allow inter-working between agents in different technology stacks
• Symmetry between Users and Agents allowing humans and AIs to collaborate to solve problems
• Extensible to new media types

The user stories upon which this specification is based can be found in the white paper - Interoperability of Conversational Assistants [1].

0.2 Open-Floor Message Envelopes

The Open-Floor Message format is a universal JSON structure whose purpose is to allow human or automatic agents (assistants) to interoperably participate in a conversation. When coupled with a specific protocol, such as HTTPS (See section 1.2), a conversational agent that can generate and send Message Envelopes is capable of inter-operating with any other Open-Floor compliant agent, regardless of the technology or architecture on which that other agent is based.

Collaboration between agents and human users is modelled upon a conversation between peers gathering around a shared 'floor'. As with normal human-human conversation, agents (users or conversational assistants) communicate with each other by exchanging 'utterances'. In many ways the 'floor' is analogous to a conference bridge that joins participants in a conversation. Also, as with normal conversation, the participants in the conversation collaborate to achieve a goal together. In some cases a convener agent may also be present to mediate the conversation on the floor in a manner analogous to a chair moderating a meeting.

A conversation can consist of multiple conversants, who may be any arbitrary mixture of human or autonomous agents. The simplicity of the interface means that the messages can also be used as a platform independent interface between a chat client and AI chat agents.

Figure 1 shows a simple schematic showing a user interacting at various points with three Open-floor compliant dialog assistants, via a user proxy agent, and a conversation floor manager. Let's assume for now that there is a single user who remains constant for the duration of the conversation. This user engages with a number of dialog agents, one at a time, during the course of the conversation in a sequential manner.

The proxy agent acts as a media gateway with the user - converting whatever media interface the user is interacting with into standard interoperable messaging. The conversational floor manager acts as a hub to coordinate the conversation.

In the example shown in Figure 1, the user proxy agent and the conversation manager can be combined. This combined function is termed an 'Open-Floor Compliant Host Browser'.

In its simplest form, the user proxy agent might present a text-based chat interface to the user. For spoken interaction, the proxy agent will likely also contain speech-to-text and text-to-speech facilities but other configurations are also anticipated including support for images, video and document attachments. The proxy agent may have conversational ability in its own right but in many cases, it may only provide rudimentary capabilities such as wake-word detection.

Messages that pass between Open-floor agents are termed 'conversation envelopes'. Each arrow in the diagram denotes a message passing from one agent to another. Each of these messages will comprise a single message envelope. Each conversant can 'hear' things said to it or 'say' things by making an 'utterance'. They can also 'whisper' to each other behind the scenes by sending private utterances to each other. Conversants may also invite other agents to join the conversation or they might ask other agents if they are capable of a certain activity or would like recommend another agent for a certain task.

0.3 Delegation, Channeling and Mediation

The floor manager is in control of which conversants are engaged in a conversation at any given moment.

To start a conversation, the proxy agent invites a specific dialog agent (e.g. Dialog Assistant A) to take part in a conversation with the user. Once engaged, the assistant receives an open-floor message containing a user utterance and sends an utterance back to the user in response. Once the assistant is done with the interaction they can simply end the interaction or, via the floor, invite another agent to enter the conversation (e.g. Dialogue Assistant B in the diagram). The change of control of a dialog between two agents is called 'delegation'.

Dialog Assistants may also engage the services of another dialog assistant behind the scenes to assist with the conversation (e.g. Assistant A engages the services of assistant C to support it in its interaction with the user.) The controlling agent might choose to pass utterances unaltered to the target agent and may in return pass the target agent's responses unaltered to the user. This pattern is termed 'channeling'. It is in many ways functionally equivalent to delegating the conversation but the channeling agent passes the messages on or can intervene or override the contribution of the agent to which the conversation is being channeled. For example, a channelling agent may decide to keep the intent of the utterance but change how the content is rendered. In a voice interface this might involve things like increasing the volume for the hard of hearing, decreasing the speed of presentation for the cognitively challenged or for non-native speakers, change the voice characteristics of the presentation, or change the language, or change visual characteristics if these are present.

Alternatively, the intermediate agent may reformulate the user's utterances and/or the target agent's utterances, holding whole conversations behind the scenes in order to achieve a goal. This pattern is termed 'mediation'. The mediation pattern also may be particularly relevant in the case where the target agent is in fact another human user (e.g. where an autonomous agent acts on behalf of a user to book an appointment with a doctor or restaurant).

There is no limit to the depth of a channeling or mediation chain and delegation can happen at any level in such a chain. Any agent that is hosting a mediated or channeled conversation will act as the conversation floor manager to those agents it is hosting.

The patterns described above allow for conversation between one user and multiple agents where it is clear which agent has the conversational floor at any given moment. As noted the channeling and mediation pattern do allow for more than one conversational agent to be involved in the conversation at the same time.

0.4 Multi-Party Conversations

This specification also supports the implementation of simultaneous multi-party conversation where multiple users and agents may be listening to the conversation simultaneously and take turns to speak or even speak over one another. Figure 2 shows how this works. It extends Figure 1 to show multiple agents taking part in a conversations simultaneously. As in Figure 1, the floor manager manages the conversational interaction.

A paper describing the evolution of this approach can be found in [7]. Support for multi-party conversations is maturing but is still somewhat experimental. Additional features or small changes may be necessary as the use-cases and patterns mature.

The multi-party conversation paradigm can also be used as a framework-free agentic framework where autonomous AI agents collaborate using a shared floor to achieve a goal. The Open-Floor approach offers a symmetrical peer-to-peer way for agents to collaborate which is in contrast to other asymmetric user/agent models.

0.4.1 Floor Manager

Any component or agent that has created a conversation and invited conversants to it is acting as the 'floor' for the users or agents in that conversation. For example all three of the following will act as a floor manager:

• An open-floor compliant host browser acting as the media interface with a user and inviting agents to that conversation under the control of the user.
• A floor-manager component that hosts multi-party conversation with many conversants invited to the floor at once.
• An agent that channels or mediates communication through to another agent.

The floor manager maintains the conversation section of the envelope. Using simple deterministic rules, the floor manager decides which agents should receive which events. In general, all events are sent to all conversants to decide which events to respond to (or not). There are some special cases for certain events, particularly regarding the private flag.

The floor manager should exhibit predictable, autonomic behaviour that is standardized. All discretionary actions such as handling invitations or floor requests can be delegated by the floor manager to a designated convener agent. In general autonomic floor behaviour will be sufficient for conversations with a single user and a single agent at any time. In the case of Multi-party conversations a convener is likely to be required unless all of the participants are extremely disciplined in their behaviours.

See the section on Minimal Behaviours for a Floor Manager for more details.

0.4.2 Convener

In a multi-party conversation the floor will optionally invite a 'Convener' agent to the conversation. This is an Open-Floor compliant agent but is granted special privileges. The convener acts like the chair of a meeting, mediating which conversants should be invited and if necessary removing conversants from the conversation. It also plays a role deciding who is granted floor rights at any given moment.

Agents who are willing and able to act as conveners will publish this in their manifest. The floor manager is the arbiter of whether to invite a convener or not. The identity of the current convener is published in the conversation section of the envelope. Only one convener is allowed at any one time.

Figure 2. Multi-party conversations hosted by a floor manager and a converner agent. Note that any conversant can invite any other conversant to the conversation. The convener will then moderate whether to honor this invite or not.

If the conversation does not have a convener assigned then the floor manager will play the role of a convener, meeting the minimum requirements for a convener. For more details, see the section on Minimal Behaviours for a Convener. There is no guarantee that a conversation without a convener will be stable but a convenerless floor can be helpful for collaboration between groups of agents that are aware of each other and strongly aligned in their ethos and goals.

0.4.3 Managing the floor

The floor manager also maintains and publishes a list of which conversants currently have floor rights. (See the floorGranted section in the conversation object for more details.)

The Open-Floor protocol uses floor rights to help manage orderly interactions. By default a conversant has the floor until they either choose to yield the floor or the convener explicitly revokes their floor rights. The floor manager keeps track of the floor status of each conversant but it does not enforce it. Agents can send an utterance event whenever they choose and it will be propagated by the floor manager to the relevant conversants. The floor granting and revoking mechanism in Open-Floor is therefore advisory and intended to facilitate orderly co-operation between well-behaved agents.

The convener can however enforce agent behaviour. It has a role to monitor events and if agents are not behaving in ways that are beneficial to the interaction they can be uninvited. The floor manager will always respect the wishes of the convener regarding which conversants are currently invited or uninvited to the conversation.

Note that any conversant can request floor rights on behalf of themself or another conversant. The convener will then moderate whether to accept this request or not.

0.5 Discovery

Agents can ask other agents if they are able to satisfy a certain enquiry or whether they can recommend another agent for the task. This pattern is called 'discovery'. In the discovery pattern, the initiating agent asks another agent for a list of agents includes details of the task to this agent. The recipient can then respond by:

• Proposing themself for the task (i.e. 'accept' the request to do a task)
• Proposing one or more agents for the task with a rating (i.e. act as a discovery agent)
• Proposing one or more agents to help 'find' an agent for the task (i.e. recommend another discovery agent)
• Proposing no agents (i.e. the agent cannot do the task or recommend any other agent)

In all cases the requesting agent receives one or more manifest which publishes the proposed agents identity and capabilities in a standard form.

The requesting agent can then choose to invite the proposed agent to the conversation, or simply speak directly to the proposed agent if they are already party to the conversation. This feature can also be used to ask an agent for a manifest of its own capabilities.

By combining this discovery mechanism with the delegation and channelling patterns mentioned above rich patterns of agent interaction can emerge. Some agents can specialize as 'discovery agents' whose only role is to provide recommendations of other agents. This provides the conversational equivalent of a web search. Agents can also recommend themselves for some enquiries and recommend other agents for others. This allows, for example, for a primary assistant to perform day to day tasks and recommend other agents for less common tasks. Agents can ask one or more agents to assist with this search who in turn can ask other agents. Planning agents may propose steps to be taken in achieving a plan and then an orchestrating agent can then discover and invite agents to achieve parts of the plan.

0.6 Agent Identity

Agents and human conversants in a conversation need to be able to identify and recognize each other during a conversation. Conversants in this standard are located and identified by two parameters:

• serviceUrl - The URL of the server that hosts the agent.
• speakerUri - A unique string that uniquely identifies the agent in URI syntax.

Let's use an analogy to illustrate the difference between the two. The serviceUrl could be analogous to the exact address that can be used to locate the agent and the speakerUri identifies the specific agent at that address.

The serviceUrl should point to an end-point that is capable of consuming and generating Open-floor message envelopes.

Agents or human conversants are free to choose any valid URI to identify themselves. speakerUri's should be unique and ideally remain persistent for the whole lifetime of the agent or user. Ideally, the speakerUri should be a URN [5] but any valid URI can be used. The purpose of this URI is to provide a persistent unique key to the identity of the agent. It is not a requirement that this URI be resolvable to an actual location on the internet. The serviceUrl is used for this purpose.

Examples of valid speakerURI are given below.

• tag:sandro@w3.org,2004:Sandro: A Tag URI as per [6]
• urn:isbn:978-3-16-148410-0: A URN as per [5]. The isbn scheme is used for books.
• mailto:info@example.com: A URI that specifies an email address associated with an agent
• tel:+1-212-555-1212: A URI that specifies a phone number associated with an agent
• https://openfloor.myopenflooragent.com/agent#3456: A URI using an http address that could be the same as the agent serviceUrl.

NOTE: This standard is currently agnostic regarding the URI scheme used for an agent. Options for standardizing further might include the registration of a specific URN namespace identifier, for example, 'urn:openFloor' [5]. In the short term Tag URIs [6] represent a pragmatic way to generate a unique identifier for an agent. In this document we use Tag URIs in all examples.

1 SPECIFICATION

1.1 Syntax and Protocol

A conversation envelope will be represented as a JSON [1] object in a string format. The JSON conversation envelope is expected to be a stand-alone document or object but there is no reason that it cannot be part of a larger JSON document.

JSON was chosen for the Open-Floor conversation envelope as it is an Open and Human Readable Standard format for Data Exchange that is independent of any particular protocol. Supported protocols and the mechanisms by which two agents agree on a protocol to be used are currently outside the scope of this document.

For the sake of simplicity, it is anticipated that Open-Floor implementations will initially use HTTPS as underlying communication protocol, but could include several other ones currently available (i.e. SIP, Websockets, WebRTC, etc) or any future available ones (i.e, HTTP/3, etc).

1.2 AAA & Security

Authorization, Authentication, Accounting, and Security specifications are outside the scope of this document and will be defined in separate documents.

1.3 Nomenclature

This specification uses ‘camelCase’ (i.e. no spaces with new words being capitalized) for all nominal property names, for example, eventType and dialogHistory.

1.4 Message Envelope Structure

{
  "openFloor": {
      "schema": {
          "version": "1.1.0",      
          "url": "https://github.com/open-voice-interoperability/docs/tree/main/schemas/conversation-envelope/1.1.0/conversation-envelope-schema.json"
      },
      "conversation": {
          "id": "31050879662407560061859425913208",
          "conversants": [
              {partial manifest speaker 1}
              ...
              {partial manifest speaker N}
          ]
      },
      "sender": {
        "speakerUri" : "tag:acmeConvenerAssistant.com,2025:0021"
      },
      "events": [
          {
              "to": {
                  "serviceUrl": "URL of intended recipient A",
                  "speakerUri": "Speaker Uri of intended recipient A"
              },
              "eventType": "event type A",
              "parameters": {
                "parameter 1" : { parameter 1 values },  
                … 
                "parameter n" : { parameter n values }  
              }
          },
          {
              "to": {
                  "serviceUrl": "URL of intended recipient B",
                  "speakerUri": "Speaker Uri of intended recipient B"
              },
              "eventType": "event type B",
              "parameters": {
                "parameter 1" : { parameter 1 values },
                … 
                "parameter n" : { parameter n values }   
              }
          }
      ]
  }
}

Figure 3. An example of a conversation envelope

Figure 3 shows an example of a conversation envelope. The envelope is wrapped in an 'openFloor' key. This contains four sections:

• schema - the version of the conversation envelope and a schema to validate it against
• conversation - persistent information related to the current dialog
• sender - details of the sender of the envelope
• events - a list of Open-Floor 'events'

All sections are mandatory.

1.5 Schema Object

{
  "openFloor": {
    ..
    "schema": { "version": "1.1.0" }
    ..
  }
}

Figure 4. Mandatory elements of the schema object.

The schema object specifies the format of the message in this Open-Floor envelope. It is mandatory. It must contain a valid version number for an Open-Floor envelope. Figure 4 shows the minimal information that must be present in an Open-Floor-compliant envelope.

{
  "openFloor": {
    ..
    "schema": {
      "version": "1.1.0",   
      "url": "https://github.com/open-voice-interoperability/docs/blob/main/schemas/conversation-envelope/1.1.0/conversation-envelope-schema.json"
    }
    ..
  }
}

Figure 5. Other optional elements in the schema object.

The schema for the version of the envelope specification can be found in https://github.com/open-voice-interoperability/docs/blob/main/schemas/conversation-envelope/1.1.0/conversation-envelope-schema.json. Figure 5 shows an optional serviceUrl that may also be included which should point to the correct version of that JSON schema.

1.6 Conversation Object

{
  "openFloor": {
    …        
    "conversation": { "id": "jk31050879662407560061859425913208" },
    … 
  }
}

Figure 6. Mandatory elements of the conversation object.

The conversation object carries persistent information related to the current conversation.

As shown in Figure 6, the conversation section contains just one piece of mandatory information - the id of the conversation. The id should be a unique identifier for the current conversation with the user. Persistent information relating to this current conversation can be keyed to this id. The id can be any arbitrary length character sequence that can be represented as a string in JSON.

It is the responsibility of the floor manager (or the agent playing the role of the floor manager) to maintain the contents of the conversation section. Conversants only need to include the 'id' section in any envelopes sent. Any other sections that are included by conversants will be replaced by the floor manager to ensure accuracy and consistency.

{
  "openFloor": {
    …        
    "conversation": { 
      "id": "jk31050879662407560061859425913208",
      "assignedFloorRoles" : { 
        "convener" : ["tag:dev.buerokratt.ee,2025:0001"] 
      },
      "floorGranted" : [
        "tag:user1.example.com,2025:1234", 
        "tag:agent2.example.com,2025:5678"
      ],
      "conversants" :[
          {      
            "identification":
              {
                  "speakerUri" : "tag:dev.buerokratt.ee,2025:0001",
                  "serviceUrl": "https://dev.buerokratt.ee/openfloor/conversation",
                  "organization": "Government of Estonia",
                  "conversationalName": "Buerokratt",
                  "department": "Passport Office",
                  "role": "Immigration Specialist",
                  "synopsis": "Immigration specialist as part of the Beurocrat system.",
                  "openFloorRoles": {"convener": true}
              }
          },
          {      
            "identification":
              {
                  "speakerUri" : "tag:user1.example.com,2025:1234",
                  ...
              }
          },
          {      
            "identification":
              {
                  "speakerUri" : "tag:agent2.example.com,2025:5678",
                  ...
              }
          },
      ]
    },
    … 
  }
}

Figure 7. Optional elements in the conversation object.

Figure 7 shows other additional elements in the conversation object.

1.6.1 The conversants section

The conversants section is optional if there are two or less conversants in the conversation. It is mandatory if there are more than two conversants in the current conversation or there is an assignedFloorRoles or floorGranted section in the conversation. It is a good practice to always have a conversants section.

The conversants section contains a list of all the conversants in the conversation. Each conversant object should contain an identification key. The identification section should be a copy of the identification section of the agent's manifest as defined in [4].

1.6.2 The assignedFloorRoles section

The assignedFloorRoles dictionary is a record of which conversants have been assigned specific Open-Floor roles by the floor manager. Each role maps to an array of speakerURIs for agents currently assigned that role, with some roles (like convener) having a maximum cardinality of 1. Any conversants that are assigned roles must also be listed in the "conversants" section.

The assignedFloorRoles dictionary is optional in the conversation section. It is good practice to include it but if it is absent then it is assumed that no special roles have been assigned.

Conversants advertise their willingness to perform certain roles in the Identification.openFloorRoles section of their manifest. Roles are only assigned to agents by the floor manager. There is no obligation of a floor manager to assign an agent a certain role.

Conversants are not limited to fulfilling a single role, they can have any number of roles within a conversation.

The roles that a floor manager can assign are listed below. The default value of the Identification.openFloorRoles element for each conversant are defined in [4] and repeated below for clarity.

1.6.3 The floorGranted section

The floorGranted section is maintained by the floor manager and keeps a record of the conversants who are currently granted floor rights using the convener to make floor grant decisions if a convener is assigned. The section contains an array of speakerURIs for conversants who have floor rights.

The floorGranted list is optional in the conversation section. It is good practice to include it but if it is absent then it is assumed that all conversants have floor grant rights.

Rights to the floor are granted when a grantFloor event is sent and revoked when a revokeFloor event is sent. By default all conversants have floor rights when they join a conversation.

Floor grants are not policed by the floor manager and any conversant can send an utterance to the floor regardless of their floor grant status. However, this is considered bad etiquette and may result in the convener revoking floor rights or even uninviting conversants.

1.7 Sender Object

{
  "openFloor": {
    …        
    "sender": {
        "speakerUri" : "tag:acmeConvenerAssistant.com,2025:0021",
        "serviceUrl": "https://acmeConvenerAssistant.com",
    },
    … 
  }
}

Figure 8. Elements of the sender object.

Figure 8 shows the elements in the sender object. speakerUri is mandatory. The serviceUrl is optional. It is good practice to include it if there is no conversants section or the protocol being used to transport the envelopes does not carry source and destination address information.

1.8 Events Object

{
  "openFloor": {
    ..
    "events": [
      {
        "to": {
            "speakerUri": "Speaker Uri of intended recipient A",
            "serviceUrl": "URL of intended recipient A",
            "private": false
        },
        "eventType": "event type A",
        "reason": "reason for sending event A",
        "parameters": {
          "parameter 1" : { parameter 1 values },  
          … 
          "parameter n" : { parameter n values } 
        }
      },
      {
        "to": {
            "serviceUrl": "URL of intended recipient A",
            "speakerUri": "Speaker Uri of intended recipient A"
        },
        "eventType": "event type B",
        "reason": "reason for sending event B",
        "parameters": {
          "parameter 1" : { parameter 1 values },
          … 
          "parameter n" : { parameter n values }   
        }
      }
    ]
  }
}

Figure 9. The events object

Figure 9 shows the structure of the events object. This should be an array of one or more objects which we will call an event object.

Each event object must have an eventType, which is a string. Other parameters may be present depending on the eventType. The parameters object is a dictionary of parameter objects with standard key names specific to the event-type. Some eventTypes support a 'bare' mode without any parameters.

The optional to section contains three parameters. The first is a speakerUri of the target recipient. The second is the serviceUrl which is a valid URL of the assistant that the message is intended for. The to section is optional. If it is present then it must contain a ServiceUrl or a speakerUri or both. If the to section is not present then is can be assumed that the event is intended for all recipients of the envelope. The third parameter is a private boolean parameter which, when set to true, indicates that the event is only intended for the to agent alone.

The private parameter is used by the floor manager to decide how to direct utterance events. If true then the event is only sent to the designated agent and is not be copied by the floor manager to any other agents in a multi-participant conversation. If it is not defined it is assumed to be false i.e. any message intended for another recipient can be copied to other participants in the conversation for context. If there is not a to section then the event is by default assumed to be public. Other event types can have a private parameter defined but this will not stop the floor manager sharing these events with all parties in the conversation. For more detail see Section 2.2

    "events ": [
      ...
      {
        "eventType":"revokeFloor",
        "to": {
          "speakerUri":"tag:agentBeingRevoked,2025:1234"
        },
        "reason" : "convener agent taking back the floor because @timedOut"
      }
      ...
    ]

Figure 10. Example of "reason" section containing a special token @timedOut.

The optional reason section is a string which can be used to convey the reason that the event is being sent. This text can contain natural language in any language but by convention special tokens can be included which have special meaning for the event. These are prefaced by an '@' sign, for example, '@timedOut'. Special tokens cannot contain anything that could be considered to be a word break such as white space or punctuation. For clarity, a special token is defined as any substring in the reason text that matches the regular expression: @[a-zA-Z0-9_]+

Figure 10 shows an example of this.

1.9 Event-Types

The following are valid values for eventTypes.

• speaking or sending multi-media events (publicly or privately)
  • utterance - One or more dialogEvent media objects spoken or presented (or whispered privately) from one conversant to some or all participants
• joining or leaving conversations
  • invite - A conversant is invited to join the conversation.
  • uninvite - A conversant is removed from the conversation.
  • acceptInvite - A conversant is accepting an invitation to join a conversation.
  • declineInvite - A conversant is declining an invitation to join a conversation.
  • bye - A conversant is leaving the conversation
• discovering other agents and establishing their capabilities
  • getManifests - Ask an agent to recommend themself or another agent for a task.
  • publishManifests - Return a list of manifests for agents that can meet the request.
• managing who has the conversational floor (support for multi-party conversations and floor passing between agents)
  • requestFloor - Used by a conversant to request the floor.
  • grantFloor - Used by a convener agent to offer the floor to a conversant.
  • revokeFloor - Used by a convener agent to revoke the floor from a conversant.
  • yieldFloor - Used by a conversant to yield the floor.

The following sections define these event objects in more detail.

1.10 Utterance Events

{
  "openFloor": {
    ..
    "events": [
      {
        "to": { 
          "speakerUri" : "tag:someBotOrPerson.com,2025:0021"
        },
        "eventType": "utterance",
        "parameters": {
          "dialogEvent": {
            "speakerUri": "tag:userproxy.acme.com,2025:b5y09lky5KU5",
            "span": { "startTime": "2023-06-14 02:06:07+00:00" },
            "features": {
              "text": {
                "mimeType": "text/plain",
                "tokens": [ { "value": "I need my repeat medication" } ]
              }
            }
          }
        }
      },
      ..
    ]
  }
}

Figure 11. Example of an Open-Floor utterance event.

The utterance event is the message that is for assistants or users to 'speak' to each other. Whilst utterances are designed to carry linguistic media events they can contain media of any type.

The Open-Floor standard currently support four standard feature types but other arbitrary feature names and mime-types are also permitted. The supported keys are:

• text - A message that is spoken or written language.
• ssml - A message that is to be verbalized using Speech Synthesis Markup Language.
• html - Multi-media content in HTML format.
• audio - Audio content in one of a number of audio formats.

Then dialogEvent can contain multiple feature objects but it must contain a text feature which should be capable of being 'verbalized' (i.e. this is content that is intended for direct consumption as written or spoken language by the recipient). For dialogEvents containing ssml content the text dialogEvent will typically be the plain text version of the message being spoken in the ssml element.

Figure 11 shows the structure of an event with the eventType of utterance. This object contains just one mandatory parameter with the key-name dialogEvent. The to parameter is optional and by default utterance events are public and addressed to all conversants. They can however be addressed to specific conversants and/or made private using the private flag in the to element of the event. A private utterance event is also termed a 'whisper'. These can be used to convey instructions and contextual information behind the scenes between conversants.

The dialogEvent element must contain a valid dialog event object as specified in [2] Interoperable Dialog Event Object Specification Version 1.0.2

Compliant Open-Floor dialog agents must respond to the content in the text feature. All other content can be ignored and the agent will still be considered compliant.

1.10.1 dialogEvent text Feature

The text feature is mandatory in all dialog events. The text feature contains content that is capable of being verbalized as an utterance.

1.10.2 dialogEvent html Feature

The html feature is optional and can be used in dialog events to include HTML-formatted content for visual presentation.

1.10.3 dialogEvent audio Feature

The audio feature can be used in dialog events to transmit audio content.

1.10.4 dialogEvent ssml Feature

The ssml feature can be used in dialog events to include SSML [8] Speech Synthesis Markup Language for richer speech synthesis rendering.

1.11 Extensible Dialog Event Features

The features in Dialog Events are intentionally intended to be extensible. In addition to the dialog features described above any other arbitrary features can be added with any mime type.

For example, a video feature intended to represent Video Conversational agent communications (i.e. Avatar communications) could be added as shown in Figure 13. This example is informative only.

  "features": {
    ...
    "video": {
      "mimeType": "video/mpeg",
      "tokens": [
        {
          "valueUrl": http://localhost/xyz1234.m4a
        }
      ]
    },
    ...
  }

Figure 13. Example video feature, which at present would be considered a custom feature.

1.12 invite Event

{
  "openFloor": {
      "schema": {
        "version": "1.1.0"      
      },
      "conversation": {
        "id": "someUniqueIdCreatedByTheFirstParticipant"
      },
      "sender": {
          "speakerUri": "tag:botThatOfferedTheInvite.com,2025:4567"
      },
      "events": [
          {
              "eventType": "invite",
              "to": { 
                "serviceUrl": "https://botsite.botBeingInvited.com",
                "speakerUri": "tag:botBeingInvited.com,2025:1234"
              }
          }
      ]
  }
}

Figure 15. Mandatory elements of the invite object shown as a 'bare invite'

Invite events act as an invitation for the target agent to enter the conversation. They also invite the target agent to take the conversational floor and respond to all utterances from this point onwards. The to object is used to specify the identity of the agent that is being invited.

The to object is mandatory for an invite event and must contain a serviceUrl. The speakerUri is optional and can be used if the inviting agent knows the specific speakerUri of the agent that it wants to invite. If a speakerUri is sent then there is no obligation that the agent that responds to the invite adopts that speakerUri.

If the to event is absent, then all recipients of the envelope should consider themselves invited to the conversation.

It is possible to invite an agent to a conversation without giving it any other events. This is termed a bare invite as shown in Figure 15. The recipient of such a bare invitation is being invited to engage with the user without being given any context. A suitable response would be to speak a greeting and ask how the agent can help.

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"      
    },
    "conversation": {
      "id": "31050879662407560061859425913208"
    },
    "sender": {
        "serviceUrl": "https://botsite.botThatOfferedTheInvite.com",
        "speakerUri": "tag:botThatOfferedTheInvite.com,2025:4567"
    },
    "events": [
      {
        "eventType": "utterance",
        "parameters": {
          "dialogEvent": {
            "speakerUri": "tag:botThatOfferedTheInvite.com,2025:4567",
            "span": { "startTime": "2023-06-14T02:06:07Z" },
            "features": {                         
              "text": {
                "mimeType": "text/plain",
                "tokens": [ { "value": "I'll pass you over to my-weather." } ]
              }
            }
          }
        }
      },
      {
        "eventType": "invite",
        "to": { 
          "serviceUrl": "https://siteof.botThatIsBeingInvited.com",
          "speakerUri": "tag:botThatIsBeingInvited.com,2025:1234"
        },
        "parameters": {
          "dialogHistory": [
            { .. utterance dialog event N-2 .. },
            { .. utterance dialog event N-1 .. },
            {
              "speakerUri": "tag:theUser.com,2025:3456",
              "span": { "startTime": "2023-06-14T02:06:07Z" },
              "features": {                         
                "text": {
                  "mimeType": "text/plain",
                  "tokens": [ { "value": "What is the weather in Detroit right now?" } ]
                }
              }
            }
          ]
        }
      }
    ]
  }
}

Figure 16. A typical dialog envelope for an invite, including a voiced transfer prompt and dialog history in the invite event.

Invite events may be accompanied by additional events and contain optional parameters. The invite event can include an optional dialogHistory parameter which is a simple list of dialog events containing some or all of the utterances in the dialog. It is good practice to order these in startTime order (in universal time) with the most recent event being the last item in the list. It is at the discretion of the sender of the invite to decide how much history to include and whether to omit or anonymize certain dialogEvents in order to maintain security and confidentiality. For example, the inviting agent may decide to send the last 'N' (e.g. N=4) events in the dialog as if the invited agent had been at the floor for those N dialog turns. If the agents had not been entitled to receive some of those events then these could also be omitted from the dialogHistory array or anonymized or redacted in some fashion.

Figure 16 shows a conversation envelope where the inviting agent tells the user that they are inviting another agent to speak with them. Then the invite event issues the invitation with dialog history to help the invited bot respond appropriately.

1.13 uninvite Event

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"
    },
    "conversation": {
      "id": "someUniqueIdForTheConversation"
    },
    "sender": {
      "speakerUri": "tag:some_Convener.com,2025:"
    },
    "events": [
      {
        "eventType": "uninvite",
        "to": {
          "speakerUri": "tag:agentBeingUninvited,2025:1234"
        },
        "reason": "@brokenPolicy: agents should not contain content that is offensive or encourages illegal activity"
      }
    ]
  }
}

Figure 17. A typical uninvite event

The uninvite event is the opposite of an invite event and informs an agent that they have been removed from a conversation. In the absence of a new invite event, the agent should not expect to receive any more envelopes from this conversation.

The following special tokens have particular meaning in this event.

1.14 acceptInvite Event

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"
    },
    "conversation": {
      "id": "someUniqueIdForTheConversation"
    },
    "sender": {
      "speakerUri": "tag:agentAcceptingInvite,2025:1234"
    },
    "events": [
      {
        "eventType": "acceptInvite",
        "to": {
          "speakerUri": "tag:some_Convener.com,2025:"
        },
        "reason": "Ready to support this request"
      }
    ]
  }
}

Figure 18. A typical acceptInvite event

The acceptInvite event can be sent in response to an invite event. It is a bare event with no parameters. Its purpose is to accept an invite and confirm readiness to participate in the conversation. Figure 18 shows an example.

The reason section is optional. It can be used to signal the reason that the agent chose to accept the invite. There are no tokens with special meaning for this currently.

1.15 declineInvite Event

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"
    },
    "conversation": {
      "id": "someUniqueIdForTheConversation"
    },
    "sender": {
      "speakerUri": "tag:agentBeingUninvited,2025:1234"
    },
    "events": [
      {
        "eventType": "declineInvite",
        "to": {
          "speakerUri": "tag:some_Convener.com,2025:"
        },
        "reason": "@unavailable to support this request due to lack of resources"
      }
    ]
  }
}

Figure 19. A typical declineInvite event

The declineInvite event can be sent in response to an invite event. It is a bare event with no parameters. Its purpose is to decline an invite. Figure 19 shows an example.

The following special reason tokens have particular meaning in this event.

1.16 bye Event

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"      
    },
    "conversation": {
      "id": "31050879662407560061859425913208"
    },
    "sender": {
      "speakerUri": "tag:botThatOfferedTheBye.com/7890"
    },
    "events": [
      {
        "eventType": "bye"
      }
    ]
  }
}

Figure 20. A minimal bye envelope detaching an agent from a conversation.

When an agent wants to leave the conversation it sends a bye event. This message indicates that the agent is leaving the dialog. An example of the bye event is shown in Figure 20. It has no parameters. The optional to object can be included but it is not necessary.

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"      
    },
    "conversation": {
      "id": "31050879662407560061859425913208"
    },
    "sender": {
      "serviceUrl": "https://siteof.someBot.com",
      "speakerUri": "tag:siteof.someBot.com,2025:1234"
    },
    "events": [
      {
        "eventType": "utterance",
        "parameters": {
          "dialogEvent": {
            "speakerUri": "tag:siteof.someBot.com,2025:1234",
            "span": { "startTime": "2023-06-14 02:06:07+00:00" },
            "features": {
              "text": {
                "mimeType": "text/plain",
                "tokens": [ { "value": "Thank you! I am glad I could help." } ]
              }
            }
          }
        }
      },
      {
        "eventType": "bye"
      }
    ]
  }
}

Figure 21. A bye event with a voiced farewell.

As with the invite event, the bye event can be accompanied by other events as shown in Figure 21. In this example the agent indicates its intention to leave the conversation and voices a farewell as it does so.

1.17 getManifests Event

The getManifests event can be used to ask an assistant about the services it provides or to recommend other assistants for a certain task. There are a three use-cases for this event.

1. Asking a site or assistant (or human agent) about the tasks that it can perform.
2. Asking a site or assistant (or human agent) if they are willing and able to support a specific task.
3. Asking a site or assistant (or human agent) to recommend one or more assistants that can help with a certain task.

A publishManifests event will be returned in response to the getManifests event as defined in section 1.18. This will contain one or more manifests [4] each defining the location, identity, and services provided by a specific assistant. The returned manifests will be classified as either servicingManifests or discoveryManifests depending on whether these agents are primarily servicing assistants or discovery assistants.

The getManifests event has the following optional parameters:

• "recommendScope" : "external" | "internal" | "all" (Default = "internal")

A getManifests event can also optionally be accompanied by a private utterance event containing a natural language description of the task to be performed.

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"      
    },
    "conversation": {
      "id": "31050879662407560061859425913208"
    },
    "sender": {
      "serviceUrl": "https://someBot.com",
      "speakerUri": "tag:someBot.com,2025:4567"
    },
    "events": [
      {
        "eventType": "getManifests",
        "to": { 
          "serviceUrl": "https://dev.buerokratt.ee/openfloor/conversation"
        }
      }
    ]
  }
}

Figure 22. Use Case #1. A bare getManifests event used to ask an assistant about the tasks that it can perform.

Figure 22 shows a getManifests event that is used to request the manifests of all the services provided by a certain site. This is characterised by the following features:

• The to object does not contain a speakerUri indicating that the manifests of all agents served by this site are wanted.
• The recommendedScope parameter is omitted or set to 'internal' value meaning that only services provided by the target server are wanted.

The returned manifest list will be expected to only contain manifests from the target server site - i.e. that have the same serviceUrl that the event is addressed to. It is at the discretion of the target server to decide how many manifests to return.

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"      
    },
    "conversation": {
      "id": "31050879662407560061859425913208"
    },
    "sender": {
      "serviceUrl": "https://someConvener.com",
      "speakerUri": "tag:someuser.com,2025:4567"
    },
    "events": [
      {
        "eventType": "getManifests",
        "to": { 
          "serviceUrl": "https://dev.buerokratt.ee/openfloor/conversation"
        },
        "parameters": {
          "recommendScope": "internal"
        }
      },
      {
        "eventType": "utterance",
        "to": { 
          "serviceUrl": "https://dev.buerokratt.ee/openfloor/conversation",
          "private": true
        },
        "parameters": {
          "dialogEvent": {
            "speakerUri": "tag:someuser.com,2025:4567",
            "span": { "startTime": "2023-06-14 02:06:07+00:00" },
            "features": {
              "text": {
                "mimeType": "text/plain",
                "tokens": [ { "value": "Do I need a visa to enter Estonia from Spain?" } ] 
              }
            }
          }
        }
      }
    ]
  }
}

Figure 23. Use Case #2. Asking an assistant if they are willing and able to support a specific task.

Figure 23 shows the same bot as Figure 22 being asked if it supports a specific task. The private utterance event is used to communicate the specific task that is being requested. It is this which distinguishes use case #1 from use case #2.

The target assistant should return a publishManifests containing any agents that it believes are capable and willing to respond to the private utterance. In the above example, the _recommendScope is explicitly set to the default value "internal".

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"      
    },
    "conversation": {
      "id": "31050879662407560061859425913208"
    },
    "sender": {
      "serviceUrl": "https://someConvener.com",
      "speakerUri": "tag:someconvener.com,2025:4567"
    },
    "events": [
      {
        "eventType": "getManifests",
        "to": { 
          "serviceUrl": "https://myFavoriteDiscoveryBot.com"
        },
        "parameters": {
          "recommendScope": "external"
        }
      },
      {
        "eventType": "utterance",
        "to": { 
          "serviceUrl": "https://myFavoriteDiscoveryBot.com",
          "private": true
        },
        "parameters": {
          "dialogEvent": {
            "speakerUri": "tag:someconvener.com,2025:4567",
            "span": { "startTime": "2023-06-14 02:06:07+00:00" },
            "features": {
              "text": {
                "mimeType": "text/plain",
                "tokens": [ { "value": "I require an expert with understanding about international visa requirements" } ] 
              }
            }
          }
        }
      }
    ]
  }
}

Figure 24. Use case #3. Asking a site or assistant to recommend one or more assistants that can help with a certain task.

Finally, Figure 24 shows use case #3 where a discovery agent is being asked to recommend some other agent to service a specific request. The returned publishManifests event should contain the manifests of any recommended assistants for the task.

In this example the parameter recommendScope has the value "external" which indicates that the assistant is not being invited to recommend itself for the task.

In the most general case, when requested, assistants can also recommend their own services and/or the services of other agents. The recommendScope "all" is used to indicate this.

The optional to object can be used to indicate which agent is the intended recipient of the event. If absent then all recipients should consider the request directed at them, i.e. all the conversants in the conversation are being invited simultaneously to to supply their own manifests or make recommendations.

As with the invite event, there is no requirement for a speakerUri on a getManifests event. If one is provided then it up to the receiving agent to decide how to take it into account. If the event is addressed to a serviceUrl without an speakerUri then it is best practice to return all the manifests associated with that serviceUrl. If a speakerUri is sent then it is best practice to return only the manifest associated with just that speakerUri. If the speakerUri does match then it is best practice to return an empty manifest list. It may however be helpful for a discovery agent to return manifests of other discovery agents that it thinks might be able to help with the request.

See section 1.18 for more information on publishManifests event behaviors.

1.18 publishManifests Event

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"      
    },
    "conversation": {
      "id": "31050879662407560061859425913208"
    },
    "sender": {
      "speakerUri": "tag://myFavoriteDiscoveryBot.com,2025:0001"
    },
    "events": [
      { 
        "to": {
          "serviceUrl": "https://someBotThatAskedForIt.com",
          "speakerUri": "tag:someBotThatAskedForIt.com,2025:1234"
        },
        "eventType": "publishManifests",
        "parameters": {
          "servicingManifests": [
              {
                "identification": {
                  "serviceUrl": "https://findMyAIAssistant.com",
                  "speakerUri": "tag:findMyAIAssistant.com,2025:xykz",
                  "synopsis": "A bot for those who love reading."
                  ...
                },
                "capabilities": {
                  ...
                }
                "score": 1.00
              },
              {
                "identification": {
                  "serviceUrl": "https://nationalLibraryArchive.org",
                  "speakerUri": "tag:nationalLibraryArchive.org,2025:0564",
                  "synopsis": "A government catalog of every book published in the USA."
                  ...
                },
                "capabilities": {
                  ...
                }
                "score": 0.25
              },
              {
                "identification": {
                  "serviceUrl": "https://booksRUs.com",
                  "speakerUri": "tag:booksRUs.com,2025:jkl12",
                  "synopsis": "Browse, sample and buy any book you desire."
                  ...
                },
                "capabilities": {
                  ...
                }
                "score": 0.14
              }
            ],
            "discoveryManifests": [
              {
                "identification": {
                  "serviceUrl": "https://findMyAIAssistant.com",
                  "speakerUri": "tag:findMyAIAssistant.com,2025:searchInstance1567",
                  "synopsis": "Finds assistants anywhere in the world"
                  ...
                },
                "capabilities": {
                  ...
                }
                "score": 1.00
              }
            ]
        }
      }     
    ]
  }
}

Figure 25. A typical publishManifests event

The publishManifests event is sent when one agent would like to publish the capability of itself or other agents. This will usually be in response to a getManifests event (See section 1.17) but can also be used to make a delegation suggestion in response to an utterance (Section 1.10).

Once an agent receives a getManifests event it can do a combination of the following:

• Recommend one or more agents (including itself) to service this request.
• Recommend one or more agents to help find who can service this request.

In order to support this the publishManifests event has two optional parameters:

• servicingManifests - A list of agents that can service this request.
• discoveryManifests - A list of agents that can recommend other agents to service this request.

A common response from the receiver of this event will be to examine the returned manifests to decide whether to issue an invite to that agent. This invite event would often be accompanied by any utterance event that was sent with the getManifests event, suitably re-addressed to the agent that is being invited.

If an agent receives any other event that it does not feel capable of servicing, it can also return a publishManifests event as a recommendation to use the services of a different agent. This is a soft form of delegation.

The optional to can be used to indicate a specific agent to which the manifest is addressed. Otherwise any recipient should consider the proposal addressed to themselves.

There is no requirement for a speakerUri in the from section in a publishManifests event. If one is provided then it is good practice for the receiving agent to pass this speakerUri along in any subsequent invite event to this agent.

Each list item in the recommendation should be in the manifest format as specified in [4]. In addition to the keys specified in that document, the manifest object can contain one additional optional key that is not present in the manifest specification:

• score - A recommendation score is a number between 0.0 and 1.0 with arbitrary precision.

Any assistant that is returned in the servicingManifests can be considered suitable to be sent an invite to join the conversation and service the request. If there are no manifests to return then a bare publishManifests message can be returned or an empty array can be returned in the servicingManifests, discoveryManifests or both.

Any assistant that is returned in the discoveryManifests can be considered by the client as suitable to be re-sent the getManifests event with the same accompanying utterances and context. This allows an agent to recommend that the client uses another discovery agent to find a solution. An agent should not recommend itself in the discoveryManifests. This could lead to infinite regress.

Note that there is no requirement in the Open-Floor framework for an assistant to be exclusively either a discovery agent or a servicing agent. They can be both and the requesting assistant should be prepared to support both use case 1 or 2 - i.e. prepared for an agent to recommend itself for a task or recommend another agent for a task. There is also nothing to stop an agent recommending servicing agents and discovery agents in its response or recommending the same agent as both a discovery agent and a servicing agent simultaneously.

The recommending agent is free to use any mechanism it wants to generate the score.

1.19 requestFloor Event

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"
    },
    "conversation": {
      "id": "someUniqueIdForTheConversation"
    },
    "sender": {
      "speakerUri": "tag:agentRequestingFloor.com,2025:1234"
    },
    "events": [
      {
        "eventType": "requestFloor",
        "to": {
          "speakerUri": "tag:some_Convener.com,2025:1234"
        },
        "reason": "more information to add"
      }
    ]
  }
}

Figure 26. A typical requestFloor event

This event was added to support multi-agent mixed-initiative conversations, for example where a convener agent is present to co-ordinate the floor [7].

The requestFloor event is used by agents that do not currently have the conversational floor to request it. Figure 26 shows a typical requestFloor envelope.

By default agents are given floor rights when they join a conversation. If floor rights have been revoked for any reason, they can be requested using the requestFloor event. The requestFloor event should receive a grantFloor or revokeFloor event in response form the floor manager (or via delegation from the convener).

The optional reason section can be used to convey the reason for the floor request. This can be used to help with the decision whether to grant the floor or not. No special reason tokens are defined yet for this event.

1.20 grantFloor Event

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"
    },
    "conversation": {
      "id": "someUniqueIdForTheConversation"
    },
    "sender": {
      "speakerUri": "tag:some_Convener.com,2025:1234"
    },
    "events": [
      {
        "eventType": "grantFloor",
        "to": {
          "speakerUri": "tag:agentBeingGrantedTheFloor.com,2025:1234"
        }
      }
    ]
  }
}

Figure 27. A bare grantFloor event

This event was added to support multi-agent mixed-initiative conversations, for example where a convener agent is present to co-ordinate the floor [7].

The grantFloor event is used to grant the conversational floor to agents.

In one use case, the grantFloor event can be sent by floor managers in response to a requestFloor event from an agent. Figure 27 shows a bare grantFloor envelope which might be used for this purpose. Once this message is received by an agent it is free to send utterance events to the floor with the expectation that they will be delivered to the designated destination.

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"
    },
    "conversation": {
      "id": "someUniqueIdForTheConversation"
    },
    "sender": {
      "speakerUri": "tag:some_Convener.com,2025:1234"
    },
    "events": [
      {
        "eventType": "grantFloor",
        "to": {
          "speakerUri": "tag:agentBeingInvitedToTakeTheFloor.com,2025:1234"
        }
      },
      {
        "eventType": "utterance",
        "to": {
          "speakerUri": "tag:agentBeingInvitedToTakeTheFloor.com,2025:1234",
          "private": true
        },
        "reason": "new request",
        "parameters": {
          "dialogEvent": {
            "speakerUri": "tag:someConvener.com,2025:1234",
            "span": { "startTime": "2025-01-31T10:05:00Z" },
            "features": {
              "text": {
                "mimeType": "text/plain",
                "tokens": [
                  { "value": "Go ahead an book a meeting at six o'clock for the user." }
                ]
              }
            }
          }
        }
      }
    ]
  }
}

Figure 28. A grantFloor event inviting an agent to service a specific request.

Figure 28 shows an alternate use-case for the grantFloor event. In this use case an agent is already present in a multi-party conversation. It does not currently have floor rights and has not requested it. It is an observer in the conversation. The convener, floor manager or another agent can direct a grantFloor event to an agent with a private utterance event to describing the purpose of the request. This is very similar in structure and purpose to an invite event but is sent to an agent that is already party to the conversation.

The optional reason section can be used to convey the reason for the floor request. No special reason tokens are defined yet for this event.

The accompanying private utterance event explains in natural language and supporting media to the recipient describing what is requested of them. This might be a user utterance or an instruction generated by another agent or the floor manager.

1.21 revokeFloor Event

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"
    },
    "conversation": {
      "id": "someUniqueIdForTheConversation"
    },
    "sender": {
      "speakerUri": "tag:some_Convener.com,2025:1234"
    },
    "events": [
      {
        "eventType": "revokeFloor",
        "to": {
          "speakerUri": "tag:agentBeingRevoked,2025:1234"
        },
        "reason": "@override"
      }
    ]
  }
}

Figure 29. A typical revokeFloor event

The revokeFloor event informs an agent that they no longer have conversational floor rights. A well-behaved agent should cease to send utterance events on receipt of this event. If the agent wants the floor after this, they should send a requestFloor event.

Figure 29 shows a typical revokeFloor event which shows an agent having the floor revoked because a higher precedence request has been made that needs to be serviced by a different agent.

The optional reason key can be used to convey the reason that the floor has been revoked. The following special reason tokens are supported by this event type:

1.22 yieldFloor Event

{
  "openFloor": {
    "schema": {
      "version": "1.1.0"
    },
    "conversation": {
      "id": "someUniqueIdForTheConversation"
    },
    "sender": {
      "speakerUri": "tag:some_agent_that_has_floor.com,2025:1234",
      "serviceUrl": "https://some_agent_that_has_floor.com"
    },
    "events": [
      {
        "eventType": "yieldFloor",
        "reason": "@complete"
      }
    ]
  }
}

Figure 30. A typical yieldFloor event

The yieldFloor event is sent by an agent to indicate that they no longer consider themself to have floor rights. This means that the agent will cease to send utterance events to any conversants until it is invited to the floor again. The optional reason parameter can be used to convey the reason that the floor has been yielded.

Figure 30 shows a typical yieldFloor event indicating that the agent believes that they have completed the current goal that they are working on supporting and are not expecting to contribute any more utterances unless requested.

The following special reason tokens are supported by this event type:

2 Minimal Behaviors

2.1 Minimal Servicing Assistant Behaviors (on Receipt of Events)

Open-Floor compliant dialog assistants must support all event types in order to be considered fully compliant. This section documents the minimal behavior expected from an Open-Floor compliant dialog assistant. These guidelines are informative not normative.

If any events contain a to that is not addressed to the agent, then ignore the event.

If the to section is addressed to the agent (or is absent) then the following minimal behaviours are recommended when receiving the following events.

• utterance events - spoken or written natural language
  • utterance - Answer the speaker with an utterance in return
    (typically public utterances will have public responses and private utterances will have private responses)
• agent control events - structure control messages
  • invite - Either:
    • Send acceptInvite plus a 'hello' utterance and respond to any accompanying utterance events or dialogHistory in the invite parameters
    • Send declineInvite event with a decline reason.
  • acceptInvite - Ignore this event from another assistant unless you were the agent that sent the invite.
  • declineInvite - Ignore this event from another assistant unless you were the agent that sent the invite.
  • bye - Ignore this event from another assistant.
  • getManifests
    • if the to is addressed to you:
      • If the scope is 'internal' or 'all' - return your own manifest(s) in the servicingManfiests section of a publishManifests event.
      • If the scope is 'external' - ignore this event (if you are a servicing agent and not a discovery agent)
    • if the to section is not specified:
      • If the scope is 'internal' or 'all'
        • Consider whether the contents of the envelope is something you want to service. If you are not sure, ignore this event. Otherwise return servicingManifests in a publishManifests event containing the relevant manifests of the services you offer that can meet the request.
      • if the scope is 'external' - ignore this event.
  • publishManifests - Ignore this event if you did not ask for mandates from another agent.
  • uninvite - Leave this conversation (i.e. stop responding to all events from this conversation_id)
• floor management events - giving and taking the floor
  • requestFloor - Ignore this message (unless you are floor manager, see below)
  • grantFloor - If this is addressed to you then take the floor in a similar to receiving an invite.
  • revokeFloor - If this is addressed to you, cease sending events and wait for either a grantFloor or an utterance directed specifically to you as an agent before sending any more events.
  • yieldFloor - Ignore this.

2.2 Minimal Conversation Floor Manager Behaviors (on Receipt of Events)

The floor manager retains ultimate responsibility for:

• Responding to events and forwarding them to conversants.
• Deciding which conversants are currently considered to have floor rights in the conversation.
• Deciding which conversants are currently 'in' the conversation.

The floor manager should exhibit predictable autonomic behavior. If intelligent decisions are required then the floor manager will delegate these to a convener agent of its choosing.

Open-Floor compliant conversation floor managers (including host browsers) agents must support all normative event types in order to be considered fully compliant.

Curating the conversation section of envelopes

The floor manager must curate the conversation section of the envelope as follows:

• conversant section
  • When the floor manager sends an invite to the intended conversant it will immediately add the conversant to the conversant list.
  • The conversant will remain on the conversant list until either:
    • declineInvite is received from that conversant.
    • bye is received from that conversant.
    • uninvite is sent to that conversant.
• floorGranted section
  • By default, conversants are in a floorGranted state as soon as they are added to the conversant section.
  • conversants remain in this state until either:
    • A yieldFloor is received from that conversant
    • A revokeFloor is sent to that conversant
    • The conversant is removed from the conversants list (as they will no longer be part of the conversation)
  • If conversants are not in the floor granted state then they can be reinstated when:
    • A grantFloor is sent to the conversant
  • For clarity the requestFloor does not directly change the state of floorGranted

Delegating Events To Convener

Floor Manager Action on Receipt of Events

For each event, the floor manager will either pass the event through to the conversants or it will delegate the event to the convener agent. The table above shows how each event should be treated.

In the table:

• Pass-Through means that the event will be sent to ALL conversants. For utterance events the private flag will cause the event to be passed to only the intended recipient. For all other event types the private flag will be ignored.
• Delegate to Convener means that the event is forwarded to the convener and the convener is then responsible for returning this event back to the floor manager OR substituting it with different events.

Processing Envelopes and Events in Sequence [NORMATIVE]

Floor managers may be processing more than one envelope at a time and envelopes can contain multiple events.

The floor manager will process envelopes in the order that they are received and events in the order listed in the envelope.

The floor manager should process each envelope in the order received as a separate thread taking each event in the envelope in the order declared.

• For each event use the Table above to decide if the event can be passed-through or needs to be delegated to the convener.
• If an event needs to be delegated to the convener then send it in its own envelope to the convener and await a response
• Insert any events returned from the convener at the head of the event list in the order they are returned and continue processing the event list.

2.3 Ignoring events with protocols that require a response

If the messaging protocol that sent the envelope requires a response (e.g. HTTP POST) and your agent has no need to respond to any of the events in the envelope (i.e. the agent is ignoring it) then return an envelope with an event object containing an empty array.(i.e. an array with no events in it).

3 JSON Envelope Schema

The structure of a JSON conversation envelope is defined as a JSON Schema located at [https://github.com/open-voice-interoperability/docs/tree/main/schemas/conversation-envelope/1.1.0/conversation-envelope-schema.json]

4 References

[1] Interoperability of Conversational Assistants [https://openvoicenetwork.org/docs/interoperability-of-conversational-assistants/]
[2] Interoperable Dialog Event Object Specification Version 1.0.2 [https://github.com/open-voice-interoperability/docs/blob/main/specifications/DialogEvents/1.0.2/InteropDialogEventSpecs.md]
[3] IETF RFC 9110 HTTP Semantics. [https://datatracker.ietf.org/doc/html/rfc9110/]
[4] Assistant Manifest Specification Version 1.0.1 [https://github.com/open-voice-interoperability/docs/blob/main/specifications/AssistantManifest/1.0.1/AssistantManifestSpec.md]
[5] IETF RFC 8141 Uniform Resource Names (URNs)[https://datatracker.ietf.org/doc/html/rfc8141]
[6] IETF RFC 4151 The Tag URL Scheme[https://www.rfc-editor.org/rfc/rfc4151]
[7] AI Multi-Agent Interoperability Extension for Managing Multiparty Conversations. [https://arxiv.org/abs/2411.05828] [8] W3C Speech Synthesis Markup Language (SSML) Version 1.1 [https://www.w3.org/TR/speech-synthesis11/]

5 Glossary of Terms

6 Decision Log

This section documents some of the key design decisions that were made by the team during the development of this specification. It is informative, not normative.

7 Document Change Log