01
Kill switch is the orchestrator's primary instrument
Default-on. One toggle freezes every agent across every tenant. Per-agent and per-action sub-switches let you keep the lights on where it matters and stop where it doesn't.
// 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, immutable decision_log. Built in. Built right.
Kill switch default-on 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. Numbers below are real from a live 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 tenant=lh : OPEN [gate] kill_switch agent=catalog: OPEN [gate] kill_switch action=PRICE : OPEN [gate] rate_limit 1/24h per sku: PASS (last 27h) [lock] advisory sku=linen-blzr : ACQUIRED [gate] evidence tier_required : A [gate] evidence tier_observed : A (cost_per_item) [gate] trademark filter : PASS [gate] uniqueness filter : PASS [gate] llm_budget tenant_daily : 84% used — ALLOW [plan] planner: PRICE_CHANGE -€6 [judge] judge: PASS (margin floor 11pt) [exec] mutation shopify.variantUpdate -> OK [log] decision_log #84,217 written [lock] advisory sku=linen-blzr : RELEASED [done] reverse_op pre-armed: PRICE -> €148.00
// 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 →
// what ops leads are saying
From an operator who threw away the cron jobs.
“We tried five workflow tools before Magistry. It's the only one we trust to write — and the rollback button is the reason. The kill switch, the advisory locks, the rate limits — these are things I used to hand-roll in Postgres. Now they're a checkbox.”
Sara Khan
VP Operations
Ember & Co.
// 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.
Kill switch ON by default · Dry-run from day one