Tools and skills

An assistant's tools answer what may it call? It's a list of actions: read a ticket, post to Slack, look up a calendar.

A skill answers how should it handle this kind of task? It's a reusable set of instructions the assistant pulls in when relevant, like a runbook for writing the weekly operations brief.

Tools: the list of what it may do

Scout reads a shared spreadsheet and posts a brief to Slack. Its tool list needs the Sheets read action and one Slack posting action. Add another action when a real step needs it, because every tool name and schema goes to the model on each turn and gives it another possible call to consider.

Action selectors live on the assistant. Two assistants can use different slices of the same provider while selecting only the actions each one needs.

Selecting more than one action at a time

You can name actions one at a time, or select a family:

Family selectors are expanded fresh on every turn, so provider: gmail keeps meaning "every Gmail action" as new ones are added. That is the point, and also the reason to use one only when the role needs the whole family.

Tools work inside harder access controls

The tool list says what the job needs. The role says what is permitted. Connected accounts add a third check: the assistant needs an explicit grant to the exact account behind the action. Every check applies.

Change the tools when you're shaping what the assistant is for. Change the role when you're deciding what it may do across Mobius. Change account access when you're deciding which external identity it may act through and which Mobius conversation or routine audiences may retain the tool result. An account grant does not restrict an external recipient or channel named in the action.

Which account a tool acts through

Selecting gmail.message.send says the assistant may send mail. It does not say which mailbox it may use. The person or team that manages a connected account must grant that exact account to the assistant as a separate step.

When several granted accounts are available, a tool can take the account name for that call. Open the assistant's Accounts card and choose Account preferences when one account should be the usual choice for Your chats or for Channel replies. A preference chooses among existing grants; it cannot create access.

Routines save their own exact accounts. They do not inherit chat or channel preferences. If several accounts remain possible and nothing selects one, Mobius asks for a choice or withholds a capability that cannot name an account. It never guesses from the first connected account.

Read Connect accounts for account managers, result audiences, and the complete access flow.

Skills: instructions for a kind of task

A skill is reusable guidance for work that shows up in more than one place.

Northwind keeps skills for work such as:

• How to write up an incident so a client can read it.
• The offboarding checklist, including account removal and ownership transfer.
• How to phrase a "we can't reproduce this" reply without sounding dismissive.
• How to format a monthly report so it matches the last eleven.

The point of a skill is that it's specific enough to be worth loading only sometimes. Standing instructions describe the enduring job. Skills describe how to handle a particular kind of task when it comes up.

A skill can narrow the actions used for that task. It cannot select an action the assistant has not already selected. Required actions make the skill unavailable when they are missing; recommended actions produce guidance only.

Share a skill deliberately

A skill can belong to one person, be shared by that person, or belong to the team. Sharing makes its instructions available to its chosen audience; it does not assign the skill to every assistant.

The skill must be visible to every person who can use the assistant. A private skill can be assigned only to a private assistant for its owner. This prevents a shared assistant from exposing instructions that one colleague cannot read.

After an authorized person edits a skill, assistants assigned to it load the new instructions on their next turn. Existing transcripts keep the work that already happened, so you can compare the result before and after the change.

How this fits with everything else

The tool manifest is the one to look at when an action you expected isn't there. It's the result of combining the assistant's action selectors, its role, the available account access, and any narrowing for that session. You don't manage it directly; you read it when something's missing.

In the app

Open Build > Agents, pick an assistant, then use the Tools and Skills cards on its Configure tab. This is where you choose an assistant's actions, whichever provider they came from. Connecting a service from a conversation gives an assistant without that service's actions all of them at once. Narrow them from the action count on the service's card in the conversation, where they're grouped into read and write, or here.

Open Build > Skills to see the skills available to you. Whether you can read, edit, share, or assign one depends on its owner, audience, and your role.

From the terminal:

mobius skills list

Start with the smallest set that can finish one real task. Run it. Look at which tools the assistant actually used. Add something only when a missing action blocked real work.

Some shapes that work:

Exact fields are in the interactive API reference. Terminal use is in the CLI command reference.

Next

• Write the standing job description in assistant definitions.
• See what an assistant can select in actions.
• Connect and grant an exact account through Connect accounts.
• Set the hard boundary with roles.
• Share structured data through tables.