Reference

Two different things that both make an agent more capable, and they answer different questions.

An agent's tools answer what may this agent do? 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 set of instructions the agent pulls in when relevant, like a runbook.

Tools are capability. Skills are technique.

Tools: the list of what it may do

Triage needs to read tickets, add a label, and post to one Slack channel. That's three actions, and that's its tool grant. Scout needs to read a few things and nothing else, so its grant is smaller still.

The grant lives on the agent. There is no container in between to create, name, and keep in sync — which matters the moment two agents need different tools, because with a shared container you would have to fork it.

Keep it short. This is the advice everyone ignores and then wonders why the agent picks the wrong tool. Four actions and the choice is obvious. Forty and it's a guess. A short grant also makes each turn cheaper, since the list of tools goes to the model every time.

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 platform: gmail keeps meaning "every Gmail action" as new ones are added. That is the point, and also the reason to reach for one only when the role really needs the whole family. "Read all of GitHub" is rarely what you meant.

A tool grant is not a security boundary

Worth being precise about, because it looks like one.

The grant says what the job needs. The role says what is actually permitted. Both apply, and the stricter one wins. An agent granted an action its role forbids simply cannot call it.

Which gives you two useful dials. Change the tools when you're shaping what the agent is for. Change the role when you're deciding what it's allowed to reach.

Which account a tool acts through

Granting gmail.message.send says the agent may send mail. It does not say from which mailbox, and that is a separate question with its own answer.

An agent reaches, in order: its own connections, then the connections your organization shares. Its own come first on purpose — a shared support agent with its own mailbox has to behave the same for everybody, not send as whoever happened to message it last.

Your own connections are not in that list by default. If you want an agent to act through your account — replying from your address, reading your calendar — you turn that on for that provider on the agent's page, and its page then says "acts through your Gmail" so anybody looking can see it.

When there is more than one account it could use, the agent is asked which one each time, by the name you gave the connection. If that question does not belong in the conversation — the agent should always send from one address — pin that connection on the agent and it stops being asked.

Two accounts of a keyed service, like two Firecrawl keys, are a different case: nothing in a request says which key is meant, so those tools are withheld until you pin one. The agent's tool list will tell you that is why.

Skills: instructions for a kind of task

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

Things Northwind IT keeps as skills:

• How to write up an incident so a client can read it.
• The offboarding checklist, in order, with the bits people forget.
• 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 tools used for that task. It can't hand the agent something it wasn't granted.

Sharing skills across teams

Skills are organization-wide: written once and available to every agent.

Being available isn't the same as being assigned. Somebody still has to give an agent the skill. When an admin edits a skill, every agent using it picks up the change on its next turn.

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 agent's grant, its role, whether the provider is connected, 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 agent, then edit Tools and Skills from Configure.

Skills are one organization-wide list under Build > Skills.

From the terminal:

mobius skills list

Start with the smallest set that can finish one real task. Run it. Look at which tools the agent 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 agent definitions.
• See what an agent can be granted: actions.
• Set the hard boundary with roles.
• Share structured data through tables.