Most AI coding assistants assume you are fine sending your repository somewhere else. For side projects that is a reasonable trade. For anything with a client contract, an internal service, or a repository you cannot move, it is not.
The interesting shift of the last year is that the agent part has become a commodity — Codex, OpenCode, Claude Code and friends all expose a CLI you can run yourself. What is still missing for most teams is everything around the agent: where does it run, which filesystem does it see, who reviews the diff, and how do you run the same routine twice without re-explaining it from scratch.
I have been building that layer for a while. Here is the model that ended up working for me, and the concrete pieces you need if you want to reproduce it.
1. Separate the control plane from the machine that runs the agent
The mistake I made first was treating "the agent" as the single thing to manage. In practice there are three distinct things:
- a control plane that owns identity, sessions and routing,
- one or more nodes — your laptop, a home server, a cheap VPS — that can actually execute work,
- a set of workspaces that give each task an isolated filesystem and process tree.
Once those are three separate concepts, everything else gets easier. A session is not "a chat window", it is a job with an owner, a working directory, a runtime and a status. You can list it, resume it, hand it to a colleague, or kill it.
If you want the shape of that in practice, the first setup guide walks the control-plane/node split end to end, and remote nodes covers what it takes to attach a second machine — the interesting part is that node enrollment is a token, not a VPN, so a box behind NAT is reachable without exposing your whole network.
2. One workspace per task, not per conversation
The second change was moving from "one container per project" to "one workspace per task". A task workspace is disposable: it gets a working directory, a defined runtime, and a bounded life. Two agents working on the same repository in parallel stop stepping on each other's files, and cleaning up is a delete rather than an archaeology exercise.
That works with either a local runtime (run directly on the host, reuse the tools you already have installed) or a Docker runtime (each workspace in its own container). I default to Docker for anything that installs dependencies, and local for repositories where I want the host toolchain.
See instances for how workspaces are created and restored, and workspace: repository if you want the Git side of it.
3. Make the agent's output reviewable, not just readable
A terminal scrollback is a terrible review artifact. What I want after an agent finishes is:
- the diff, in a form I can read like a pull request,
- the commands it actually ran,
- a branch or worktree I can check out and test myself.
The practical trick is to have the agent deliver onto a separate ref instead of mutating your working tree. Worktrees are the cheapest version of that: the agent works on its own checkout, git diff shows you exactly what happened, and merging is a normal Git operation. There is a walkthrough of that workflow in the worktree session tutorial.
If the agent needs to pull a private dependency, the credentials question comes up immediately. Scope the token to the specific remote, use it for provisioning, and keep it out of the agent's environment where possible — git credentials goes into that in more detail than is comfortable.
4. Automate the routines you repeat
After a few weeks you notice you are running the same sequence over and over: pull, update a lockfile, run the test suite, fix the lint, open a branch. That is where a small automation layer pays for itself. I ended up with four primitives that compose:
- documents — the instructions, versioned,
- triggers — what starts it (schedule, webhook, manual),
- actions — what it does (run a session, run a command, notify),
- schedules — when.
Once those exist you stop pasting the same prompt and start reviewing output instead. The automation docs cover the model, and actions is the part with the sharp edges.
What I would tell someone starting today
- Run the agent where the code lives. Latency is the least of your problems; data residency and filesystem access are the real ones.
- Give every task a disposable workspace. It removes an entire class of "which file did it overwrite" bugs.
- Make the agent deliver a diff, not a summary. Reviewing summaries is how you end up trusting a black box.
- Automate only after you have run the routine manually three times.
If you want to try this shape without assembling it yourself, this is exactly what I have been packaging as TaskHandoff — a self-hosted control plane for AI coding agents, Apache-2.0, with local and remote nodes, per-task Local or Docker workspaces, Codex and OpenCode sessions, Git review, and scheduled automation. Start with installation, or skim the FAQ if you are wondering whether it needs Docker or a public IP.
The docs are at docs.thandoff.com (also in Chinese — the site is bilingual, add /en/ for the English tree).
What is your setup? Are you running agents on your laptop, a home lab box, or somewhere properly boring like a VPS? I am curious which of the three layers above people are missing.
Top comments (0)