We’ll build a workflow that demonstrates a multi-step, multi-agent workflow. At a high level, the workflow will:

  1. Listen for an email from a customer.
  2. Triage the request to the appropriate case type.
  3. If the request is a refund, attempt to refund the order.
  4. Log the result to the console.
1

Create a demo cluster

A cluster is a logical grouping of tools, agents and workflows that work together. Data is isolated between clusters, and you can have multiple clusters in your account.

2

Install the SDK

Inferable SDK has support for a variety of languages. We’ll use Node.js for this demo.

3

Create tools

The next step is to create tools that allow the agent to take actions on your behalf.

Tools are plain old functions that allow the agent to take actions on your behalf. All tools run on the machine that they are registered on.

The agent can only call tools that are registered in the cluster, so it’s a convenient way to make sure the agent is aligned with your internal systems. Agent can’t see any runtime information from the tools, only the results (including any exceptions).

We’ll create a few tools that allows us to interact with a mock database:

  1. listAllCustomers - Fetches all customers from the database.
  2. getAllData - Fetches customer data from the database.
  3. attemptRefund - Attempts to refund an order.
4

Create a workflow

We’ll now create a workflow with two agents.

Workflows are a way to orchestrate agents. They are durable, and distributed.

  • Durable: State is preserved across executions, and they can run recover from the last state in case of failures or interruptions.
  • Distributed: Workflows can run across multiple machines, and can be triggered from anywhere.

Workflows are defined as code. This means you can use existing programming primitives, like if, else, for, while, etc to control the flow between agents.

Workflows can be versioned. This allows you to ship new versions of your workflows, and not interrupt the current.trigger()ning workflows.

Workflows must not have any side effects. They should only be used for orchestration and control flow between agents. Refer to the workflows page to see how you can manage side effects.

Listening on a workflow tells the control plane that it’s ready to receive requests to the workflow from the outside world. In a production setting, you’ll have multiple replicas of the workflow running, and the control plane will load balance between them.

5

Run the workflow

We’ll now run the workflow with a request. You can run the workflow via the Inferable REST API, or via the SDK.

Running the workflow requires an executionId. This is used to ensure that the same request is always processed the same way, and to allow the control plane to resume from the last state in case of failures or interruptions.

The executionId is a string that you generate yourself. It can be any string, but it’s recommended to use a UUID or a hash of the request.

Let’s run a few scenarios:

​
Things to Note

You didn’t have to explitly attach the tools

  • You can attach tools to an agent by using the agent.tools property, but you don’t have to.
  • At each decision point, the agents does a context-aware tools search, and uses the tools that are most relevant to the current context.

Refund agent had to execute multiple tools in multiple steps to get the result

  • An agent can call multiple tools in multiple steps to get the result.
  • Each agent is an autonomous process that can reason and act while managing internal state.

Agent conformed to the resultSchema when returning results

  • The agent conforms to the resultSchema when returning results.
  • If the agent returns a result that doesn’t conform to the resultSchema, Inferable will ask the agent to “self-correct”.

Calling the same workflows with the same executionId gives you the same result

  • Workflows are durable, and distributed.
  • Calling the same workflow with the same executionId will always give you the same result.

Tools and workflows run on the machine that they are registered on

  • Tools and workflows run on the machine that they are registered on.
  • This means that the control plane only sees what you’ve explicitly exposed via tool results, and no runtime information from the tools.

Was this page helpful?

Suggest edits
Quick StartCore Concepts