Skip to Content
DocsConceptsRoles: hiring a worker

Roles: hiring a worker

A role is a persona a contact wears for a whole conversation: who the agent is, not what it can do. Assigning a role to a machine you have joined is how you hire a worker — a mail assistant, a technical writer, a code reviewer — and it stays assigned across every conversation with that contact until you change it.

A role is not a Skill

The two are easy to confuse and opposite in shape:

  • A role is never invoked. It is always in force — every turn is run with that persona active.
  • A Skill is invoked for a specific task and returns.

A worker’s role does not change what tools or Skills it can use; it changes who it is while it uses them.

Hiring and reassigning

Two ways to give a machine a role:

  • When you add it. Pick a role while creating a new agent, and the contact starts already wearing that persona.
  • On an existing contact. Reassign the role from the machine’s roster entry at any time. A failed install leaves the previous persona in place rather than an unresolved slug.

Hiring is not limited to one worker per machine. A machine that already has a role assigned can take on a second, independently-configured agent identity — its own engine lane — and you hire that one separately, with its own role, its own conversation history, and its own address.

The assignment belongs to the correspondent you are talking to, so it survives starting a new conversation with the same contact. A correspondent is usually a machine’s one agent — but a machine can host more than one agent identity on the same engine (see Engine lanes), and each of those is its own correspondent with its own role. Reassigning a role on one lane never touches another lane on the same machine.

Changing a worker’s role never moves the contact. A role is not part of what identifies a correspondent, so open panes, bookmarks, and unread state all survive a role swap exactly as they survive a rename — reassigning a role is never a reason to lose history.

Where roles come from

Cmdop ships a public catalogue of roles you can browse and assign from the console. You can also write your own role as a file on the machine that runs the agent, for a persona specific to your business; there is no in-browser role builder, so a custom role is authored on the machine, not through a web form.

What a role does not do

A role is a persona, not a sandbox. It changes tone, focus, and default behavior; it does not add or remove permissions, and it does not confine what the worker can do to a restricted set of actions. Anything a role’s description implies it needs — access to mail, to a client base — should be read as what the role does with the permissions and tools already available to that machine, not as an isolation guarantee.

A role that cannot resolve — for example, its file was removed on the machine after it was assigned — never breaks the conversation. The turn continues without a persona rather than failing, so a broken role reads as the agent answering more plainly, not as an error.

Common questions

What is a role in Cmdop?

A role is a persona a machine’s contact wears for a whole conversation — who the agent is. Assigning one is how you hire a worker.

How is a role different from a Skill?

A role is never invoked and stays in force for every turn. A Skill is invoked for one task and returns. A worker’s role does not change which Skills or tools it can use.

Can I write my own role?

Yes. A custom role is a file you write on the machine that runs the agent, not something built through a web form.

Does a role restrict what the worker can do?

No. A role changes persona, not permissions. What a worker can act on is governed separately by the machine’s permissions.

Last updated on