How ShareWell uses Maestro.

A fintech with one directory tree.

ShareWell builds accounting and asset-management software for Australian fund managers. Customers use a SvelteKit web application. Behind it sit Python APIs, core-api chief among them, built on an in-house framework called huracan.

All of it lives in one directory tree of roughly 35 repositories: the two main products, the auth service, reporting tools, data pipelines, internal libraries. That tree is what Maestro conducts. Only the app and core-api have dev servers worth launching; the rest are workspaces agents read and edit.

Five tools, until the work was in the product.

The tracking did not start here. We began on Linear, and two engineers quietly stopped opening it: it was fiddly, easy to forget, and the board drifted from reality until it was worth less than nothing. We moved the plan onto a Figma whiteboard, which was better in one way, because the plan sat right beside the meeting notes and we crossed things off in place. It was worse in another, because tasks slid off the edges and were never seen again.

Then most of the real feedback started arriving over WhatsApp, where it got buried in the thread and was hard to act on directly. The fix was to stop asking anyone to open a separate tool at all. We built the tracker into the accounting software our customers already use, so a user reports a problem from the page they are on and watches the same board we do. Direct feedback from inside the product is the part everyone ended up loving, and the backlog finally reflected the work.

That backlog grew past a hundred open tasks, and that is what led to Maestro. We did not want to drive a fleet from Codex or the Claude console and take the output on trust. We wanted to sit above it: triage each task by hand, hand every agent a steer on how to approach it, read the diffs, and keep the merge in human hands. Maestro is the control plane for exactly that.

Everything lands in Tasks.

A crash in production arrives from Sentry with the stack trace attached. Action items from a Tuesday meeting become tasks before the call ends. GitHub issues sync both ways. When a user reports a bug from inside the app, the task records the page, the browser and the viewport they were on.

This matters for what comes next: an agent picking up a task cold gets the same context a human would want, without anyone writing a handover.

One button per task, or one sentence per project.

The operator opens the backlog and presses dispatch on a task. Maestro picks the target repo, creates a git worktree on a branch named maestro/<handle>, claims the task in the tracker and posts the plan as a comment. A fix that touches both the app and core-api gets a worktree in each repo, on the same branch name.

For bigger runs the operator talks to the orchestrator, a master Claude session with its own control API. Told "do every task in project X", it lists the backlog, dispatches workers, answers their questions and keeps eight to ten in flight. It is briefed to delegate rather than code, and it cannot merge.

Branches queue for a human, graded.

Finished branches land on the triage board. Each arrives with a report card: a short summary, a risk level, and scores for correctness, clarity, test coverage and risk. The card is generated by a read-only Claude pass over the worktree, alongside plain git stats.

To see the change run, the operator starts dev servers inside the agent's worktree. Maestro allocates the ports and clones the env, and the traces flow to one otel-lgtm dashboard under the agent's own service name. Questions go to the agent in chat; it is the same conversation the agent has been working in all along.

Maestro merges. The history shows a human decided.

When the operator approves a branch, Maestro performs the merge. Not the agent, and not a script the agent controls. Maestro commits the worktree, merges --no-ff into main, deletes the worktree and branch, archives the agent and closes the task.

Mergeability is checked up front with git merge-tree, in memory, before anyone reads a line of the diff. A branch that conflicts with main is flagged on the board before it can waste review time.

Releases are mechanical.

Every repo uses conventional commits, so cutting a release requires no judgement. releaser reads the history, bumps the version, writes the changelog with git-cliff, tags, pushes and creates the GitHub release. One command, same behaviour for a human, a CI job or an agent.

When a release goes out wrong, releaser undo removes the commit, the tag and the GitHub release in one step. Maestro itself is released this way.

The bottleneck moved. It did not vanish.

Parallelism does not make review free. One operator can clear maybe a dozen branches an hour before the reading blurs, so throughput is capped by the seat, not the agents. The report card buys you triage order, not a diff someone else has read.

The costs are ordinary ones. Thirty-five repos times eight agents is a lot of worktrees and a lot of dev servers; ports run out before memory does. Agents still stall on tasks nobody scoped, and a task a human could not write a plan for is not one an agent rescues. Maestro makes the clear task fast. It does not make the vague task clear.

A fleet instead of a queue.

The working target is under 30 open tasks on the app, held by one operator. The way there is parallelism with a narrow waist: many agents writing, one human deciding, one system recording.

The tracker stays accurate because no person is asked to keep it accurate. Attribution is honest because bots are named actors, so work done by claude is signed claude. And the merge history of main is a sequence of human approvals, each one logged.