A proposal reaches you two ways: a Change proposal card in the agent’s chat, and a row under Waiting for your decision on Home. Both open the same screen with Review and decide.

Start with the agent’s write-up and any screenshots it attached, the easiest part to judge on a phone. The summary card above them is the change itself: the files changed, opening to the full diff, the commits, and Actions for the checks. A line under the write-up says what approving will do. Comments is a thread shared with the agent and your teammates while the proposal is open.

Approve & merge merges the branch into main and the agent hears the outcome in its chat. Reject merges nothing; the screen does not collect a reason, so say it in the agent’s chat, where it can act on it. Only the owner of the agent that proposed the change can decide it. A teammate can read and comment, and no agent can approve anything.

You ask an agent for a change. It works on a branch, pushes, and records a proposal. None of that reaches you: no card, no row, nothing to decide. The agent keeps going until it is finished, with the checks green, the wording right and the screenshot attached.

Only then does it invite you, and the card and the row appear together. What you decide is always what is on the screen when you press the button. If the agent pushes an improvement before you decide, the same proposal shows the new code, with no second card. After you decide, the card in the chat shows the outcome and the row leaves the queue.

A repository can run checks: its own script, .agentbuilt/ci.sh, on a throwaway machine. The verdict shows on the proposal’s Actions row and on the repository’s overview. A repository with no script reports skipped, which means there was nothing to run.

You get a card only when the checks on that version have passed. A check still running or failing keeps the invitation from being sent, and a check pending for 30 minutes fails, so a verdict always arrives. The checks can go red afterwards, because an open proposal follows its branch: a later push runs them again. When that happens the button reads Approve anyway, and the line above it points at the Actions row. Approving still merges.

A repository can be set to merge only when its checks pass. There the button reads Actions must pass first, stays disabled, and unlocks itself the moment they pass. What a check may be handed is under Keys for checks.

A merged change is not necessarily live yet. After approving, the proposal screen grows an After approval card with three stages that fill in on their own: Merged into main, Checks on main, and Delivery, whatever the repository does with a merged change. A delivery that reports skipped needed nothing; one that finishes says the change reached a live surface. On a repository with CI off, the last two say off straight away: nothing runs after the merge, so there is nothing to wait for. The site’s row on Home, or the agent, says when it is in front of everyone (see The site screen).

What merges is the version on your screen. If the branch moved between your reading and your tap, approving is refused, nothing changes, and the pill reads Went stale; the agent proposes again. A proposal whose pill reads Conflicts with main is final: the fix arrives as a new proposal with a new number, and the agent says which number is the live one.

If you already have a GitHub, a GitLab or another git host, that is the right home for your code, and an agent uses it once it has a key for it. Your history, collaborators and existing checks stay where they are.

When there is no host, or no way to hand an agent a key for yours, the platform has private repositories of its own, on its own git storage. Ask any agent to create one. It belongs to the whole workplace: every member sees it and every agent in every room can push to it, with no share step. A repository’s screen has an Overview tab for its proposals, check runs and contributors, and a Content tab for the files and the README.

In a repository created here, main is protected: no agent can push to it directly, and a change reaches it only through a proposal you approve. Protection can be added but never taken away, and so can the rule that merges need green checks. An agent can also create an unprotected repository, permanently, for stores nobody reviews such as backups and exports. Anything you will read or run belongs in a protected one.

A clone is a copy of a repository on your own computer, worked on with ordinary git. The Repositories section on Home ends with Clone on your computer: it shows an example git clone line, with x-access-token as the username and your personal key as the password.

Create key & copy makes the key and puts it on your clipboard, unseen by anyone. New key & copy replaces it everywhere at once and Revoke ends it. Agents never see this key and cannot make one for you; ask one how to get the code onto your laptop and it points you here.

Sometimes a check needs a key, a deploy token for example. Keys live in a room’s Secrets, and a check gets one only when you say so. When an admin’s agent asks, the repository’s row on Home gains the badge CI access asked, and its screen shows which agent asked and which keys it named.

You decide there, with Allow for approved CI or Keep private. Allowed keys reach checks on main only and are masked out of every log. A grant names one room, because keys belong to rooms. Any agent can later narrow a grant; only you can widen one.

An agent can rename a repository. The history stays whole; only the clone address changes.

No agent can delete a repository. An admin’s agent can ask, which shows as the badge delete asked on the row, and the agent tells you in its reply. On the repository’s screen Keep it says no, or Delete this repository asks you to type the name. An admin can also delete there without an ask. For 14 days any agent can bring it back; after that it is gone.