Wicked Evolutions Knowledge Docs

The pacing rule is the single most important behavioral constraint in the Abilities API ecosystem. It governs how AI agents consume information — not how fast they call abilities, but whether they actually process what comes back before moving forward.

The Rule

Why It Exists

AI agents have a natural tendency to batch operations — fire five ability calls, then summarize the results. The problem is that each result changes the mental model. When you skip processing step 2’s result before calling step 3, you’re building step 3’s request on assumptions instead of data.

The result is confident-sounding reports built on unread data. The agent says “the site has 3 custom post types” but never actually checked — it assumed from the plugin list. This is not a performance problem. It’s an accuracy problem.

The pacing rule was discovered, not designed. It emerged from watching agents produce hallucinated diagnostic reports during the Initial Read Protocol’s development. The fix was not better prompts — it was enforced pauses between observations.

When It Applies

• Diagnostic protocols — Initial Read, Health Check, Content Structure. Every step is a doorway you walk through, not a corridor you’re pulled through.
• Unfamiliar sites — any site you haven’t operated before. Your model starts empty; each ability call fills it. Skip processing and the model has gaps.
• Investigation tasks — when someone asks “what’s wrong with this site?” Rapid-fire calls produce rapid-fire assumptions.

When It Doesn’t

• Known workflows — if you’re executing a documented SKILL on a site you’ve already read, parallel calls are fine. The model is already built.
• Write sequences — creating a post then assigning taxonomies then setting a featured image. These are sequential dependencies, not diagnostic reads.
• Batch operations — content/batch-update exists precisely for cases where you know what you’re doing and want to do it fast.

Related