Agent

New agent takes a name, role line, provider, model, max turns and identity text, creates the agent, and opens its screen to connect Slack.

e.g. a name this tenant already uses → refused, nothing created.

An agent's name, role line, Slack app suffix, inference, default model, max turns, identity text and enabled are edited in the Hub. Nothing else about it can be changed.

After a save, the agent's screen shows what was saved, every field, without a reload.

e.g. Codex, model Sol → Terra, Save → Terra stays selected; the same for the name, role line, max turns and identity.

e.g. Claude → Codex, Save → Codex stays selected, its models are listed, and the header says Codex.

Saving an agent with no model is refused and nothing is written.

Unticking "Agent enabled" and saving disables the agent.

A Slack app suffix is one short word of letters, digits or dashes, or nothing.

e.g. has spaces! → refused, the agent unchanged.

Renaming an agent, or changing its suffix, renames its Slack app. The rename is saved here either way, and what Slack said is shown beside it.

A member sees the agent screen with every control disabled and the reason stated; a submission from them is refused (MEMBER-WHO-MAY-CHANGE).

Another tenant's agent reads as "no such agent", on reads and on writes.

Every agent has one manager: a person of its own tenant who has not left, another agent of its tenant (ORG-CHAIN-ENDS-IN-A-PERSON), or the organization itself (ORG-UNDER-THE-ORGANIZATION). An agent is never without one: one made with no manager named sits under the organization, waiting to be confirmed; a person or agent of another tenant, or someone who left, is refused, and so is a loop (ORG-NO-LOOP). It is changed on the agent's page and on its profile.

e.g. New agent named under a person of another tenant → refused, nothing created.

Whoever creates an agent is its manager unless they pick someone else; the manager can be changed later by anyone who may change the agent (ORG-MANAGER-MANAGES).

The Agents screen shows a card per agent — name, role line, login badge, the provider it thinks with, its model, its state, and its tools — and the card opens it.

An agent thinks with one provider, and the card, the agent's screen, the API and the worker all say the same one. How the worker launches it is not shown to people.

e.g. Lumen on Codex → the card, the screen header and the Inference box all say Codex; none says Claude Code.

Every field on an agent's card reads exactly as on its screen: provider, the model by its name, state and login badge.

e.g. model sol → "GPT-5.6 Sol" on both, never the raw id.

The card and the screen show one state, the first that holds: Disabled (switched off) → Not wired yet (no Slack app, or not installed) → Slack off (its binding switched off) → Serving. It is what is configured; whether the worker is reachable is not claimed. The signed-in tally is counted separately (AGENT-FLEET-TALLY).

e.g. enabled, installed, binding off → "Slack off", not "Active". Disabled but signed in → "Disabled", and still counted as signed in.

The Agents screen counts how many agents are signed in: a shared agent when its login works, a per-person agent when at least one person is signed in (INFER-HONEST-BADGE).

The roster is the worker's whole view of an agent: its identity and inference, its channel, the people it knows, its tools, connections and skills, and its tenant's mission and timezone. What is not on it, the agent does not have.

An agent is served once it is enabled and its Slack channel works; a new agent starts answering on the first reload after that.

A save reaches the running agent in about a second, without a restart, and agents that did not change keep their connections.

e.g. change the default model → the next turn uses it.

A roster that arrives empty, or short by more than half a fleet, is ignored and the agents keep serving.

An agent is given its identity text exactly as written, refreshed on every reload.

Renaming an agent changes only what it calls itself: its login, its sessions and its conversation history stay.

A worker serves every agent on the roster, or only the agents it is named, and says which it is leaving alone. One agent is never given to two workers.

An agent can be set to local mode: it is placed on the person's own pool (worker-pool.md), the Hub shows the one command that brings it online, and everything else about it — its Slack app, its skills, its brains, its people — is managed in the Hub exactly as for an agent in the Cloud. Switching either way is a handover: the Hub shows moving until the old pool has let go, and says that the model login must be connected again on the new one.

Every tenant sees the same catalogue of tools. An agent holds a tool by holding a skill that brings it; a tool asked for on its own is refused, naming the skills that bring it. An agent of another tenant is a 404 before anything is said about tools.

A removed tool is gone from the agent's next roster; removing one it never had succeeds and changes nothing. One a skill on the agent still brings is refused, naming the skill (TOOL-ADDED-BY-ITS-SKILL).

The Skills & tools tab lists the tools the agent holds, each with the skills that added it, or — once none does — a Remove button. Nothing is ticked: tools come with skills. A member sees the same, read only.

A tool states which credential kinds it accepts — calendar: ICS, Google or Outlook; Plaud: Plaud; site edit: website — or that it needs none because Tonoman or the provider supplies it (transcription, web search, web fetch). It is how a skill's needs meet the tenant's credentials (SKILL-BINDING-PER-TOOL). Design: features/tools-and-skills/design.md.

A tool takes one credential or several. Calendar takes several and reads them all, merged; Plaud and site edit take one. "Each person's own" on a several-tool is every credential of that kind the person holds; on a one-tool it is the one the person chose for that instance.

e.g. Cara holds a work and a personal calendar → both feed the recap bound to "each person's own".

A tool a skill brings says which skill copies added it, and cannot be removed while one of them is on the agent.

e.g. calendar on an agent with meeting-recap and agenda-brief → "added by agenda-brief, meeting-recap"; Remove is refused.

Removing a skill leaves the tools it brought on the agent, now removable; they go only when removed themselves.

e.g. web-fetch skill removed → web-fetch reads "no skill brings it now" with a Remove button; removed → gone from the next roster.

In a turn — whether a person typed the message or a job wrote it on their behalf — the tools a skill brings are tonoman commands, and a login or calendar is named by its label, the way people say it: "Work calendar", "Team Plaud"; "mine" is the person's own. A person may use their own and the shared ones a skill copy on the agent uses, never another person's own; a name that matches nothing is answered with the names that do.

e.g. "what's on my work calendar tomorrow?" → tonoman calendar find --calendars "Work calendar" …; --login "Ben's Plaud" as Ana → refused, listing "mine" and "Team Plaud".

Each tool on an agent is a copy with a keyword of its own: the first copy takes the tool's name (plaud), and later copies a number (plaud-2). A copy other than the first can be renamed; no two things on the agent share a keyword.

A second copy of a skill brings second copies of the tools it needs that take an account, numbered like the skill copy and set up like the first skill copy's: drop-watch-2 brings partnerhub-2. A tool that takes no account (web search) has nothing to differ by, so one copy serves every skill. Two different skills share a tool's first copy unless one is pointed at another copy, or at a new one, on its page.

e.g. meeting-recap and agenda-brief both use calendar; agenda-brief pointed at "a new copy" → calendar-2, set up like calendar, for agenda-brief alone.

A tool copy has one setting: whose account it uses. Each person's own — every person connects theirs, in a DM, with !connect <copy> — or one account for everyone, picked by its label from the shared accounts of a kind the tool takes (several, for a tool that reads several, like calendars). There is no choice of kind: it follows from what is connected. A person's own login is never listed as a shared option.

e.g. plaud-2, each person's own → Ana connects with !connect plaud-2, and plaud-2 reads that login, not the one she connected for plaud.

Whether a tool is connected is said for one person, on the People tab — never on the Skills tab, where "connected" would not say for whom. For the person chosen (the one looking, by default): each skill copy, each tool it brings, connected through which credential, or not.

A tool not connected for a person shows the exact words that connect it, to send the agent in a DM, with a button that copies them. The Hub never collects the login itself (CONN-CONNECT-IN-CHANNEL).

e.g. plaud, not connected for Ana → "DM Nova !connect plaud [copy]"; plaud-2 → "!connect plaud-2".

web-search is a tool: an agent searches the web only while it is granted — Claude through its web search, Codex through its live web search (CLI-WEB-ON-BOTH-PROVIDERS). Every agent that existed when it became a tool was granted it, so nobody lost it.

web-fetch is a tool: while it is granted, the turn has tonoman web fetch --url, which opens one page FROM THE WORKER the way a browser asks for it and returns its title, description and text — nothing saved. It opens only https addresses that resolve to the public internet: a private, loopback, link-local or cluster address is refused, checked on the address actually connected to, on every redirect. Granted to nobody by default.

e.g. a public LinkedIn profile → its name, headline and location (what LinkedIn shows a browser); https://temporal.prod-temporal.svc.cluster.local:7233 → refused, nothing sent.