We didn't hire an ops team. We built one — out of agents, sagas, and a lot of small, well-defined tasks.
People are often surprised by how small our team is for what we run — a commerce platform serving real merchants, with real money flowing through it, every day. The honest answer to 'how?' is that a large part of our operations isn't done by people at all. Over the last year we've built what we call an AI ops layer: a control plane of agents that pick up the repetitive, well-defined operational work that used to quietly eat our days.
I want to be precise about what this is, because 'AI ops' could mean almost anything right now. This isn't a chatbot bolted onto a dashboard. It isn't a model guessing at production changes. It's a set of narrow, scoped operators, each with a specific job, a clear definition of done, and a complete record of everything it touched. Think less 'magic robot' and more 'a very diligent junior operator who never gets bored and never forgets to write it down'.
What the agents actually do
The work we've handed off is exactly the work that's too important to skip and too repetitive to enjoy. It's the stuff that, in a bigger company, you'd hire an operations team to grind through — and that, in a small company, simply doesn't get done consistently because everyone's busy building.
- Triage and group incoming errors before a human ever looks at them.
- Run routine data and configuration checks across tenants on a schedule.
- Draft and verify fixes for known classes of CI and integration failures.
- Keep operational records and trackers up to date without manual data entry.
- Escalate to a person — with full context attached — only when judgement is genuinely needed.
That last point is the one that matters most. The goal was never to remove humans from the loop. It was to make sure that when a human does get pulled in, it's for something that actually needs a human — a real decision, a genuine ambiguity — and that they arrive with the full picture already assembled instead of starting from a blank page at 11pm.
Executor-agnostic, saga-shaped
The design decision that makes this safe rather than terrifying is treating every operation as a saga: a sequence of discrete steps that can be tracked, retried, and rolled back. The agent proposes and executes steps, but the tracker — not the agent — is the source of truth about what happened. So the system is auditable and recoverable by construction, rather than a black box that occasionally does something clever and occasionally does something you can't explain.
It's also executor-agnostic, which is a slightly nerdy way of saying we don't care whether a step is carried out by an agent, a script, or a person — the tracker records it the same way. That flexibility means we can automate a step when we trust it, and pull it back to a human the moment we don't, without rebuilding anything.
“Automation isn't about removing people. It's about removing the work that didn't need a person in the first place.”
Why this matters if you're a merchant
You will never see this layer, and that's exactly the point. It's the reason a tiny team can keep the platform reliable, ship quickly, and still answer your support questions like actual humans — because the humans aren't buried under operational busywork. The capacity we get back from automation goes straight into the things you do feel: faster fixes, faster releases, and a team that has time to actually talk to you.
Where this is heading
There's a longer arc here, too. Almost everything we've automated for ourselves is, eventually, something we can hand to you. The operational patterns we've proven on our own infrastructure — the checks, the saga-style recoveries, the auto-triage — are a preview of capabilities that will, over time, show up inside the product itself. We're building the ops team we wished we had. The interesting part is that, increasingly, our merchants get to borrow it.
