Wetel
Go back

Hiring a ready-made role instead of building an AI employee from scratch

There are two ways to fill a job. You can write the job ad yourself: decide what the role does, who it answers to, what it needs to know and which systems it may touch, then interview until someone fits. Or you can go to an agency that already has the job description written, tested on other teams, and a candidate ready to start once you hand over a desk and a login.

The agency route is faster, but it does not remove the manager. Someone still decides to hire, gives the new person access to the right systems, and watches the first weeks.

Wetel offers both routes for AI employees. Building one means writing the persona and the workflow yourself. Hiring a role means starting from a template Wetel has already written. This post explains the second route as it works today, for the department head deciding whether to hire and the technical lead who finishes the setup.

The short answer: a hire is a working copy in your workspace, owned by you

Hiring a role creates a new agent in your workspace from a ready-made template: its persona, its conversation flow (a workflow), its knowledge bases and the connections it needs. In one step Wetel creates the agent, its workflow, its knowledge bases, and a connection for every setup step you already supplied a credential for. If every required step is done, the agent is published and active. If not, you get a setup checklist, and the agent takes no traffic until you finish it.

Two people stay in charge throughout. A workspace owner hires the role, and the same owner (or the team they delegate to) supervises what it does afterwards. A template is a starting point, not a hand-off.

What is inside a role template

A role template is the job description and the starter kit together. The roadmap describes it as a ready-made AI role: a persona, a conversation flow, and the knowledge bases and connections it needs. Examples in the docs include an operations coordinator and a knowledge officer.

When you look at the roles you can hire, you see enough to decide and to fill in the hire, and no more:

The listing never contains the role’s workflow or prompts. You decide on the job description, not on the internal wiring. Once hired, though, the agent and its workflow live in your workspace like any other agent (more on that below).

Who can hire, and what you will see today

Only a workspace owner can hire a role, and today only on a PRO plan. The list of roles tells you whether your plan allows it (canHire), and if not, why (cannotHireReason). Being the owner, and your limits, are checked at the moment you hire.

The documented limits are 10 hired roles at once and 5 hires per 24 hours per workspace.

The more important point for planning: nothing appears in that list until Wetel lists a role. The gallery starts empty, and a role shows up only when Wetel has made it available. So today, hiring a role yourself is available by invitation. A role that is not listed, does not exist, or is not available to you all give the same answer (Template "<key>" not found), so the list does not leak what else might exist.

Separately, Wetel can still set up a role in your workspace for you, as a guided pilot. Those agents arrive with the same setup checklist.

How a hire works, step by step

A hire moves through three stages: choose, hire, then finish whatever needs your own credentials.

flowchart TD
  G["Owner reviews the listed roles"] --> H["Owner hires one:<br/>parameters, plus any credentials<br/>already to hand"]
  H --> Q{"Every required<br/>setup step done?"}
  Q -- yes --> L["Agent published and active"]
  Q -- no --> C["Setup checklist:<br/>agent stays off"]
  C --> F["Give a credential, or create<br/>the connection yourself and bind it"]
  F --> Q

For the technical lead, the hire itself is one call, hireAgentTemplate, made with the owner’s sign-in. The docs’ example variables:

{
  "input": {
    "templateKey": "ai-operations-coordinator",
    "idempotencyKey": "wizard-2026-10-05-a1b2c3",
    "parameters": { "company": "Acme" },
    "slotCredentials": [
      { "slotKey": "action_track_a_parcel", "bearerToken": "<your token>" }
    ]
  }
}

Three details are worth knowing before you build a screen around it:

The setup checklist, and why the agent stays off until it is done

Anything that needs your own credential is left as a setup step (a “slot”) for you to fill, and until every required one is filled the agent stays off. Think of the agency candidate who has arrived but has no login yet: they are in the building, but they are not answering customers.

The checklist, agentTemplateInstall, lists each slot with its status, whether it is required, and for each one still waiting, what to create and how its credential must be provided. Some slots need nothing from you at all: a slot that has no credential, or that acts as the signed-in end user, is already bound for you.

There are two documented ways to finish a waiting slot:

  1. Give the credential. With provideAgentTemplateSlotCredential, the owner hands over the token for that slot, and Wetel creates the connection in your workspace from the slot’s definition, stores the credential and binds it.
  2. Create the connection yourself and bind it. You create a custom action or a connector to your own tool server with the usual operations, then attach it with bindAgentTemplateSlot.

Binding is checked, not trusted. A slot that expects a token refuses a custom action that carries no credential, because every call would be rejected. A slot that uses your tool server refuses a connector that does not expose every tool the workflow calls. Binding the same resource twice is harmless; binding a different one to a slot that is already set up is refused as a conflict.

When the last required slot is bound, the workflow is published and the agent becomes active. If publishing fails, the checklist says why (publishError) and the agent stays off.

While it is off, it really is off. An agent still being set up refuses sdkStart with a Forbidden error that says it is still being set up, and connecting a messaging channel to it is refused the same way. Agents you built yourself are never affected by this rule.

Why your credentials are write-only

A credential you give for a hired role is stored under your workspace and never returned, logged or shown again. The checklist itself contains no credential and no template content. If you want to keep the credential entirely in your own hands, the second route above lets you create the connection yourself and only tell Wetel which one to use.

For the department head, this means the relationship with your suppliers and systems stays yours: the role brings the know-how, and you decide which account it uses. If something fails after a credential was stored, the response says so, and you can bind the created resource by its id rather than handing the token over a second time.

After the hire: a starting copy you supervise

A hired role is a starting copy, not a subscription that keeps changing underneath you. Your hire gets the version of the template that was current when you hired it. Moving an existing hire to a newer version of its template is not built, so a hired agent does not change on its own when the template is later improved.

What arrives is an ordinary agent, workflow and set of knowledge bases in your workspace. The roadmap notes that the create, update and publish flow underneath does not change, so the people who supervise it review and adjust it the same way they would an agent they built themselves. A few things worth deciding in the first weeks:

Hire or build: how to choose

Hire when a listed role is close to the job you need; build when the job is specific to how your business works. Hiring saves you writing the conversation flow and working out which connections the role needs. Building gives you full control from the first line, which is the better choice for a process nobody else runs quite like you do.

Either way you end up with an agent in your workspace, running a workflow, supervised by your people. Our post on tools, workflows, skills and agents covers how those pieces fit.

What is live today and what is not

Live today: Wetel setting up a role in your workspace for you with a setup checklist; workspace owners on a PRO plan hiring a listed role themselves, within the limits above; finishing a setup step by giving its credential or by binding a connection you created; and an agent that stays off until its required setup is finished. The changelog records when each piece arrived.

Not built yet: moving an existing hire to a newer version of its template, and a wider catalogue of roles. Until Wetel lists a role, the list of roles you can hire is empty, so today this is by invitation.

If there is a role you would rather hire than write from scratch, tell us which work you’d hand over first.

Share this post:
Share this post on Whatsapp Share this post on X Share this post on Linkedin Share this post via email
Next Post
Screening job applicants with an AI employee: what it does, step by step, and where people decide
Previous Post
An AI employee that starts on its own: scheduled work, and what stops it running away