AgentSDEDocs
Open console

Quickstart

Connect a repository, let an agent take one issue end to end, and review the pull request it opens. Ten minutes, no pipeline design required.

8 min readUpdated 2026-08-04 · Priya NEdit this page

#Before you start

You need three things. None of them take long, and none of them require you to change how your team already works.

  • An AgentSDE workspace where you can hire agents and start runs · the built-in admin role, or a custom role granted those permissions.
  • A repository you can open pull requests against, on GitHub or Bitbucket.
  • One issue small enough to finish in a single pass · a failing test, a missing validation, a copy fix. Save the refactor for later.
Agents work inside your rules, not around them

An agent pushes to its own branch and opens a pull request like any other contributor. Branch protection, required reviewers and required checks all still apply. There is no path by which an agent merges to a protected branch on its own.

#1 · Connect a repository

Connecting is an OAuth grant plus a repository selection. The scopes are fixed at grant time, which is why AgentSDE shows you what it received rather than letting you toggle permissions after the fact.

1

Install the AgentSDE app

In the console, open Settings → Integrations and choose GitHub. You will be redirected to install the app on the organisation that owns the repository. An organisation owner has to approve it once.

2

Select the repositories agents may touch

Grant the narrowest set that still lets you test · one repository is enough today. You can widen the allowlist later in Settings → Repositories without re-authorising.

3

Confirm the base branch

Agents cut branches from the base branch set in Settings → General → Source control. Leave it blank to follow each repository’s own default, or pin one per repository.

verify the connectionbash
$ agentsde repos listacme/web          github    base: main       activeacme/api          github    base: develop    activeacme/infra        github    base: main       excluded

#Choose an issue source

Work arrives from a tracker. Pick the one your team already uses · the rest of the quickstart is identical whichever you choose.

Nothing more to connect · the app grant already covers issues. Agents read the issue body, its comments and its labels.

what an agent readsyaml
issue:title: "Login form accepts blank email"labels: [bug, in-refinement]body: |  Submitting the sign-in form with an empty email  returns a 500 instead of a field error.comments: 3

#2 · Hire an agent

An agent is a binding, not a model. Hiring one ties four things together and gives them a name your team will see on pull requests.

What you bindIn the quickstartChange it later in
Phase designStarter SWE v1Phase design
PersonaPragmatic contributorPersona
Repository scopeacme/webAgent detail
EnvironmentProductionEnvironments

The Hire wizard sets all four. Every one is editable afterwards without re-hiring.

The console wizard is the fastest path. If you would rather stay in the terminal, the CLI does the same thing:

terminalbash
1$ agentsde hire \2  --name "web-swe" \3  --design starter-swe \4  --persona pragmatic-contributor \5  --repo acme/web6hired agent agt_01HXY42M9VBQ7K3Z7design starter-swe pinned at v18ready · waiting for an intake trigger
Start on the pinned design

Starter SWE is a five-phase pipeline: refine, plan, deliver, review, compound. It is deliberately boring. Write your own phases once you have watched this one run twice.

#3 · Start your first run

A run starts when an intake trigger fires. Every workspace ships with two built-ins, and both are on by default:

  1. The issue enters the in-refinement label or status.
  2. Someone comments the literal command /agent start on the issue.

Use the comment for your first run · it is explicit, and it records who asked for the work.

/agent start
Posted as an ordinary issue comment. The agent replies in the same thread when it picks the work up.

The run appears on the Runs board within a few seconds. Press K anywhere in the console and type the issue title to jump straight to it.

The Runs board grouped by status · Queued, Running, Paused and Stopped columns, each holding run cards with the issue title, repository, agent and progress.
The Runs board · every active run, grouped by status as it moves through the pipeline.

#4 · Watch the phases

Each column on the board is one phase of the agent’s design. A phase is a system prompt plus a model, a reasoning budget and a set of allowed tools. The card moves right as each phase completes, and every phase leaves an artefact you can read.

PhaseProducesTypical duration
RefineA restated brief · scope, acceptance criteria, open questions1 to 2 min
PlanA file-by-file change plan against the real repository2 to 4 min
DeliverA branch, commits and a diff4 to 20 min
ReviewSelf-review comments and a pass or fail verdict1 to 3 min
CompoundNotes folded back into the repository knowledge graphunder 1 min
Cost is per phase, not per run

Token spend accrues as each phase completes and is shown on the run card and in the run detail hero. A run that stalls in Deliver is the expensive one · set a per-environment cost cap before you point an agent at a large repository.

#5 · Review the pull request

When Deliver finishes, the agent opens a pull request from its branch and requests the reviewers your branch protection already requires. The description is written from the refined brief and the plan, so the reviewer sees the reasoning and not just the diff.

Returns a 422 with a field-level error when email is blank, instead of falling through to the session lookup. Adds two cases to auth/sign-in.test.ts. Acceptance criteria from the issue are restated below; the third one, rate limiting, is out of scope and left open.

Pull request body · acme/web #4192

Review it exactly as you would a colleague’s. Request changes in the normal review UI · if the agent’s design has a review-blocked trigger wired up, that comment starts a follow-up run automatically. Otherwise comment /agent start again.

#When a run stops early

Three states are worth recognising before you debug anything:

  • Needs input · the agent asked a question it cannot answer from the repository. Answer in the run panel and it resumes.
  • Failed · a phase errored. The logs for that phase are on the run detail page; retry re-runs from the failed phase, not from the start.
  • Paused · you or a policy stopped it. Nothing is lost; the branch stays where it was.
Restart is not retry

Restart discards the agent’s branch and begins the pipeline again from Refine. Use it when the brief itself was wrong. If only one phase misbehaved, retry that phase instead.

#Still stuck?

Check the run’s Started by row first. Most first-run surprises are intake surprises · a label that does not match the trigger, or a repository outside the agent’s scope. See status.agentsde.com if phases are queuing but never starting.