Prioritized operability this week. If this system can not be run safely by a small team, it will not be adopted no matter how clever the policy engine is. Operations is not a feature you add later. It is a constraint you design around from the start.
Added kill-switch framing so operators can stop the world when something goes wrong. Not "gracefully drain over 30 seconds" but actually stop. Every action pauses. Every pending execution freezes. The operator investigates, fixes the issue, and then resumes. This is table stakes for anything that controls real-world actions.
Wired rate limiting concepts into the control plane path. Not just throughput limits but semantic limits. "No more than 5 financial transactions per minute" is different from "no more than 100 requests per second." Both matter.
Started building out metrics framing: allow rates, review rates, block rates, top block reasons. If you are running this in production, you need to know at a glance whether the system is behaving normally or if something shifted. A sudden spike in block rate means either your policy changed or your agents changed. Either way, you want to know immediately.
The receipts viewer becomes more important as volume grows. When you are processing 10 actions a day, you can read every receipt. When you are processing 10,000, you need search, filters, and aggregation.