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, a decision_log of every action. 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
One owner per field, so two agents don't fight over one row
Catalog Specialist and Campaign Specialist both want to touch the linen blazer SKU? Each field has one live owner at a time. A unique index in Postgres enforces it, so a second agent's claim on the same field is refused by the database and waits until the first releases it.
04
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 does for your fleet.
One spine. Every external write held to the same set of rails, on every store you run.
- Checks every write against its per-action rate limit, and holds back the ones that would breach a cap until the next window.
- Gives every change one owner at a time, so two agents never write over each other.
- Logs every action as a decision row with its reverse op attached, readable through the API when an auditor asks.
// 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: a write held by rate-limit policy is logged with the rule that held it · 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