The agent inside a real repo: isolating tasks with git worktree and shipping a PR

The previous post gave the agent tools to read, search, edit, and run across a multi-file repository, but running directly on the same working copy you work in. That's fine for understanding the loop; not for turning it loose on a real repo. This post is the missing wrapper: where the agent runs when the repository actually matters. The idea is to give each task an isolated copy—with git worktree and its own branch—have it reproduce the bug with a test before touching anything, run the whole suite so it doesn't break what already worked, and ship its output as a pull request, not a merge.

TL;DR

• Don't let the agent run on your working copy. Give each task its own isolated copy with git worktree and a branch: a failed attempt is a branch you delete, and two tasks at once don't step on each other.
• The flow that works for bugs is writing the failing test first (red), fixing until it's green, then running the WHOLE suite at the end to catch regressions. The new test passing isn't enough.
• The agent's output is a PR, not a merge. It proposes a diff on its own branch; a person reviews and integrates it. Isolating the work and shipping it as a PR is what lets you leave it running unsupervised.

Why the agent shouldn't touch your working copy

The tools from the previous post—write_file and run_command—operate on the filesystem: they write real files and run real commands. While the repo is a toy example, it doesn't matter where they run. On a real repository, where they run is the first serious decision, because the agent gets steps wrong: it opens the wrong file, leaves a change half-done, runs a command that fails. If all of that happens on your active working copy—the working tree, the files you have open right now—the damage is direct.

Three problems show up immediately. The first is that the agent's work mixes with yours: if you had uncommitted changes, you now don't know which lines are yours and which the agent put there. The second is that an attempt aborted mid-edit leaves broken files in your tree, and cleaning that up by hand is exactly what you wanted to avoid. The third is that you can't run two tasks at once, because both would write to the same files.

On your working copy             Isolated per task
(bad)                             (good)

your work   ─┐                    your work ─► main copy (untouched)
agent t1    ─┼─► same tree        agent t1  ─► worktree 1 + branch agent/t1
agent t2    ─┘   (collide)        agent t2  ─► worktree 2 + branch agent/t2

The solution is the same one a human team uses to avoid stepping on each other: each task works on its own copy and its own branch. The only difference here is that the program creates and destroys the copy, not a person.

---

Keep reading

That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:

Read the full post on ramonchancay.me →

Originally published at www.ramonchancay.me/blog/agent-in-a-real-repo.