Skip to main content
Getting started

Your first ticket, this week.

Setup is not a project you survive before the value starts. Most of it is the product working out your codebase for itself, and you checking that it got it right.

The path

Six steps. The fifth is the one that matters.

  1. 01

    Put an agent on a machine

    about ten minutes

    A server in your cloud, a box in your datacentre, anything behind your VPN. One command, the same idea as a build runner. It connects outward only, so your network team has nothing to approve beyond ordinary web traffic.

  2. 02

    Connect a repository

    a short form

    Name the product, point at the repository, connect your code host and your ticket tracker. That is the whole form — the rest it works out for itself.

  3. 03

    It reads your codebase

    one pass, read-only

    It clones the repository with read-only access and nothing else granted yet, then works out your stack, how you build and test, your branch conventions and your services. If you have a README for AI agents, it reads that first.

  4. 04

    It asks you a few things

    a short conversation

    Questions come after it has looked, so there are few and they are specific: “I can see Postgres and Terraform — which environment is production?”

  5. 05

    You confirm the setup

    the gate

    You review what it worked out and confirm what counts as production. That is the one thing it is never allowed to decide alone, and your confirmation is recorded against your name.

  6. 06

    Assign it a ticket

    from here on

    It gets to work, and comes back to you for approval when it wants to ship something. You can watch it the whole way, or ignore it until it asks.

The one gate

You say what production is.

Almost everything about your setup, the product can work out on its own and you simply confirm. One thing it never decides: which of your environments is production.

Everything else depends on that answer. Get it wrong and you have not made a configuration mistake, you have created a security hole. So a person says it, on the record.

We also check your main branch is protected before you can finish. If it is not, setup stops rather than warning you — that protection is what stops an agent merging its own work.

What you confirm
Repositories
and their main branches
Environments
and which one is production
How to build
and how to run the tests
Where tickets live
and which project
Who approves what
by role and by team
Spending limits
per ticket and per team
Then what

What the first month usually looks like.

Start where it cannot hurt

Most teams begin with it doing the work and stopping before anything ships — a pull request to look at. You are reviewing output, not trusting a system you have not watched yet.

Loosen where it earns it

Dependency bumps and flaky-test fixes are usually the first thing teams let it ship. Anything customer-facing usually stays behind an approval for a long time, which is sensible.

The second team is easy

Adding another repository or team costs a fraction of the first one, because the machine, the connections and the rules already exist.

See it run on your own code.

A working session rather than a slide deck. Bring a repository and a ticket you would otherwise assign to someone, and watch it go from the ticket to a pull request you approve.