AI Operating System with agents for dropshipping.
We were building an AI back office for Google Ads dropshippers. Support triage, live profit and loss, feed and trend watching. What we actually had was a dashboard with cron jobs behind it. A week before launch we threw the architecture away and rebuilt it as an agent harness. Everything we had bolted on until then was throwaway work, and pretending otherwise would have cost more later.
Every capability is its own agent.
An agent here is a system prompt, a skill set, and the tools it is allowed to touch. An orchestrator decides which one gets the job and hands work between them. The upside is boring and large: adding a seventh capability means writing a file, not rewiring the product.
Nothing spends money on its own.
Every action an agent wants to take lands in one inbox first. The owner sets the line per workspace: approve everything by hand, or let it run inside limits you set. Auto-run is a choice somebody makes, not the default we ship.
Inbox
4 waiting · 1 blockedbelow the €35 CPA floor you set · reversible
order numbers pulled, tracking checked · you read them first
drill: day → product → order
outside guardrail — will not run, approved or not
One inbox for every agent · approval-first is the shipped default
The bottom row is the one that matters. A guardrail is not a warning you can click past. If an action sits outside the limits the owner set, approving it does nothing.
Two agents out, one a month after.
The runtime is deliberately not tied to one model provider. The same agent definition runs on either, and we pick per job on cost and speed. That decision took an afternoon and has already paid for itself twice.
Thin product, thick plumbing.
Most of the work is not the interface. It is OAuth that survives production, a schema that holds a member's whole account, and the guardrail layer that sits between a suggestion and a live campaign.