Per-key scopes rolling out
Narrow what a single key can reach — which providers, which operations. Scopes are in preview: they are recorded and shown today, and enforcement is being switched on key class by key class rather than in one flip.
Platform / Governed
Budgets that actually stop.
Autonomy is only safe if the limits are real. The failure everyone fears with an agent swarm
is the one that shows up on the invoice: work that ran past a cap and told you afterwards.
swarmsDB enforces the spend limit where the request is served — so the cap is a wall,
not a line in a report you read the next morning.
402 Payment Required The enforced control
An org budget is a wall on the serving path.
When an organisation is over budget, the next request gets a real
402 / 429 — not a silent truncation, and not a line in a nightly report.
Enforcement lives on the path that serves the data, not in a batch job, so an autonomous
swarm cannot spend past the cap and leave you to discover it later.
Data residency enforced
Pin a workspace or a key to a region, and requests are resolved and served within it. Residency is enforced on writes and on the hot path, and a residency lock is immutable once set — you cannot silently widen where data may live.
Stated precisely on purpose: the wall that stops overspend today is the org budget. The finer per-key controls above are the honest state of each — described as what they do now, not what they will do once every flag is flipped.
Point one agent at it.
Connect over MCP or REST. If your agents read more than one source, the context bill is the first thing you will see move.
Measured on our own agent-swarm workload. swarmsDB is battle-tested, not yet widely adopted — external traction is the next milestone.