Let an agent open pull requests

An AI agent can take a coding card from start to a pull request on your repository. You review the pull request and merge it yourself. The agent never does.

Before an agent can do this, you need three things in place:

• a code connection, see Connect your code;
• the repository linked to the card’s project, see Link repositories to a project;
• an agent that is a member of that project and has workstations turned on, see AI agents.

Ask for a change

Name the repository in the card’s Repository field. If the project has only one repository, it is used without you choosing it. Then do either of these:

• Assign the card to the agent, and write the outcome you want in the description.
• Send the agent a direct message about the card.

Say which branch the change should go into if it isn’t your repository’s default branch, for example “target staging”. That branch has to be on the repository’s list of allowed branches (see Which branch the pull request targets).

Every pull request is tied to a card. An agent can’t open one without a card, and the card must be a task or ticket on a project that has the repository linked.

What the agent does

The agent starts a workstation and works on the card’s repository there:

1. It clones the repository and reads its README and contributing notes.
2. It makes the change on a new branch whose name starts with 3mote/, for example 3mote/VW-12-voice-orders, and pushes it.
3. It finds the repository’s own checks, such as lint and tests, and runs them.
4. It opens a pull request. If the checks failed, or it couldn’t run them, the pull request is a draft and says why.
5. It comments on the card with a link to the pull request. When the pull request is ready (not a draft), 3mote moves the card to Review for it. A draft leaves the card where it is.

The agent never merges or approves a pull request, and it never moves a card to Done. A person reviews the pull request, merges it, and finishes the card.

Which branch the pull request targets

The pull request goes into your repository’s default branch. The default branch is always allowed.

To let pull requests target other branches, such as staging, a project owner or admin lists them for each repository in Project Settings → Repositories. An agent can only target a branch on that list, and only when you or the card ask for it. The branch also has to exist on the code host. The agent never targets a 3mote/ branch. If a repository has no extra branches listed, every pull request goes to the default branch.

If you ask for the same branch again, the agent updates the pull request it already opened instead of opening a second one. An agent only ever updates pull requests it opened itself. If someone else already has a pull request open from that branch, the agent doesn’t take it over. An agent can open at most five pull requests an hour.

What the pull request shows

On GitHub the pull request is opened by the 3mote app, not by a person. Its description ends with a line that names the agent and the card, for example:

Opened by Ada (AI agent) on 3mote · VW-12

That line holds the card’s code and nothing else about your workspace. It has no link back to 3mote and doesn’t name the person who asked, because repositories can be public and anyone can read the pull request. On AWS CodeCommit, a draft pull request is titled with [Draft] at the start, because CodeCommit has no draft state.

If the repository is public, anything in the title or description is public too. Agents are told to include only what the change needs, and 3mote checks it. On a public repository, 3mote refuses a pull request whose title or description contains a link to your workspace, a mention of a person on 3mote, or the email address of any member of your workspace. It also limits the description to 8,000 characters. The agent is told what to remove and can try again.

On GitHub, 3mote also neutralises @-mentions and closing keywords in the agent’s title and description. A name like @octocat won’t notify anyone, and “Closes #12” won’t close an issue when the pull request merges.

Follow the outcome on the card

Open the card. Under the Repository field, a Pull requests row shows each pull request as a chip with its number and state: Open, Draft, Merged or Closed. Click it to open the pull request on your code host.

The Activity tab records when the pull request was opened and when its state changed, for example when it was merged. No notification is sent. The card is the record.

How quickly the state updates depends on where the repository lives:

• GitHub tells 3mote about a merge, a close, a reopen or a change from draft to ready within moments.
• AWS CodeCommit can’t tell 3mote, so its pull requests update when you open the card (if they haven’t been checked in the last few minutes), and in a daily check of pull requests opened in the last 30 days (up to 50 per workspace per day). After 30 days, a pull request only updates when someone opens the card.

3mote keeps the pull request’s number, title, link, branch names, state and when it was merged or closed. It doesn’t keep a copy of your repository, but the agent’s workstation clones the repository it works on, and the workstation’s checkpoints, which include that working copy, are kept in your workspace’s storage until 7 days after the session ends (see AI agents).

Keep your main branch safe

An agent can only push branches that start with 3mote/, and can’t merge. Even so, protect your default branch so that no change reaches it without a review. On GitHub, add a ruleset (or branch protection rule) that requires a pull request and at least one approval before merging. In CodeCommit, use an approval rule template. Your people then review every agent change the same way they review each other’s.

CI and secrets

Opening a pull request usually starts your repository’s own checks. If a workflow runs on pull_request, it runs on the agent’s changes, with that workflow’s secrets and token, because the change comes from a branch in your repository. Branch protection doesn’t stop this. It only stops the merge.

To limit what an agent’s change can reach:

• Set your repository’s default workflow permissions to read-only, and grant more only to the workflows that need it.
• Keep deploy keys and other sensitive secrets in an environment that needs approval, so a workflow can’t use them until a person approves the run.
• Review the pull request, including any change to workflow files, before you approve a run or merge.