Context
Tumble is a two-sided marketplace: on one side, customers who want their laundry picked up, washed, and returned; on the other, independent contractors — "Super Washers" — who run the loads out of their own homes. Like every two-sided marketplace, the business only works when both sides show up in the right numbers, at the right times, in the right places. Too many washers and nobody earns enough. Too few and orders go undelivered.
For years, this was a daily human decision. A marketing manager would look at yesterday's order volume, peek at how many washers were scheduled for tomorrow, and pick from a menu of interventions: run a push notification with a bag credit, text the washers about guaranteed-earnings offers, bump prices in a specific market, send a re-engagement email. There was a spreadsheet. There was a morning meeting. There were a lot of instincts that couldn't quite be explained.
It mostly worked. But it was fragile, slow, and it couldn't possibly scale past the hours a human could look at the dashboard.
The challenge
We wanted the decision to stop living in a meeting.
A marketplace balancing problem is a natural fit for an autonomous agent — but "natural fit" is a long way from "working system." The real problems were:
- Forecasting demand well enough to act on it. A sloppy forecast gives you sloppy interventions. A good forecast in isolation gives you nothing unless it's wired directly into the decision loop.
- Knowing what the current supply actually looks like. Washers schedule themselves. Schedules change. Shifts get dropped. The ground truth is moving all the time.
- Picking an intervention, not just noticing a gap. There are four different levers we can pull, each with different costs, different latencies, and different downstream effects. A model that tells you "supply is low" without telling you which lever to pull is just a more expensive dashboard.
- Doing all of this continuously, without a human in the loop, without melting the marketplace down if something weird happens.
The approach
We built an orchestrator agent that runs continuously. Its job isn't to make predictions — its job is to close gaps. It reads three things on every tick: the forecasted demand for the next window, the scheduled washer supply for that window, and the current state of any interventions already in motion. When the gap between demand and supply crosses a threshold, the orchestrator picks an intervention.
The orchestrator doesn't do the intervention itself. It delegates to sub-agents, one per lever, each of which knows how to actually execute and how to report back:
- A guaranteed-earnings sub-agent that pushes a time-bounded offer to washers in the affected market.
- A washer outreach sub-agent that composes and sends SMS to washers we think are likely to accept a shift.
- A pricing sub-agent that adjusts surge on the demand side within pre-approved bounds.
- A demand nudge sub-agent that pushes targeted nudges to customers whose usage patterns suggest they were close to ordering anyway.
Each sub-agent reports back its effect — how many washers signed up, how many customers converted, how the underlying supply/demand curve moved. The orchestrator uses that feedback on the next tick, so the system gets steadily better at picking the right lever for the right gap.
What we built
A Python service running on our existing infrastructure, talking to our existing data warehouse and our existing messaging stack. No new vendor. No standalone platform. A single long-running orchestrator process, four sub-agents as separate modules, and a small set of tables for decision logging and rollback.
The human operators didn't disappear. They moved up one level. Instead of deciding which intervention to run today, they review the orchestrator's decisions after the fact, approve or tune the thresholds, and spend their time on the problems the agent is still too new to handle.
The outcome
The daily meeting went away. The spreadsheet went away. The interventions that used to happen once or twice a day now happen continuously, at whatever cadence the marketplace actually needs. The variance in order fulfillment smoothed out. The team got their mornings back.
Decision levers
4
Cadence
Continuous
More importantly, the system is something we can trust. We know what it's doing. We know why it's doing it. We can turn any piece of it off without turning the whole thing off. And the operator team — the humans who used to make the decisions — are still in the loop, just on different decisions.
What's different now
This was the first of roughly a dozen agents we shipped at Tumble. It wasn't the flashiest — the churn intervention engine arguably changed more numbers, and the maintenance dispatch pipeline replaced more manual work. But the marketplace balancer was the one that taught us the most about what it takes to actually hand a real business decision to an autonomous system and trust the result.
What we learned there is most of what Clarified Consulting is built around. Three things in particular:
- The orchestrator + sub-agent pattern is more robust than any monolithic approach we tried. Every sub-agent is small enough to reason about, audit, and turn off.
- The humans don't leave. They move up a level. The people who used to run the decision now review it, tune it, and handle the exceptions. Their job gets more interesting, not smaller.
- Shipping it inside your own business first changes what you build. When the system is running your own payroll and your own customer experience, you make different choices than when it's a demo.
If you're trying to solve a problem that looks like this one — a recurring business decision that lives in a meeting and needs to live somewhere else — let's talk. The first conversation is free.