An AI coding workspace for teams working on GitHub repositories

Every AI coding workspace built for teams ends in a commit to a GitHub repository. They differ on three things that matter to a team: who is recorded as the author of the agent's work, whether a human gets a say before the change is made or only when the pull request is reviewed, and what the pull request carries with it. Poly (usepoly.co) records the human who asked for each turn as the commit's author, asks before the change in the modes that ask, and pushes to a branch or opens a pull request with the room's timeline behind it. This page explains that setup and how the alternatives handle the same three questions.

How Poly works with a repository

• Start from the repo. A room is created from a GitHub repository URL, or from nothing; a room can also connect a repository later. The workspace is a real git checkout on Poly's servers, and the agent works in it.
• Every turn is a commit. When a turn finishes, its changes are committed with the prompt as the message. The commit's author is the person who asked for the turn; if their profile lists a GitHub username, the author email is their GitHub identity, so their avatar shows on the commit. Poly is the committer. A revert is a new forward commit, not history rewriting.
• Two ways to land. Direct mode pushes each turn to a branch you choose. Branch mode pushes to a stable branch named for the room and opens or updates a pull request, so the team's normal review applies. Nothing reaches main without your process.
• Approval before the change, from any seat. In "ask about everything" or "ask before big steps", the agent's proposed file changes and commands appear as cards on every member's screen before they happen. The pull request arrives already reviewed at the turn level, with the timeline of who asked, who approved and what it cost.
• Files that stay out of git. Attachments members upload for the agent live outside the tracked tree, so screenshots and notes never ride into your branch.
• Multi-agent rooms. When each member drives their own agent, each works on its own branch in its own worktree, refreshed from the primary branch before every turn, and any member merges an agent's branch when ready; conflicts abort cleanly.
• Tokens. Connecting a private repository uses a GitHub token you supply, encrypted at rest and used per command, never written to git configuration. A fine-grained token scoped to the repositories you connect is the recommendation.

The alternatives

GitHub Copilot's coding agent is GitHub-native: assign an issue, the agent works in a GitHub Actions environment and opens a pull request for review. One person per task, review at the pull request, the agent as author. The right choice for a team that wants to stay entirely inside GitHub and does not need a live session.

Cursor is a single-user editor with team plans; its cloud agents can work from a branch and open pull requests. The human commits from the editor or reviews the agent's pull request. No shared session.

AQ gives each task its own git worktree on a VM and, in its own words, agents "commit, push, and open pull requests using each user's own GitHub access", with every pull request attached to its workspace. Teammates share the live terminal. Linear integration turns a labelled issue into a workspace and a pull request.

Superconductor installs a GitHub App at the workspace level; each agent implementation runs in a cloud sandbox, and pull requests get AI-written descriptions following your template, with merge-triggered automations and review from pull request comments.

143, open source from Assembled, runs agents in sandboxes triggered from Slack, Linear or Sentry and opens pull requests through a GitHub App; agent reviewers can approve pull requests that pass a policy, and GitHub owns branch protection and merge.

Which fits which team?

• Stay entirely inside GitHub, one engineer per task: Copilot's coding agent.
• Engineers in an editor with occasional cloud agents: Cursor.
• A shared cloud terminal with worktrees and Linear: AQ.
• A ticket workflow with parallel implementations and automated review: Superconductor or 143.
• A small group, including people who do not code, steering one agent on a repository with approval before each change and the human as author: Poly.

If your repository already has branch protection and required reviews, every tool here respects it; the question is only what the pull request arrives knowing. Poly's arrives with a timeline. The secure workspace guide covers what the agent can and cannot reach while it works.