Use Cases

By default, you and your team can interact with your agent through the cloud portal, but lot more sophisticated use cases can be unlocked beyond that. The channels configured for the agent, and data sources connected to the agent can allow you create infinite use cases for yourself, your internal team or for your customers. Without configuring channels, you will only be able to send task to your agent from the cloud portal.

The below are a few uses cases possible by configuring agents:

Customer Facing Conversational Agent

Example of these can include:

  • Customer Email Support
  • Customer Voice Support
  • 24/7 Booking Service
  • Triaging Agent for Healthcare Business
  • Inbound Lead Call (Customer Profiling and Assessment)

Interacting with the configuration page creates a yaml that mirrors the configuration you’re making; below settings will be a section of the yaml that can create some unique use cases:

Inbound Voice Interaction

The below example shows a section of what would be an ideal settings to configure an agent that will be able to take inbound voice conversations.

Inbound voice interaction over api auth.

The below makes the agent take inbound conversation over voice widget. Turns off the video, end ensures the authentication is required. The authentication information is coming from a connected knowledge graph called “UserDataSource”. To make the agent not require authentication, set authentication: false

engine: taskflow
mode: conversational_inbound
 - credentials:
      allow_video: false
      authentication: true
      type: api
      users: "UserDataSource"
    name: widget

The users of this channel will connect via a special URL that can be found on the settings > Widget Settings. From the page, you can share the URL or QR code with the users that can authenticate against the agent based on the configuration.

Widget Connection URL

Inbound Voice interaction static list

The below makes the agent take inbound conversation over voice widget. Turns off the video, end ensures the authentication is required, but only from known list of people with the stated email. Not ideal for large number of people as api authentication type will be more effective for large number.

engine: taskflow
mode: conversational_inbound
 - credentials:
      allow_video: false
      authentication: true
      type: static
      users:
        - "user1@email.com"
        - "user2@email.com"
        - "user3@email.com"
    name: widget

Inbound Mail Interaction

The below example shows a section of what would be an ideal settings to configure an agent that will be able to receive an email of task to be done. This can be used for a customer support agent that responds to customers over email, an internal team agent that responds to the team, or an agent that allows potential customers to make enquiries.

Default Email Receiver

The below settings allow a Compose AI user to be able to assign task to the agent over email. The user can send the task to ai.employees@composeai.io to assign task to the agent, but the email must come from the email account used to create an account.

channels:
  - credentials:
      imap_mail_server: system
      mail_from: ai.employees@composeai.io
      mail_password: system
      mail_username: system
      smtp_mail_server: system
    name: email

Custom Email Receiver

This use case allows for email defined in api-datasource-name (which could be your customers), to be able to interact with your agent. The below settings allow a Compose AI user to connect to a custom IMAP/POP server to receive email sent to your agent. The authentication: true means the agent will only answer to some users that are in the api-datasource-name. If authentication, types and users are not defined, only the Compose AI account will be able to send a task to the agent.

channels:
  - credentials:
      imap_mail_server: imap-email-server.com
      mail_from: email@server.com
      mail_password: IMAP/POP-Password
      mail_username: email-username
      smtp_mail_server: smtp-mail-server.com
    name: email
    authentication: true
    type: api
    users: "api-datasource-name"

Custom Email Receiver

Allow anybody to email your agent. Could be useful for an enquiry based based agent. This can only be done with a custom maul server not ai.employees@composeai.io

channels:
  - credentials:
      imap_mail_server: imap-email-server.com
      mail_from: email@server.com
      mail_password: IMAP/POP-Password
      mail_username: email-username
      smtp_mail_server: smtp-mail-server.com
    name: email
    authentication: false 

API interaction

Sending tasks via APIs allow you to integrate the agent orchestration layer into your other systems. You can create a new task by sending an API that looks like the structure below.

curl -X 'POST' \
  'https://api.composeai.io/api/v1/tasks/' \
  -H 'accept: application/json' \
  -H 'X-API-KEY: API-Secret-Key' \
  -H 'Content-Type: multipart/form-data' \
  -F 'priority=medium' \ 
  -F 'task=Do one, two and three for me' \  
  -F 'agent_id=abcd-1234-efgh-0987-djhd' \ 
  -F 'frequency=dnr' \ 

The API-Secret-Key can be gotten from Settings > API Keys

API Keys Page

Telephone Interaction (Coming Soon)

Telephone receiver allows you to configure agentic use cases similar to the described ones above. You can either allow your known phone number, a list of known phone numbers, an API call that returns phone number authenticate against the agent to be able to interact with it. Also, you can set authentication:false on the channel, allowing any body to be able to interact with the agent.

Let anyone call the agent

channels:
  - credentials:
      sip_trunk: telephone_trunk
      sip_credential: credentials 
    name: telephone
    authentication: false 

Let a list of known numbers call the agent

channels:
  - credentials:
      sip_trunk: telephone_trunk
      sip_credential: credentials 
    name: telephone
    authentication: true
    type: static
    users: 
        - "010203040506" 
        - "030203040506" 
        - "090203040506" 

Let known phone number authenticate via api

channels:
  - credentials:
      sip_trunk: telephone_trunk
      sip_credential: credentials 
    name: telephone
    authentication: true
    type: api
    users: "users-datasource-name"