← All work

Our product · AI Operations

Fleet Control runs AI agents on our work around the clock, and no change lands until it passes checks a machine can verify.

Systems Architecture, Agent Orchestration, Automation, Testing

ToolsClaude CodePythonSQLiteOpenRoutersystemd
A milestone panel: August 28, September 9, September 20 and September 22, 2026

Agents that call a job done too early

Fleet Control is the system we built to run AI agents on our own work around the clock, behind checks a change has to pass before it lands. We needed it because an agent can report a task finished after doing the wrong thing, and a bad change on a live system is expensive to undo. We wanted agents picking up well-defined jobs overnight, the steady, careful work a small team never has enough hours for. That only made sense if nothing real changed until the work proved itself against a check a machine could run.

A gate every task has to pass

Every task runs as a mission with its finish line written down first, in a form a machine can check, such as a test suite passing. The mission moves through a fixed map of 14 states, from queued through sensing, executing and validating to review. There is no shortcut from validating straight to complete, and anything that stalls lands in a needs-attention queue for us.

  • Built the mission engine in Python, with gates that decide whether a change moves forward, goes back for another try, or gets rolled back.
  • Held our own code to a higher bar: its test gate deliberately breaks each changed Python function in small ways and fails if the tests catch fewer than 80 percent of those breaks.
  • Gave agents a memory they search before acting: a SQLite full-text index over our written knowledge base, which can be rebuilt from the source files at any time.
  • Made the AI model swappable through OpenRouter, so a mission can run on a different model, sealed off on a remote server.
  • Set up systemd timers that start and supervise overnight batches, with auto-merging kept off unless we arm it for a supervised run.

Proven live, one stage at a time

We widened what the system may do in stages, and each stage had to be proven live before the next. On August 28, 2026, an agent merged its own tested change with no one stepping in, inside a throwaway test repository. On September 9, the system ran live on a swapped-in AI model on a remote server. On September 20, it took its first action on a client project: a Vercel preview deploy, with production untouched. On September 22, it took an approval from an email reply sent from a phone and applied it once, and checking the inbox again did not apply it a second time. Auto-merging stays off unless we arm it for a supervised run. For a small business, this is what around-the-clock work should look like: jobs keep moving overnight, every change is checked, and nothing reaches a live system on an agent's word alone.

Building something similar?

Tell us what you need.

Send the context, the broken parts, and what you need it to do. We'll tell you plainly where we can help.

Start a conversation