I built a staging area for AI coding agents
I use AI agents and multi-agent workflows constantly. The same two
problems show up every time.
The first is visibility. You only talk to the orchestrator. It starts
the work and comes back later with a result. You can't see which agent
took which task, or why it decided what it decided. You trust the
system, and you find the mistakes afterward.
The second is review. The work arrives as one large diff at the end.
Correcting anything at that point is expensive. So you either approve
work you didn't read, or you throw it away.
I wanted to watch the work happen, and I wanted to review it in small
pieces. Apron Agents is the result.
The design
The name comes from the airport apron — the staging area where crews
prep and check aircraft before they ever reach the runway.
An orchestrator splits your task into small issues, each touching
different files, and hands each one to a worker agent.
Every worker gets a clone of a temporary bare git repository. It is not
your repository. It's a disposable copy in a temp directory that
behaves like a real remote, so agents can branch, commit, and push
without any risk.
Merges happen one branch at a time, and each one has two conditions:
you have to approve the diff, and the test command has to pass. If the
tests fail, the branch is rejected before it merges.
At the end, the files are copied into your working directory. That copy
is the only connection to your machine. Apron never configures your
real remote, never fetches from it, and never pushes to it.
One module holds that rule, and a test enforces it — no other file in
the codebase is allowed to start a git process.
The first bug: nothing happened after dispatch
You typed a task, hit enter, and the interface sat there for several
seconds. Long enough to look broken.
My first fix was a loading spinner. That was the wrong fix.
The real cause was the event bus: it awaited each subscriber in
sequence, so the HTTP request didn't return until the planner model had
produced the entire plan. The UI didn't have a feedback problem. The
request had a multi-second model call inside it, and that call didn't
belong there.
A spinner makes a bad design tolerable. It doesn't fix it.
So I moved planning into a background task. Once it was out of the
request, I could show it. The planner now reports its own steps, and
you watch it read files and assemble the plan in real time.
The bug turned into the feature I wanted in the first place.
The second bug: the agents never saw the review notes
The review gate lets you reject a diff and write a reason for it.
A few weeks later I traced where that reason actually went. Nowhere.
The rejected issue was handed back to the agent with no context, and it
retried knowing nothing about what it got wrong the first time.
The fix was small. Feedback is now appended to the issue description
for the next attempt — review comments, failed test output, and merge
conflicts. The description is already part of the normal prompt, so
every agent backend picked this up without a single change.
This is the failure mode I'd watch for in any event system. If you emit
data and nothing subscribes to it, there's no error. No test fails. The
code is correct on both ends. Only the behavior is wrong. It took me
weeks to notice.
Now, whenever I add a field, I ask one question first: what reads this?
Availability
Apron Agents is an early beta, MIT licensed. It runs on whatever you
already have — Claude Code, Codex, an API key, or an offline demo mode.
pip install apronagents
apron start
If you find bugs, file them in the issues tab.
Stack
Python for the orchestrator, workers, merge controller, and the
disposable git sandbox. TypeScript and React for the live dashboard.
Packaged on PyPI, tested in GitHub Actions.
← All posts