Running coding agents unattended: sandboxes, leases and budgets

Coding agents are now good enough to build a small project from a brief. The hard part is not the model; it is everything around it once nobody is watching. I built a pipeline that finds bounties and hackathons, plans a build, has an agent write it, has a second agent review it, and submits it. Three problems shaped the whole design.

Problem 1: agents run arbitrary code

An agent that can build software can also run anything it writes. So generated code never executes on the control server. Every build runs in an E2B sandbox, and in API mode the sandbox gets a temporary broker credential rather than real provider keys. In subscription mode the model CLIs run in a separate private service, and only generated source is sent into the sandbox for execution. No account credentials ever enter a sandbox.

Problem 2: crashes leave work in an unknown state

A long build can die halfway through: a deploy restarts, a provider times out, the worker crashes. The question is not whether that happens but what state it leaves behind. All job state lives in PostgreSQL, changed in short row-locked transactions. Workers hold leases on the jobs they run, and a result that arrives after its lease has expired is rejected.

The effect is simple to state: a crash can make the system repeat work, but it can never apply a stale result or submit the same entry twice. When a submission's outcome is ambiguous, it is recorded as unknown and never resent.

Problem 3: agents spend money without limits

Model calls, sandboxes, hosting and search all cost money, and an agent loop has no natural reason to stop. Before dispatching work, the system reserves budget against configured limits, and work that would exceed them is not dispatched. The dashboard separates spend that has been reported, budget that is held, and cost that is still unknown, because a reservation is not an invoice.

Do not trust the agent's word

The subtlest failure was legitimacy. A model will confidently report that a bounty is real, open and paying. The selection step only passes an opportunity when independent reviewers cite current evidence from the organiser; self-certified, stale or model-only claims are rejected. The builder and the reviewer are separate agents, and the reviewer checks the exact source and production artifacts before anything is packaged.

Make every notification come from state

Telegram updates and the dashboard history are produced by the same durable state transitions. There is no separate "send a message" code path that can drift from what actually happened, so a notification is always a fact about the system.

What it came to

• Built and deployed to production on Railway in 6 days, with 107 application tests and a container and PostgreSQL restart test.
• Imported and checked 1,037 real opportunities.
• The lessons transfer to any agent system: isolate execution, make state crash-safe, cap spending before dispatch, and verify claims independently.