Connect your repo

A workspace that knows your repository is a different product from one that does not. Not because of a feature - because the AI stops guessing. It can read the code you are arguing about, it can see what shipped this morning, and the work you hand it can end in a pull request instead of a paragraph.

An admin connects it in Settings → GitHub. Here is what changes, in order of how much.

Your commits become context

Once a repository is connected, its commits ride along in what the AI reads. That sounds small and is not: “why is the staging deploy broken” becomes answerable, because the last twenty commits are in the room with the conversation about them. The GitHub App also delivers pushes and pull requests back to WeMachines, which reads the task codes on commit subjects - so a ticket referenced in a commit moves on the board without anyone dragging it.

Where it moves is your rule, not ours: a repository carries a code_flow block that says what a push to a branch means, what an opened pull request means, and what a merge to main means. Most teams write it once and never think about it again.

Questions answered from the files

“Where is the retry logic?” “How does our signup flow work?” “What throws this error?” Ask in chat or in a comment and the AI searches the connected repositories, reads the matching files, and answers citing the paths it read. No coding run, no branch, no waiting. It only ever reads - answering a question cannot change the repo - and an admin who wants a particular agent kept out of the code can switch Code Search off under that agent’s tools.

More than one repo, and telling them apart

Most teams have several. Each connected repository gets its own page with its own primary branch, its own choice about whether its commits ride in AI context, and the field that matters most: a description saying what lives in it - “the marketing site and blog”, “Terraform for the production cluster”. That sentence is how an agent knows which repository to search instead of searching all of them.

You do not have to write them. Settings → GitHub has a Study button: press it and WeMachines reads every connected repository - file tree, README, manifests - works out what each one is for, fills in the ones nobody described, and draws a map of which stands on which, with every connection traceable to the file that proves it. A description a person wrote always wins over what a study found, so studying never overwrites your own words. It runs on our servers, so you can close the tab.

Handing a ticket to a coding agent

Every task carries a play button - on the row, on the board card, and at the right end of the bar across an open task. Press it, pick a model, press Run. The agent works on its own branch and opens a pull request. You can also just say it: “@AI implement T-42”, in chat or by voice.

Mid-run it can stop and ask. Reading files, editing them and running commands are approved from the start; anything outside that shows up on the run as “Asking to use…” and waits, with Allow once, Allow for this run, or Decline. Nobody has to be watching - but nobody answering is the one way a run stalls, so a request left alone for ten minutes ends the run with whatever it had already written saved to the branch. Every run says why it ended: finished, stopped by someone, hit the step limit, ran too long. A run that cannot do the job - it needs access, a tool, or a person - says so as its result and changes nothing, which we would rather have than a confident empty pull request.

T-42 Fix the login redirect

Read 6 files

Edited 2 files

Asking to use web search It can't do this without you, and it's waiting. Allowing applies to this run only. {"query":"oauth redirect_uri trailing slash mismatch"} Allow once Allow for this run Decline

The part your engineers will care about: everyone’s agents on one board

The coding agents your team already runs - Claude Code, Cursor, Codex - can join the same workspace over MCP. Settings → Multiplayer has a one-line setup you run in the repo root:

It touches four things: a .mcp.json registering the server, a .wemachines/ folder (a workflow file telling the local agent how to keep the team updated, a config with the auto-mode switch, a guard script), a merged .claude/settings.json, and a short section appended to your agent instructions - your existing CLAUDE.md if you have one, otherwise AGENTS.md. Nothing you wrote is overwritten: files are created only when absent, and the two JSON files are merged. Re-running it is safe.

After that, a terminal session is a teammate. It picks up tickets, shows live in the sidebar while it works, moves what it ships, and can read and write the workspace the way the in-app AI does. The guard script is the reason we are comfortable with that: it blocks every workspace write tool outside a connected repo, and auto_mode in your config decides whether writes happen freely, after a confirmation, or only when somebody asks for them by name.

Whose bill the coding runs land on

A run started in the browser happens in our sandbox and spends the workspace’s credits. A run started from the Mac desktop app can instead use the agent already installed on that Mac - Claude Code, Codex, Grok or Hermes - on that person’s own subscription, for no credits at all. It works in an isolated git worktree beside their checkout, so their working tree is never touched and several runs can go at once. Spend credits well covers when each one is the right call.

In the browser Press Run on a task

runs in

Our sandbox Its own branch, then a pull request

spends

Workspace credits Shared by the whole team

Mac desktop app Press Run on a task

runs on

That Mac’s own agent Claude Code, Codex, Grok or Hermes, in an isolated git worktree

costs

No credits at all That person’s own subscription