Book a call
All resources

Guide · 8 min read

Give each agent a job

One assistant that does everything is a generalist you cannot criticise. Several teammates with jobs are colleagues you can. A workspace can have as many AI teammates as it needs, and the difference between them is not a label - it is what they are told, what they may touch, and what they run on.

An admin adds and edits them in Settings → Agents. Here is what is worth setting, and why.

The brief is most of it

Each agent gets a name, a brief and a model. The brief goes into that agent’s instructions, so it is where a researcher becomes a researcher. @-mention the one you want and that specific agent answers.

Write briefs the way you would write the first week of someone’s job: what they own, what good looks like, what they should refuse. A brief that says “be helpful and concise” produces the same teammate you already had under a different name.

Three that earn their place on most teams:

A reviewer Argues, commits to a call, cites.
A researcher Searches the web. Read-only.
A triager Terse. Lives on the board.
  • A reviewer. Reads what is proposed and argues with it. Set it to push back hard, to commit to a call rather than hedge, and to cite where a claim came from.
  • A researcher. May search the web, writes prose rather than bullets, and is read-only - it can look things up and answer, and has no tools that create, edit or post.
  • A triager. Terse, no emoji, always ends with next steps. Lives on the board and does the tidying nobody volunteers for.

The settings that make one feel like a different person

Beyond the brief, an admin picks how an agent answers: length, whether it thinks before replying (faster and cheaper, or slower and deeper), tone, how hard it pushes back, prose or bullets, whether it hedges or commits, whether it must cite, whether it uses emoji.

And what it does on its own: how readily it speaks up in chat without being mentioned, whether it may search the web, and whether it may change anything at all. An agent set to read-only will say so when asked to make a change rather than quietly failing. An admin can also narrow which built-in tools a particular agent gets - so a research agent does not carry the ability to move tickets.

A researcher: thorough, thinks first, writes prose, cites - and cannot change anything.

One agent is the workspace’s primary one: it is what answers ⌘O voice, writes huddle summaries, runs the conflict checks, and runs any routine that names no teammate of its own. Pick it deliberately - its tone is the workspace’s ambient tone.

Models: pick where the work happens

There is no team-wide model setting to get right, and that is on purpose. An admin pins an agent to its own model when editing it; whoever starts a coding run or an app turn picks the model for that run. Each picker offers the whole catalog - hundreds of models across every major maker, read live from the gateway, so a model released today is in the picker today and nobody updates anything.

Two things worth setting once. A fallback model per agent, which it uses only while its first choice is unavailable - a provider outage, or that one model being throttled. Ordinary errors are never retried on it. Without one, an agent simply says the provider is down until it is back.

And, if your team needs it, the ZDR filter. Models marked ZDR route only to zero-data-retention endpoints - the provider does not store what is sent - and that routing is enforced on every request rather than assumed: if no ZDR capacity is available, the request fails instead of quietly using an endpoint that retains. Our own built-in AI runs on ZDR-routed models. Customer content is never used to train models on any of them.

Skills: the instructions your team already writes

A skill is a plain SKILL.md file in your GitHub repo, under .claude/skills/<name>/ or .wemachines/skills/<name>/ - both are synced, so a team already keeping skills where Claude Code reads them keeps one directory rather than two. An admin syncs them in from Settings → Agents and switches each on.

The mechanism is the good part: an agent is shown only the one-line description of each skill and loads the full text when it judges it relevant. A shelf of thirty skills costs almost nothing until one is actually used. Skills are text, never code - nothing about a skill runs or reaches the network.

An agent sees the grey line. It opens the file when the line looks relevant.

This is how a team’s standards stop being folklore. “How we write commit messages”, “what our review actually checks”, “the way we name migrations” - written once, in the repo, under version control, read by every agent that needs them. Including the ones in your engineers’ terminals.

Tools from outside

An agent can be connected to an MCP server, which gives it tools from another system - a tracker, a docs tool, anything that speaks MCP. An admin adds it while editing that agent: a name, the server’s address, and a credential if it needs one, stored encrypted and referenced by name rather than pasted.

WeMachines connects at that moment and pins the exact list of tools the server offers. The agent is only ever offered that approved list, and if the server later changes what it offers, the agent keeps the approved set until an admin reviews it. Every call runs on our servers, so the credential never lands in a browser or on a laptop - including for somebody working in their editor as that teammate. It comes with every plan, the trial included.

Note the direction. This is WeMachines reaching out to someone else’s MCP server. Settings → Multiplayer is the opposite: outside AI clients reaching into your workspace. See Connect your repo.

What agents read of each other

By default an agent sees the whole team chat, its own earlier messages and every other agent’s included - which is what stops two agents answering the same question twice or contradicting each other an hour apart.

It is also, on a busy workspace, most of what the AI’s reading costs, because agents get asked for long answers and every one of those is re-read on every later run. An admin can take AI-written messages out of that in Settings → Context. Two things it never changes: an agent answering in a thread always sees the whole thread, and an agent that needs the wider room can still go and read recent chat itself. Spend credits well weighs that one up properly.