Skip to content

Workers · Custom

Custom AI workers: describe the job, deploy the worker

Need a renewals manager, a partner liaison or an inbound qualifier? Write the role in plain words, pick its triggers and tools, set what needs review. It is stored and runs exactly like Taylor and Parker: same memory, same cards, same evidence.

Your workerAny role you describe · worker
Runs like the defaultsBuild a custom worker

A custom AI worker in Heliyos is a role you define without code. You give it a name and a job description, choose the events, schedule or mentions that start it, allow the tools it may use, and decide which of its actions wait for review. From then on it runs on the OS with the same memory, model profile and result contract as the default workers, appears as an assignee next to Taylor and Parker, and reports every run with evidence. Custom workers are how a revenue team covers the jobs no vendor template anticipated.

The job

What starts it, what it may use, what waits for you

Starts when

  • Events you pick: emails, meetings, tasks, record changes, signals
  • A schedule: daily, weekly, or a cron you set
  • Someone mentions the worker by name

Can use

  • Any subset of the platform tools: records, tasks, notes, email, calendar, search, documents
  • Your knowledge base
  • Integrations the workspace has connected

Needs review

  • Whatever you decide, per action
  • Outbound email, on by default
  • Anything that changes a deal

Use cases

Use cases

  • A renewals manager, ninety days out

    "Ninety days before a renewal, check usage, draft the renewal note and brief the account owner." That sentence is the worker.

  • An inbound qualifier on Typeform responses

    Trigger on a new response, enrich the company, score fit against your ICP, and create a task for the right rep or for Taylor.

  • A partner liaison that may read but not send

    Allow records, notes and tasks; leave email off the tool list. The worker cannot do what its job does not list.

  • Same memory as Taylor and Parker

    A custom worker reads the same account memory and writes back with evidence, so the defaults see its work and it sees theirs.

  • It hands work to the defaults

    A custom worker can create a task for Taylor or leave a record change for Parker, the way a new colleague works with the team.

A day with the worker

Every step shows its evidence

Sun marks the step running right now. Finished steps go quiet. Anything important waits for a person.

  1. Mon 08:00
    Scheduled run: renewals due in 90 daysTrigger: weekly schedule · 4 accounts matched
    Done
  2. 08:02
    Checked usage and open threads on each accountUsage from the integration · last touch from the inbox
    Done
  3. 08:05
    Drafted a renewal note on Namora and created a task for the ownerTask "Prepare Namora renewal" assigned to Soham · due in 10 days
    Done
  4. 08:06
    Renewal email draft waits for approvalRule: outbound email needs review
    Needs review

Trust grows in steps

Hand off more over time

  1. 01

    Name the role

    Who it is, what it owns, in two sentences.

  2. 02

    Pick triggers and tools

    Events, a schedule or a mention. Only the tools the job needs.

  3. 03

    Set what needs review

    Start with everything reviewed. Hand off more as trust grows.

  4. 04

    Deploy

    It appears in the roster and in the assignee picker. Watch the first runs in Reviews.

Review ladder

Start with everything reviewed

  1. 01

    Review everything

    Every action waits. You learn how the worker reads its brief.

  2. 02

    Review outputs only

    Record updates run; emails, documents and tasks assigned to people still wait.

  3. 03

    Autonomous within scope

    The worker runs its job without a stop. Scope and evidence stay fixed.

Workers work together

A team, with handoffs.

Workers are not isolated bots. They hand work to each other, stop and hand it to a person when it matters, and share one memory and one knowledge base, so the work moves without anyone re-explaining the account.

Parker's avatar Parkerread the QBR transcript and created the taskTaylor's avatar Taylorwrote the proposal and the cover emailNeeds review · Sohamapproves, and it sends

  • Workers hand work to each other

    Parker reads a meeting and creates the follow-up task; Taylor picks it up, does the work and reports back what Parker should change on the account. The handoff is visible in the thread: "Parker handed off to Taylor".

  • Workers hand work to a person

    When an action matches a review rule, or a worker is unsure, it stops and hands the decision to the account owner in Reviews, with the evidence and its open questions. A person approves, edits or answers, and the run continues.

  • They share one memory and one knowledge base

    Every worker reads the same account memory and the same organisation knowledge: your pricing, docs, custom fields and files. What one worker learns on an account, the next one knows.

  • You can talk to them, and they talk to each other

    Mention @Taylor or @Parker in chat or on a task and they reply with what they did and why. On a task, workers talk among themselves to split the steps, and the conversation stays on the task for you to read.

FAQ

Questions people ask

Do I need to write code to build a custom AI worker?
No. A custom worker is a role description, a trigger list, a tool list and a review rule, all set in the app.
Which model does a custom worker use?
The same model profile as the default workers, so behaviour, cost and quality are consistent across the roster.
Can a custom worker call Taylor or Parker?
It can create tasks for Taylor and hand record changes to Parker, the same way a person does.
How many custom workers can I have?
As many as your plan allows. Each one shows its runs and usage in the app.

Describe the job. Deploy it today.

Closed beta, usage-based pricing, no seats. Join the waitlist and we review your request.

Closed beta. We review every request and reply by email.