AI Services

Overview

AI Services represent a versatile and impactful type of AI solution designed to execute complex tasks and reasoning via Quiq's public API.

AI Service flows are extremely flexible, allowing customizable request and response options and enabling all of the common utility provided by AI Studio without requiring any middleware. This flexibility allows AI Services to handle a wide range of scenarios empowering users to craft applications tailored to specific needs.


Getting Started

AI Services are created and managed like other AI Studio Projects, and can be created using the New Project button, or in the Services tab:

AI Services are published and versioned just like traditional assistants, and can be exported and imported as desired:


Starting an AI Service

AI services always begin flow execution from an API Definition Behavior. The behaviors configuration defines the endpoint used to begin the execution as well as the request and response payload if applicable:

The two** API Definition Behaviors** that signal the start of the sample AI Service

The two API Definition Behaviors that signal the start of this example AI Service


📘

Unlike Assistants, there is no session or conversation associated with a service execution, meaning that each execution is completely separate from any other.

API Definition Behaviors

The API Definition is a Behavior that is unique to AI Services and is what defines the public API used to initiate the flow:


The behavior defines several pieces of data including the Request Body as well as an optional response:


Request

Endpoint ID: The ID of your endpoint, once added a Draft and Published version of your endpoint will be visible in the Endpoints section at the bottom of the behavior

Method: API Definition behaviors support GET and POST methods.

Body:

  • Encoding can be JSON, YAML, or XML

Defining Properties

It's not required to define any properties in the Body, however doing so enables you to define the type:

as well as additional details, like whether or not the property is required:


Defining properties in the body of your Behavior also makes them accessible in the visual rules editor, enabling you to condition off of them or set values:


📘

Any defined properties will be validated and your AI Services requests can fail if the contract is not satisfied.

Undefined Properties

Properties that are not defined will not be stripped out of the request context, meaning that they can be accessed via the Function Editor, but will not be accessible in the Flow panel UI.

Response

Similar to the Request, it is not required to define all properties that will be returned from the service, but using it as a form of validation is recommended.

Return Type can be JSON, YAML, XML, or None

Asynchronous vs Synchronous

If Return type is set to None a checkbox enabling the response to run Asynchronously appears:

This can be helpful in situations you're calling into a system with a short timeout.

📘

Returning a Response Asynchronously

When Run Asynchronously is enabled, you can set up a Call API at the end of your flow to submit the results into your system.

Handling Undefined Properties

Under normal circumstances an error will occur when attempting to set a non-existent field from a programmatic action. In order to get around this for the response, a new code only setResponse action is available for AI Services only:

def build_response(context):
  actions = []

  value = {
    'successful': True,
    'completion': context['prompts']['test-prompt']['completion']
  }

  setResponse = {
    "action": "setResponse",
    "endpoint": "test",
    "value": value
  }
  actions.append(setResponse)

  return {"actions": actions}

This enables you to leverage any of the properties you may get back from your API, without having to define them one by one in your API Definition Behavior.

On request

The API Definition Behavior has a rule handler where you can configure visual rules and actions , including a location change to the next Behavior in the flow:

Endpoint Dispatcher

Because AI Services do not revolve around conversations like other Projects do, the Chat Panelis not available, and instead a new Endpoint Dispatcher panel is available that enables you to test and preview your AI Service without publishing your experience.:


You can toggle between your different endpoints using the dropdown at the top of the panel:


Key Differences Between AI Services & AI Agents

While AI Services and AI Agents use much of the same components of AI Studio, there are some key differences between them.

Fields

AI Services exist outside the context of a session or conversation, which means they don't have access to botSession field types, conversation field types, or customer field types. Additionally, AI Services Fields cannot be reported on in analytics currently.

Field TypeFormatAI ServicesAI Agents
Bot Session Fieldsbot.session.[fieldname]Not AvailableAvailable
Custom Conversation Fieldsconversation.custom.[fieldname]Not AvailableAvailable
Customer Fieldsconversation.customer.custom.[fieldname]Not AvailableAvailable
AI Services Fieldsfields.[fieldname]AvailableNot Available

Ending an AI Service

Unlike other AI Studio projects, AI Services do not need to transition to a Close or Route Behavior to end their flow without an error. Instead, they will simply stop running once they reach the last behavior that has no further change location action configured.

🚧

Errors in AI Services

Because of their ability to end at any point, you will not receive errors when a behavior does not go anywhere or do anything, like you would with other Project types. This makes it especially important to check your work before publishing changes to ensure your AI Service is behaving as expected.