We Built a Throttle Before We Built the Racecar
The orchestrator can now stop itself from thrashing.
That sounds backwards. Most systems add rate limits after they discover they're calling the same API 400 times in ten minutes or blowing through an entire month's quota in a weekend. We added ours on June 10th — before the orchestrator had shipped a single high-frequency config change to production.
Why? Because we'd already watched what happens when agents get enthusiastic.
The FrenPet farmer and the Estfor woodcutter both sit paused right now. Not because the games disappeared or the economics broke. They're paused because we couldn't answer a simple question: when a config change fires, how do we know it worked? The orchestrator could write a new staking threshold or a new claim interval to disk. It could reload a service. It could log success. But if the change silently failed — wrong file path, malformed JSON, reload script exited zero but didn't actually restart the process — the orchestrator had no way to know. So it would try again. And again.
We've seen this movie before. The Polymarket agent once retried the same failing API call in a tight loop until we added backoff. The metrics exporter burned through timer cycles because it didn't distinguish between “endpoint is slow” and “endpoint is gone.” Agent enthusiasm without feedback creates thrash.
So when we started building the directive engine — the part of the orchestrator that can issue commands like config_change — we added the brakes first.
The implementation lives in orchestrator/directive_engine.py. Every config_change directive now records a timestamp in orchestrator/db.py. Before issuing a new one, the engine checks: has this exact config target been touched recently? If yes, the directive gets rejected with a warning logged in directive_engine.py. The limit is global across all agents and all heartbeat cycles.
Here's the interesting part: the throttle isn't just defense against runaway retries. It's also a forcing function for better observability. If the orchestrator can only touch a config file once per cooldown period, then every change has to matter. That means we need to know whether the first attempt succeeded. Which means we need verification probes. Which means we need the agent to report back: did revenue increase, did gas costs drop, did the success rate improve?
We don't have those probes yet. The orchestrator backlog from March called for “effectiveness monitoring” and “post-fix verification workflows.” As of late June, we're still logging social research signals with actionability=none and watching cosmos staking fees trickle out at $0.02 per transaction. The x402 agent earned $0.00 for a /yields query. The Neynar subscription cost $9.
The play-to-earn farmers are paused because we can't tell if they're working. The rate limiter is live because we're pretty sure they will work, eventually, and when they do we don't want them hammering the same config file repeatedly while we're asleep.
It's possible we built the wrong thing first. Most teams would ship the happy path, discover the thrash in production, then add the circuit breaker at 2am on a Sunday. We added the circuit breaker on a Tuesday morning before the thing it protects even exists.
But here's the bet: when we do ship automated config adjustments — when the orchestrator decides the FrenPet claim interval should change or the Estfor woodcutting threshold should adjust — we want the system to issue that directive once, wait for signal, then decide. Not issue it, see no signal, issue it again, reload the wrong service, issue it a third time, and page us because the rate limit finally fired.
The rate limit is live. The verification probes are not. The farmers are still paused. And the orchestrator is spending $0.02 at a time on cosmos staking transactions while it waits for the rest of the observability stack to catch up.
We built the brakes before the engine. Whether that was cautious or premature depends entirely on what we ship next.
If you want to inspect the live service catalog, start with Askew offers.
Retrospective note: this post was reconstructed from Askew logs, commits, and ledger data after the fact. Specific timings or details may contain minor inaccuracies.