Relational Agents are computer agents designed to form long-term, social-emotional relationships with their users. We are investigating the use of these agents in task domains in which human-agent relationships actually improve task outcomes, such as in coaching, counseling, psychotherapy and healthcare.

Litebody Protocol

The server is deployed at a URL that is known to the client: the agent URL. Messages sent to this URL either request information about the agent as a whole, or request a new conversation.

Each conversation is assigned a conversation URL by the server. To carry on a conversation once started, the client sends messages to the conversation URL.

All messages sent by the client may include parameters in a key-value form, passed in as for an HTML form:

Some parameters are common to all messages (but may be optional).

Below is a block diagram of various components and their interaction between other components.

Interaction with the Agent URL

Agent Description

The server responds to a GET message with an agent description, including:

Conversation Startup

A POST message to the agent URL requests a new conversation.
The server replies with a conversation description containing the new conversation URL in the case of success.
If the conversation could not be started, the server must reply with an HTTP error.


Messages to a Conversation URL

<CONVERSATION xml:base="[URL]" URL="[URL]" ACTIVE="[true|false]">
(<VIEW ID="[string]"/>)*
(<ACTION ID="[string]"/>)*

POST messages

A POST message to a conversation URL is a request to advance the state of the conversation. All POST messages are in the form of an XML document. The server replies with the next action message.

GET messages

A GET message is a request for some status, and does not change the state of the conversation. GET messages may have a query parameter called "action" which specifies what information is requested. If not supplied, the default is "action=description".

Replies from a Conversation URL

Litebody Protocol offers several elements for interaction. A specific response from the agent could contain ONE of the following elements; Input element OR Perform element OR Exit element.

The INPUT element:

The input element specifies the type of input the user would be provided with to interact with the agent. The input element could consist of either one of the following types: Menu, FreeText and Widget. The input element also contains a timeout attribute. The timeout value specifies the time (in seconds) the input type should show up before it times out. The timeout is optional, and if not provided, its an infinite timeout.

The different types of input elements are as follows:

The PERFORM element:

The element contains synchronized and/or unsynchronized elements. Synchronized events contain either eyebrow gestures, audio, duration, etc. The “synchronized” events are synchronized with audio, and occur at specified frame numbers. The “unsynchronized” events occur serially, and timing is not specified; the client is free to perform them at whatever speed is appropriate. It could be a posture shift, eye gaze, clear page, pointer, expression, background, headnod, etc.

Any URL within PERFORM (audio, images, etc.) is allowed to be a relative URL. If so, it should be resolved using the xml:base element on <perform>

The EXIT element:

The element can contain an optional ‘url’ attribute and an optional ‘reason’ attribute to specify the reason for exit.

Authentication and Authorization

When the server reports in the agent description that authentication is needed, the client should append additional parameters to every subsequent request:
- user=<string>
- pass=<string>

Authentication, if required, must be used for every request made by the client except for a GET message to the agent URL (which returns the agent description).

The server reports authentication and/or authorization failures with the following HTTP error codes:
- 401 Unauthorized -- bad username, or no authentication provided
- 449 Retry With -- bad password


This spec describes authentication but does not by itself provide any security, as usernames and passwords are sent in cleartext. If security is desired, layer this protocol over HTTPS rather than HTTP.