The agent that closes your backlog while you sleep.

How it works

It runs a loop, and it stops before the parts you care about.

Every run is the same shape. The interesting part is not that it is autonomous — it is where the autonomy ends.

One real run, including the part where it got it wrong.

Every step it took on issue #482, in order, with the arguments in full. Step five failed. Step ten was never called.

1. 00:00.0Goal receivedClose240mssucceeded

   issue:  #482
   repo:   northgate/atlas
   opened: 6 days ago by @rina-k

2. 00:00.2Planned 4 stepsReproduce, locate the cache key, fix, prove it with a test3.1ssucceeded

   1. reproduce against a scratch index
   2. find where the collection name is baked into the cache key
   3. change the key to include the collection id
   4. add a regression test that renames and re-queries

3. 00:03.3github.search3 files reference buildCacheKey890mssucceeded

   query: "buildCacheKey" in:file repo:northgate/atlas
   → src/search/cache.ts:41
   → src/search/index.ts:118
   → test/search/cache.test.ts:9

4. 00:04.2github.readFilesrc/search/cache.ts410mssucceeded

   export function buildCacheKey(collection: Collection) {
     return `idx:${collection.name}:${collection.version}`
   }
   // the name is the problem — it changes on rename, the id does not

5. 00:04.6shell.test1 failing — the fixture never renames anything14.2sfailed

   $ npm test -- search/cache
   ✗ invalidates on rename
     Expected the key to change, received the same key twice.
     The fixture builds one collection and asserts on it. There is
     nothing here that renames, so the test cannot have been covering
     this path.

6. 00:18.8github.readFileRe-read the fixture rather than the test2.3schanged approach

   test/fixtures/collection.ts
   → the fixture is frozen at construction, so a rename is not expressible
   Adjusting the plan: the fixture has to change before the test can.

7. 00:21.1shell.test214 passing, including the new rename case11.8ssucceeded

   $ npm test -- search
   ✓ invalidates on rename
   ✓ keeps the key stable across a version bump
   214 passing (11.8s)

8. 00:32.9github.createBranchfix/482-cache-key-uses-id1.5ssucceeded

   base:   main @ 9f2c1ab
   branch: fix/482-cache-key-uses-id
   3 files changed, 41 insertions, 12 deletions

9. 00:34.4github.openPullRequest#1203 — Key the search index by collection id2.1ssucceeded

   Opened as a draft, linked to #482, and the failing test from step 5
   is included in the description so the reviewer can see what was
   actually broken.

10. 00:36.5github.mergeNot called — merge requires approval—not called — needs approval

    The tool definition lists `merge` under approval, so the call was
    never made. This is a line in the transcript rather than an absence
    of one: an absence looks like a bug.

11. 00:36.5Waiting for a personAssigned to @rina-k—waiting for a person

    The run stays open until someone approves or declines. Declining
    closes it unbilled.

Permissions

Everything it can reach, and everything it has to ask about first.

Scoped per tool, enforced at the call site rather than in the prompt. The blanks below are real: where there is no cell, there is no access.

Rows come from src/content/tools/tools.yaml. Leave a field empty and the cell stays empty — that is the honest version, and it is the one that gets believed.

import { defineTool } from '@astroloop/sdk'

export const github = defineTool({
  name: 'github',

  reads:  ['repos', 'issues', 'pulls'],
  writes: ['comments', 'branches'],

  // Anything listed here stops the run and waits for a person.
  // Checked at the call site, so the agent cannot talk its way
  // past it the way it can with an instruction in the prompt.
  approval: ['merge', 'force-push'],

  audit: true,
})

Measured against a person doing the same 412 issues.

Including the row where we lose. Methodology is below the table, not behind a form.

In production

What is written down, and who can read it back.

Which model sees what, and where it goes.

Named per stage rather than described in the aggregate. Bring your own keys and none of it changes.

What people say

The people who had to sign off on it.

Pricing

You pay for work finished, not for people logged in.

A run that stalls, loops, or gets rejected at handoff does not bill.

Move the slider. That is the whole pricing page.

Runs that stall or get declined at handoff are deducted rather than hidden, because they are the ones you would otherwise find on the invoice.

Questions

The ones we get asked before the trial, not after.

What counts as a run?

One goal, from the first plan to either a result or a rejected handoff. Retries inside a run are not billed separately.

Can it act without asking?

Only for actions you have not listed under approval. Everything on that list suspends the run and waits, and the list is enforced in the tool layer rather than the prompt.

What happens when it stalls?

The run is cancelled at the step budget and not billed. You get the transcript either way.

Where does my code go?

Into the runner for the length of the run, and nowhere else. Self-hosted runners are available if that is still one place too many.

Which models does it use?

Whichever you configure, including your own keys. The permission layer does not change with the model.

Can I revoke a tool mid-task?

Yes. Permissions are read at the call site, so the next call fails closed even in the middle of a run.

Give it one repository and see what comes back.

Twenty runs a month, free, with the same permissions and the same transcripts as every other plan.