An AI colleague gets a real workspace on your source code: fetch a branch, build, test, hand over. Your code does not leave your network, and nothing is ever checked in — what you get is a package a human takes over.
Interesting code rarely sits on a greenfield: it sits in a repository that has grown for fifteen years, on a server behind two firewalls, wired to a build system somebody set up years ago. That code carries most of the work — and has the fewest tools, because almost all of them assume the code comes to them. MyAiColleague reverses the direction: the AI colleague comes to the code, works on a machine inside your network and hands its result over there. What travels to the platform are mandates, decisions and logs — not your repository.
The tools that make developers productive want your code in the cloud. For the codebases this is about, that is not negotiable.
A small service runs on a machine inside your network: the runner. It opens the connection outward — nothing has to be opened in the firewall, and there is no route from the platform into your network that this service did not open itself. What it offers is decided by the operator at the machine: which directories, which source control system, and whether commands may be executed at all. When it reports a new capability, the platform first shows it as a proposal and delivers no tools until a company admin confirms it — an update cannot arm anything by itself. From the platform there is no way into those settings; that is deliberate, because this is where it is decided what runs on the machine.
You open no port. The service dials into the platform and holds the connection; the platform never calls it.
A workspace belongs to exactly one case and one employee; two colleagues on the same case work in separate directories and do not get in each other's way. Opening it is an explicit step — with a source control system the colleague picks the branch from the list of available ones, and that choice applies to everyone involved in the case. Then they work: list files, search contents, read, write, edit precisely; and if your operator has enabled commands, build and run tests as well. A service that has to keep running — a web server, a watcher — is started as a background service and worked against: make calls, read logs, shut it down at the end. Forgotten services are cleaned up by the platform itself. And your conventions apply without anyone transcribing them: project instructions in the tree are read automatically.
The colleague opens a workspace on the branch they name and works in it like a person: read, search, edit, build, test.
At the end of a task the colleague does not put the result into the branch but into a package: with TFVC a shelveset that names the case in its comment and carries the note that an AI employee produced it and that it should be reviewed before being taken over. It contains exactly what the result of this case is — not everything that looks different in the branch than on the server. The name follows the date and subject of the case, so a person finds the handover in the list; a second handover replaces the first, because the package carries the state and not the increment. This boundary is not drawn by a tool list but by the permissions of the service account: it cannot check in, even if it wanted to. Your review stays the place where decisions about your branch are made.
The result leaves the runner as a package a human reviews and takes over. The service account holds no check-in permission.
A job that runs for an hour is not a black box. The case shows what is being worked on — which tool, which step, and on a large branch how far the fetch has got. Every call sits in the fully chained log, with the reason on failure. Costs run against a daily and monthly budget and additionally against a measure for this single run; when it is reached the run ends with a statement of what it consumed instead of aborting quietly. For larger jobs the colleague presents a plan first — waves, expected results, non-goals — and a plan is always decided by a human. When a team works, the person who created something never reviews it. And anything that takes effect outside waits for a human yes.
Progress in the chat, every call in the log, cost per case, a plan before the work and a supervisor for anything risky.
As a source control system TFVC is in place today — proven on a real production branch, including handover as a shelveset — as well as the simple case of a directory on the machine. A provider for remote Git repositories is designed but not built; the layer above it is source-control-agnostic, so it is an adapter and not a rebuild. If foreign Git repositories sit checked into a branch, work inside them cannot be handed over — it is not lost, but it does not appear in the package, and the colleague states which folders are affected when opening the workspace. One colleague per workspace also means: how many can work at once is decided by your machine, not by our licence. If you need a different source system, that is a conversation about an adapter — tell us which one.
You should know before the demo, not after: TFVC and plain folders are in place, remote Git is coming, and work inside checked-in foreign repositories cannot be handed over.
30 minutes on your repository, not on our sample project. We set up the service and hand over a small change.