01
Kill switch is the orchestrator's primary instrument
Operator-owned. One flag per store stops every write and spend job from starting, while read-only ingestion, reporting, and alerting keep running so you keep eyes.
// for ops leads
One spine. Every external write. Every guardrail.
Magistry is the orchestrator your ops team has been hand-rolling in spreadsheets and cron jobs. Kill switch, per-action rate limits, advisory locks, evidence-tier gates, a per-lever trust ramp that earns autonomy slowly and loses it fast, immutable decision_log. Built in. Built right.
Operator-owned kill switch Postgres advisory locks LLM budget caps per tenant
// why ops leads pick magistry
The control plane your stack diagram has been a stand-in for.
You've already sketched this on a whiteboard: an orchestrator with switches, rate limits, locks, evidence gates, and an audit log. Magistry is that diagram, shipped.
02
Per-action rate limits, not vibes
1/24h per SKU price change. 3/h per ad-group bid change. 50/d outbound CS. Limits live in policy; orchestrator enforces them before the mutation, not after the explosion.
03
Advisory locks so two agents don't fight over one row
Catalog Specialist and Campaign Specialist both want to touch the linen blazer SKU? Advisory locks serialize the writes. No race conditions. No double-spends.
04
Immutable decision_log — your audit trail, not a log file
Every external write, every reverse op, every gate decision. Postgres-native, queryable, exportable. The diff your auditor, your CFO, and your platform reps all want.
// this week
What the orchestrator did for your fleet this week.
One spine. Six tenants. Every external write held to the same set of rails. An illustrative week on a multi-tenant Magistry install.
- Enforced 11,402 rate-limit checks across catalog, campaign, and CS — held back 47 mutations that would've breached a per-action cap, queued for the next window.
- Acquired 8,914 advisory locks; resolved 213 contention events with deterministic serialization — zero double-writes, zero stale-state mutations.
- Logged 84,217 decision rows across 6 tenants with reverse ops attached — exported on Friday's auditor request in 12 seconds via the decision_log API.
// from your dashboard
One agent run. Every gate visible. Every write conditional.
Below: the full guardrail trace on a price change — kill switch, rate limit, advisory lock, evidence tier, LLM budget cap, mutation, reverse op.
orchestrator trace ── run #84,217 ───────────────────────────────── [gate] kill_switch store=lh : OFF — writes allowed [gate] rate_limit 1/24h per sku: PASS (last 27h) [lock] advisory store=lh : ACQUIRED [gate] cost_tier required : A [gate] cost_tier observed : A (cost_per_item) [gate] margin_floor : PASS (11pt headroom) [gate] llm_budget monthly cap : 84% used — ALLOW [plan] planner: discount_test -€6 [judge] judge: PASS (tier A + margin floor) [exec] mutation shopify.variantUpdate -> OK [log] decision_log row written (status=applied) [lock] advisory store=lh : RELEASED [done] revertible: restore PRICE -> €148.00 (derived from action)
// what you actually do
Set policy once. Watch the gates do the rest.
You don't sit in the trace. You set the policy file — rate limits, evidence tiers, budget caps — and let the orchestrator hold the line for every agent, every tenant, every night.
otto: 47 mutations held this week by rate-limit policy · view held queue →
// the safety rails
The guardrails you'd otherwise hand-roll — built in.
The rollback button, the kill switch, the advisory locks, the per-action rate limits — the kind of safety rails an ops lead usually hand-rolls in Postgres — come built in. That's the difference between a workflow tool you tolerate and one you trust to write.
// one spine, all writes
Stop hand-rolling the orchestrator. Adopt the one with the rails.
Spin up a tenant, point Magistry at your stack, and replace the cron jobs, the lock tables, and the half-built audit views with a single decision spine.
Operator-owned kill switch · Dry-run from day one