Skip to content
SIRCODESALOT
All notes

Note 02 · · 2 min read

What an AI worker should be allowed to do (and not do).

Letting agents write code is the easy part. Deciding where their reach ends is the design.

Ghost Foundry takes a GitHub issue and turns it into a reviewed pull request. An agent reads the code, reproduces the problem, makes the change, runs the checks, and a second agent reviews it. It works well enough that the interesting question stopped being can it do this? and became what should it never be able to do?

Here's where I've landed.

It gets a workspace, not a machine

Every run happens in a throwaway Docker container: capped memory and CPU, Linux capabilities dropped, no Docker socket, and nothing from my home directory mounted. The agent gets a checkout of the repository and the tools it needs to build and test, and that's the whole world.

If an agent decides the fastest way to fix a failing test is to delete the test suite, fine. That's a bad diff, and review will catch it. What it can't do is read my SSH keys or poke at other projects, because they don't exist from where it's standing.

It proposes; a human merges

Agents can open a pull request. They can't merge one, and they can't deploy. The run collects evidence along the way, including logs, the diff, the check results, and before/after screenshots, so when the PR lands in my inbox I can review the outcome, not re-run the investigation.

This is the line I care most about. Automation should make the human decision faster and better informed, not remove it.

Two agents, two jobs

The fixer and the reviewer are configured separately and can be entirely different models from different providers. An agent reviewing its own work tends to agree with itself. A different model with a different prompt and a single job ("find what's wrong with this") catches things the author talked itself past.

Nothing is lost, nothing runs twice

Runs go through a durable queue with atomic claims and leases. If the worker crashes mid-run, the lease expires and the job is recovered, not duplicated and not forgotten. That's not an AI problem, it's a plain old distributed-systems problem, and it matters more here than usual: a duplicated agent run means two competing pull requests for the same issue.

The short version

Give agents a small, disposable world. Let them do real work inside it. Make every result reviewable, and keep the irreversible buttons (merge, deploy, pay, publish) behind a human. Everything else is tuning.

Dealing with something like this?

I'm happy to talk it through.

Get in touch