Give each machine a job

One machine can do a lot. A few machines with clear jobs can do even more. A reviewer should push back on a plan, a researcher should dig up evidence, and a triager should keep the board tidy. Give each one a job, then tune it as you see what it makes.

Anyone on the team can add and edit machines on the Machines page: the robot in the dock, then Machines. Here’s what’s worth setting, and why.

Add a machine

Press Add new Machine on the Machines page, or the + next to Machines in chat, and pick Cloud or Local.

A cloud machine starts out blank and opens its own room. It asks what it should do for your team and offers a few answers, like an everyday assistant, a copywriter, a competitor scout or an engineer. Click one or describe the job in your own words, and it picks a name, writes its own instructions and says hello. Rather do it by hand? “Set it up yourself” opens its editor.

A local machine runs on the computer of whoever asks it, using their own coding agent from the Mac desktop app.

Write a clear brief

The brief is the machine’s instructions, and it’s where its personality lives. Say what the job is, what a good result looks like and any limits, like “suggest changes, never make them”. Then mention the machine you want by name in chat or a comment.

Three roles to start with:

• A reviewer. Reads what’s proposed and argues with it. Ask it to be blunt and to lead with the biggest problem.
• A researcher. Thinks hard, searches the web and names a source for every claim. Its brief says it reports and a person decides.
• A triager. Short and quick. Lives on the board and does the tidying nobody volunteers for.

Choose how it works

Effort is how hard it thinks, on a ruler from 0 to 25 in its settings. It’s on Auto until you move it. Higher means more careful answers, a little slower and a few more credits. You can also set effort for a single message, from Effort under the message box.

Speaks decides whether it only answers when asked, or can join in when the talk is in its lane. Voice is what it sounds like when you call it, with six to pick from. Images sets the model it draws with, or turns drawing off.

How long its answers are and its tone aren’t on the settings page. Just tell it: “keep your answers short from now on” or “be blunter”. It changes its own settings and sticks to them.

Pick a model for the job

There’s no team-wide model to get right, and that’s on purpose. You pin each machine to its own model when you edit it, and whoever starts a coding run or an app build picks the model right there. The list updates itself, so a model released today shows up today. Try a new one on a task you know well and compare the result, the speed and the credits before you switch.

No need to pick a backup either. If a provider is down or busy, WeMachines moves the machine to a strong model from another provider until its own is back.

Need zero data retention (ZDR)? Models marked ZDR only go to endpoints where the provider stores nothing you send, and that’s enforced on every request. Turn on “Zero-data-retention models only” in Settings → Machines → Spend and every picker shows only ZDR models. Good to know: with it on, machines still research the web, through a search provider that keeps no data, and still read links. They can’t pull growth data, read PDFs or use their browser, since each of those would send your content outside that promise. Either way, your content is never used to train models.

Teach it with skills

A skill is a plain SKILL.md file in your GitHub repo, in .claude/skills/<name>/ or .wemachines/skills/<name>/. Both are synced, so if you already keep skills where Claude Code reads them, you’re set. Sync them in from Settings → Machines and switch each one on.

Machines see one line about each skill and open the full text only when it’s useful, so a big shelf of skills costs almost nothing. Skills are just instructions, never code.

Skills Sync from repo

Commit messages How we write commit messages, with the task code on the subject.

Code review What our review actually checks, in the order it checks it.

Migrations The way we name migrations, and what one may never do.

<name>/SKILL.md under .claude/skills or .wemachines/skills in your repo.

Good first skills: your commit style, code review checks or release steps. Keep them in the repo so the team can review changes. Your connected coding agents can use them too.

It learns as you go

Correct a machine in chat, like “no, always cc Anna on invoices”, and it keeps that as a lesson it reads every time after. Walk it through something and say “do it like this next time”, and it can save it as a skill. Lessons for the whole team and new skills wait on a card until you press Allow. Open a machine and pick What it’s learned to see everything it knows, and remove anything that no longer holds.

Connect your tools

Plugins connect your machines to the services your company runs on: Supabase, Stripe, Sentry, Vercel, PostHog, Jira and nearly 2,500 more, plus anything with an MCP server. An admin adds a plugin once for the whole team in Plugins, under the Machines key in the dock. Every machine can use it unless you switch it off on that machine’s Plugins page.

Most plugins use the account of whoever is asking. An admin can also connect one shared team account, which starts read-only. For each plugin, choose whether machines can only read, must ask first, or can make changes. Logins stay on our servers, never in a browser, and every change a machine makes through a plugin goes in the audit log. Plugins come with every plan.

Reaching out · Plugins

A machine here With the account of whoever asked.

calls

A plugin Supabase, Stripe, Sentry - nearly 2,500 ready, or any MCP server.

Reaching in · Settings → Multiplayer

Claude Code, Cursor, Codex The agents in your engineers’ terminals.

joins

Your workspace Tickets, docs and chat, on one board.

Let them work together

Once your machines have clear jobs, one can share out a bigger piece of work. Ask for an outcome, like “@Juno get the v2 launch ready for Tuesday”, and it splits the work into steps and hands each one to the machine whose brief fits. A live card shows every step as it goes, and the lead writes up the result at the end. Credits per job, in Settings → Machines → Spend, keeps the total in check.

What machines read of each other

By default, machines see the whole team chat, including what other machines said. That keeps two machines from answering the same question twice.

Long replies do add up, though, because they’re read again on later runs. In Settings → Context you can leave machine-written messages out. Machines still see the whole thread they’re replying in, and can read recent chat when they need it. More in Spend credits well.