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.

  mkdir inferable-demo
  cd inferable-demo
  # We're creating an ephemeral cluster that will be deleted after 1 hour.
  curl -XPOST https://api.inferable.ai/ephemeral-setup > cluster.json
2

Install the SDK

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

# inside the inferable-demo directory
npm init -y
npm install inferable tsx
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.
import { Inferable } from "inferable";

const inferable = new Inferable({
  apiSecret: require('./cluster.json').apiKey,
});

const getAllData = async () => {
  const data = await fetch(`https://go.inferable.ai/mockdb.json`)
  const { customers, orders, products } = await data.json()
  return { customers, orders, products }
}

inferable.tools.register({
  name: "listAllCustomers",
  func: async () => {
    const data = await fetch(`https://go.inferable.ai/mockdb.json`)
    const { customers } = await data.json()
    return customers
  }
})

inferable.tools.register({
  name: "getAllData",
  func: async (input) => {
    const data = await getAllData();

    const customer = data.customers
      .find((customer) => customer.id === input.customerId)

    const orders = data.orders
      .filter((order) => order.customerId === input.customerId)

    const products = data.products
      .filter((product) =>
        orders.some((order) => order.productId === product.id)
      )

    return {
      customer,
      orders,
      products
    }
  },
  schema: {
    input: z.object({
      customerId: z.string(),
    }),
  },
});

inferable.tools.register({
  name: "attemptRefund",
  func: async (input) => {
    const {customer, orders, products} = await getAllData(input)
    const order = orders.find((order) => order.id === input.orderId)

    if (order.status === "delivered") {
      // You can throw errors from the tools normally.
      // Inferable will serialize the error and return it to the agent.
      throw new Error("Order already delivered. Refund not possible.")
    }

    return {
      success: true,
      message: "Refund successful"
    }
  },
});

inferable.tools.listen();
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.

import { Inferable, helpers } from "inferable";

const inferable = new Inferable({
  apiSecret: require('./cluster.json').apiKey,
});

const workflow = inferable.workflows.create({
  name: "customerSupport",
  inputSchema: z.object({
    executionId: z.string(), // this is mandatory, and works like an idempotency key
    from: z.string().describe("The email address of the customer"),
    message: z.string().describe("The customer's message for support"),
  }),
});

workflow.version(1).define(async (ctx, input) => {
  const triagingAgent = ctx.agent({
    name: "triagingAgent",
    systemPrompt: helpers.structuredPrompt({
      facts: [
        "You are given a customer support request"
      ],
      goals: [
        "Triage the request to the appropriate case type",
        "If it pertains to a customer in the system, return the customerId"
      ]
    }),
    resultSchema: z.object({
      caseType: z.enum(["refund", "other"]),
      customerId: z.string().optional(),
    }),
  })

  const triaged = await triagingAgent.trigger()({
    data: {
      request: input.request,
    }
  });

  if (triaged.result.caseType === "other") {
    console.log("Request not supported")
    return;
  }

  if (triaged.result.caseType === "refund") {
    const refundAgent = await ctx.agent({
      name: "refundAgent",
      systemPrompt: helpers.structuredPrompt({
        facts: [
          "You are given a customer support request",
        ],
        goals: [
          "Attempt to refund the order",
          "In case of failure, explain why and ask the customer to contact [email protected]"
        ]
      }),
      resultSchema: z.object({
        success: z.boolean(),
        messageToCustomer: z.string(),
      }),
    })

    const processed = await refundAgent.trigger()({
      data: {
        customerId: triaged.result.customerId,
        request: input.request,
      }
    })

    console.log(processed.result)
  }
});

// Listen for requests to the workflow
workflow.listen();

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:

# inside the inferable-demo directory
CLUSTER_ID=$(cat cluster.json | jq -r .id)
API_SECRET=$(cat cluster.json | jq -r .apiKey)

# This should trigger the workflow and print that the refund was rejected
curl -XPOST https://api.inferable.ai/clusters/$CLUSTER_ID/workflows/customerSupport/executions \
  -d '{"executionId": "123", "from": "[email protected]", "message": "I dislike the product. Please refund me"}' \
  -H "Authorization: Bearer $API_SECRET"

​
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