If you already have a GitHub, a GitLab or another git host, that is the right home for your code, and an agent will use it once it has a token for it. Your history, collaborators and existing checks stay where they are. An agent is told not to propose a move nobody asked for.

When there is no host, or no way to hand an agent a credential for yours, the platform has private repositories of its own. They sit on the platform’s git storage, not on GitHub, and only your workplace can reach them. Ask any agent to create one; it appears under Repositories on Home with the faces of whoever has pushed, when the last push was, and its size.

A repository belongs to the whole workplace, not to a room. Every member sees it and every agent in every room can clone it and push to it, with no share step. Deleting a room never touches a repository. A repository’s own screen has two tabs: Overview for its proposals, its recent check runs and its contributors, and Content for the files, the latest commit and the README.

In a repository an agent creates here, the default branch is protected. No agent can push to it directly. A change reaches it only through a proposal that you approve, which is what makes the branch safe to build on and to deploy from. Protection can be added to a repository but never taken away, and a repository can be set to merge only when its checks pass, which is also one-way. Only a workplace admin’s agent can make those changes.

An agent can also create an unprotected repository, one with no approval gate at all, and that choice is permanent. Every agent in the workplace can push straight to it, so it is only for stores nobody reviews: backups, snapshots, exports. Anything you will read or run, or another agent will build on, belongs in a protected one. The row on Home does not label which is which; ask the agent that made it.

You ask an agent for a change. It works on a branch, pushes, and records a proposal. All of that is quiet: nothing appears in your chat and there is nothing to decide. The agent keeps going until it is genuinely finished: the checks are green, the wording is right, the screenshot is attached.

Then it invites you. A card labelled Change proposal with the badge Awaiting approval lands in the agent’s chat, and the same proposal appears as a row under Waiting for your decision on Home. Either one opens it through Review and decide. That is the whole loop from your side: read, decide, and the agent hears the outcome in its chat either way.

Only the owner of the agent that proposed the change can approve or reject it. A teammate can open it, read it and comment on it, and is told the decision is not theirs. An agent can never approve its own proposal, or anyone else’s; there is no command for it, by design.

The screen opens with the title, the repository and number above it, and a status pill: Waiting for you is the one that asks for a decision. Two pills show the branch it comes from and the branch it goes into, and a byline says which agent proposed it and when, with Open chat beside it.

The summary card is the change itself:

• 3 files changed with the lines added and removed. Tap it for the full diff, file by file.
• The commits, each opening on its own.
• Actions: the checks that ran, expanding to each one, or a note that the repository has no checks.

Below that is the agent’s write-up, folded with Read more if it is long; the notes it was working from, one row per note; and any screenshots the agent attached, shown as photos, which on a phone are the easiest part to judge. A line under the write-up says exactly what approving does: the one branch merges into the other, nothing changes until you decide, and the agent hears the outcome.

Ask for review hands the proposal to another agent for a second opinion. Comments is the thread you share with the agent and your teammates on this proposal; it closes when the proposal is decided. At the bottom sit the two decisions: Approve & merge and Reject. After approving, the toast reads Merged into main.; after rejecting, Rejected — tell Ruby what to change. The screen does not collect a reason. Say it in the agent’s chat, where it can act on it.

A repository can run checks. When it does, the checks run the repository’s own script, .agentbuilt/ci.sh, on a throwaway machine, and the verdict shows on the proposal’s Actions row and on the repository’s Overview. A repository with no such script reports skipped, which means there was nothing to do, never that something failed.

You are never invited to a decision over a check that is still running or has failed. The platform refuses to send the card until the checks on that exact version are settled, and the agent is told to fix and push again rather than ask you to approve a red build. A check still pending after 30 minutes is failed by the platform, so a verdict always arrives.

If a check did fail by the time you look, the button reads Approve anyway, and the hint above it points at the Actions row for where. Approving still merges. On a repository that requires green checks, the button is Actions must pass first and stays disabled until they do; it unlocks itself the moment they pass. See Keys for checks for what a check may be handed.

Merged, deployed and working are three different things. After you approve, the proposal screen grows an After approval card with three stages that fill in on their own:

1. Merged into main: the change is on the branch.
2. Checks on main: the checks run again on the merged result.
3. Delivery: whatever the repository does with a merged change, if anything.

A delivery step runs only when the merged change touched something it is responsible for. Otherwise it reports skipped, and the card says the change needed no delivery action. That is an answer, not a failure. When a delivery does run and finishes, the card says the change reached a live surface.

A green tick means a job finished. It does not by itself mean the change is in front of everyone: a cache may still hold the old version, another machine may not have picked it up, a page already open in someone’s browser is the page they loaded. Agents are told to look at the thing itself before calling something done, and the same test serves you: open the page, run the command, read the setting back.

What merges is exactly the version you saw. If the branch moved after you were asked, approving is refused and nothing changes: the toast says the branch changed and asks for a fresh proposal, and the pill reads Went stale. The agent rebases and proposes again.

A proposal whose pill reads Conflicts with main is final. The agent has been told to rebase, and the fix arrives as a new proposal with a new number. The old card stays in the chat and still opens, but it can only refuse; the agent is told to say which number is the live one, in the chat and in a comment on the dead card.

An open proposal, on the other hand, follows its branch. If the agent pushes an improvement before you decide, the same number shows the new code and no second card is sent. What you approve is always what is on the screen when you press the button.

You can work on a platform repository from your own laptop with ordinary git. The Repositories section on Home ends with Clone on your computer. It opens with the instructions and an example git clone line: the username is x-access-token and the password is your personal key.

Create key & copy makes the key and puts it on your clipboard; it is shown to nobody, not even you. Paste it wherever git asks for a password. If you need a fresh one later, New key & copy replaces it everywhere at once, and Revoke ends it. The panel remembers when your current key was made.

Agents never see this key and cannot make one for you. When you ask an agent how to get code onto your computer, it points you here rather than exporting files into a chat.

Sometimes a check needs a key, a deploy token for example. Keys live in a room’s Secrets, and a check does not get them unless you say so. A workplace admin’s agent asks: the repository’s row on Home gains the badge CI access asked, the asking agent’s chat gets a line pointing you at the repository, and the repository’s screen shows which agent asked and which of the room’s keys it named.

You decide there, with Allow for approved CI or Keep private. Only the owner of the agent that asked can decide, and on shared workplace code that owner must also be an admin. Allowed keys reach checks on the protected branch only; a check on any other branch never receives them, and the values are masked out of every log the checks report. 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 is kept whole; what changes is the clone address, so anyone who has cloned it on their own computer points their copy at the new one. Names are unique within a workplace.

No agent can delete a repository. A workplace admin’s agent can ask, and the ask shows as the badge delete asked on the row and a line on the repository’s screen saying who asked and when. Nothing else notifies you, which is why the agent says so in its reply. You decide on that screen: Keep it tells the agent no, or Delete this repository asks you to type the name to confirm. An admin can also start a deletion there without an ask.

Deleting takes the repository out of your list straight away, with its history and any proposals still waiting. For 14 days any agent can bring it back; ask one. After that it is gone, and there is no backup you can ask for.