Five ideas explain everything PowerExecutor does.
PowerExecutor doesn't run workflows — it runs a loop, once per cycle:
Observe → Understand → Prioritize → Act → Verify → Reflect
A bounded picture of the product — not "complete". Every fact carries a timestamp, a source, and a confidence, and missing knowledge is recorded as an explicit unknown rather than guessed. If a signal can't be observed, the cycle degrades gracefully instead of inventing state.
Everything the operator can do to a product is a capability — publish a post, send a broadcast, update content. Capabilities live in a declarative adapter spec (a YAML file) that maps each one to the product's real API, and declares its risk and how to undo it:
| Reversibility | Meaning |
|---|---|
reversible | Prior state is captured and can be fully restored. |
compensable | Can't restore exactly, but a compensating action mitigates. |
irreversible | No meaningful undo (e.g. a sent email) — always needs your approval. |
Trust isn't granted by a flag — it's earned. Every capability sits at one of three levels:
Shadow simulates the action (dry-run only, never touches the product) Recommend proposes the action and waits for your approval Autonomous acts on its own
New capabilities start at Shadow. Three consecutive clean outcomes promote a capability one level; any failure demotes it and resets the streak. You can also promote or demote manually. Irreversible capabilities stay approval-gated at every level.
Hard limits wrap the whole loop: