Skip to main content

Build a Custom AI Employee

IntermediateLabHire your first AI Employee · Step 5 of 7
Estimated time · about 18 minutes|Required · Partner Center access on a Professional plan or higher, A simple API to test against, or dummyjson.com's free public order-lookup endpoint, used as the example in this step

Outcomes

Start a custom AI Employee from an outcome statement, not a feature list
Write a role and connect the knowledge and capabilities that outcome needs
Set an autonomy level that matches how much you trust the role on day one
Add one custom capability with a simple tool
Test against a pass/fail script before calling it done

Start from the outcome

By the end of this step, a custom AI Employee built for one outcome you chose is live, answering from its own knowledge and capable of one real action through a tool you configured. You are here: Partner Center, on a Professional plan or higher.

Every employee so far came pre-built. This one starts blank, so the first decision is the outcome, not the employee: "qualify inbound leads before booking" is a real brief, "build a sales bot" is not. Building one costs nothing extra, and there is no limit on how many you create, so the only real constraint is a clear outcome. If the outcome resembles a data analyst, an inside sales representative, or a support role, the custom AI employee guide has a worked example close to it, worth stealing from rather than starting from nothing.

Try it now

Write your outcome in one sentence before you open the configuration panel: what this employee does, and for whom.

Create the employee

Labcreate the employee and its profile

You are going to AIAI WorkforceCreate.

The employee now exists in your AI Workforce roster, with a profile and an autonomy level set.

Give it knowledge and capabilities

Labconnect knowledge and turn on capabilities

You are staying on the employee's Configure panel.

The employee can now answer from real knowledge and take the actions its outcome needs, using only built-in pieces.

Add one custom capability

Most outcomes need one more thing a built-in capability does not cover: a real action in another system, a price check, an order status, an inventory count. Knowledge only answers from what has been uploaded to it, so an outcome that depends on live information hits a ceiling fast without a live connection. That connection becomes a tool, added inside a custom capability.

This step uses a real, working endpoint so you are testing against an actual response, not a hypothetical one: dummyjson.com, a free public test API that needs no authentication. Its /carts endpoint stands in for an order-lookup system. Give it an order number from 1 to 50 and it returns that order's total, its discounted total, how many products and total items it contains, and the products themselves (name, quantity, and line total for each). It is not a real Vendasta or client order system — it exists so the tool you configure here behaves exactly like the one you would later point at a client's real order API, with a live response to check your work against instead of guessing whether the capability is wired up correctly.

Labadd a capability with a tool

You are going to CapabilitiesCustom CapabilitiesAdd a capability.

The tool now appears on the capability, ready for the AI to call once its instructions say when.

Path parameters, query parameters, headers, and every field in detail: Creating Custom Capabilities walks through the rest.

Write the capability's instructions

Brief the capability the way you would brief a new hire's one task: exactly when to use it, what it needs before it can act, and how to talk about what comes back. "Only call this when the customer asks about an existing order, and get the order number first" holds up in every conversation; "help with orders when it makes sense" does not.

Test before you call it done

Labrun the pass/fail script

You are on the employee's Try it page, or its assigned channel.

Three questions, three different situations, and the employee handled all three the way its outcome intended.

Where this stops, for now

One tool answering one outcome is a complete employee. Chaining several tools together, or connecting through middleware, is a deeper build for a job that genuinely needs it; the Tools & Integrations Overview is where to go next when that day comes.

What you now have

  • A custom AI Employee built around one outcome you named, not a feature list
  • A role, an autonomy level, knowledge, and capabilities, all set from a blank start
  • One custom capability with a working tool, briefed like a new hire's task
  • A pass/fail test result you can trust before anyone else talks to it

Knowledge Check

Three quick questions on starting from an outcome, sorting knowledge from tools, and testing a new capability.