Bug-fix agent
An error in production wakes it. It pulls the stack trace, the context and the blast radius, finds the cause, and writes a fix with a test that would have caught it.
Out: a pull request, often before anyone has reported the bug
Philosophy Workflow
How the work actually runs.
Our philosophy says the code is support. This page is that support: the tools and agents that keep implementation in the background, so people can stay with the user, the direction and the product.
01 · Parallel work
Many agents, each in its own room.
We run our coding agents in Conductor. Every task gets its own workspace: a separate copy of the repository on its own branch, with its own ports and its own running app. Five agents can work on five things at once, and none of them can step on another.
A person moves between the workspaces like a director between sets. Give direction, check the result in the running product, send it on as a pull request, move to the next.
Why
With one agent at a time, the person becomes the bottleneck: you wait, then you review, then you wait again. Isolation is what makes parallel work safe, and parallel work is what turns one person's judgement into a team's output.
- porto Shorten the onboarding form PR open
- pangyo Draft a first report automatically Building
- lagos Fix crash on empty customer list Testing
- quito Migrate invoices to the new schema Building
- tallinn Add "repeat last trip" shortcut Waiting on us
Each row is an isolated workspace with its own branch. Nothing collides, so nothing has to wait its turn. The last row is the important one: the agent is ready, and the decision is ours.
02 · Capacity
We built our own fuel gauge.
Running many agents in parallel burns through model limits fast. So we made a small menu-bar manager for all our Claude and OpenAI accounts. It shows every account's rolling windows at a glance: the last five hours, the week, and the week for the largest model, along with exactly when each one resets.
One click switches which account the agents run on. When one is nearly spent, the work moves to the next instead of stopping.
Why
When agents do the implementation, developer hours stop being the scarce resource. Model capacity takes their place. Hitting a limit halfway through a task doesn't slow the work, it stops it. So we treat capacity like any other production resource: visible, measured, and switchable before it runs out.
Account AClaude Max 20x
5 hours0%
Week52%resets 3h 22m
Week · largest model100%resets 3h 22m
Account BClaude Max 20xActive
5 hours29%resets 3h 52m
Week44%resets Thu
Week · largest model82%resets Thu
Account CClaude Max 20x
5 hours0%
Week28%resets Sun
Week · largest model55%resets Sun
Account DOpenAI TeamActive
5 hours0%resets 4h 59m
Week11%resets Wed
A drawing of our manager, not a screenshot. Account A has spent its week on the largest model, so that work has already moved to B. C is the reserve.
03 · Agents
Work starts when something happens.
Not when someone finds time to write a ticket. Some agents wake on an event: an error in production, a new pull request, a signal in the usage data. Others run on a schedule, because that is the only way their work ever gets done.
Why
Security reviews, performance checks, test coverage and documentation are the work that sinks to the bottom of every backlog. It was never unimportant. It was just expensive next to the feature someone was waiting for. When agents do it, it costs little, so we schedule it and it happens.
- Event something happened in production
- Pull request a change is on its way
- Schedule runs at fixed intervals
Review agent
Every pull request is reviewed, whether a person or an agent wrote it. Findings that are safe to fix are fixed in the same pull request. The rest are raised as comments.
Out: a reviewed change, or a question for a person
Investigation agent
A step where people drop off, a feature nobody finds, a flow that takes too long. The signal starts an investigation into what is going on and what it might be worth.
Out: a finding for a person to decide on. Never a change on its own.
Security agent
Goes through the code and its dependencies looking for secrets, unsafe patterns and known vulnerabilities, and runs the security tests. On a schedule, not just when someone remembers.
Out: findings ranked by severity, with pull requests for the clear ones
Performance agent
Measures load times, slow queries and bundle size against the last baseline, and traces any regression back to the change that caused it.
Out: a regression report, and a fix where the cause is clear
Upkeep agents
Hunt for critical bugs, raise test coverage where it is thin, keep the changelog and the documentation in step with what actually shipped.
Out: small pull requests that keep the product healthy
04 · One way out
Everything ends in a pull request.
Whatever started the work, the result is delivered the same way. One place to see what changed, and one quality process that everything passes through.
Why
Control isn't one person reading every line. It lives in how the work is organised: every change arrives with tests and a reason, every change is reviewed, and every change can be traced. That holds whether five agents are running or fifty.
- 01TriggerAn error, a ticket, a usage signal, or the clock.
- 02Pull requestThe agent delivers the change with tests and its reasoning.
- 03ReviewThe pull request itself wakes the review agent.
- 04FixSafe findings are corrected in the same pull request.
- 05MergeAutomatic when nothing needs a human judgement.
If there is any doubt, it stops with a person.
Where that threshold sits is something we set on purpose, and it is not the same everywhere. A copy change can go straight through. Anything touching payments, permissions or customer data waits for one of us. What can't be verified automatically is exactly what we spend our own time on.
And a change isn't done when it's merged. It's done when we know whether it worked. Errors and performance are followed in production, usage in the product data, and what we see there becomes the next trigger. That is the loop on the philosophy page, seen from the engine room.