An AI Workflow Adoption Register: Measuring What the Business Actually Runs, and Which Workflows Deserve a Playbook
Two read-only miners on two separate record sets produced a finding neither could produce alone: the two most-adopted AI workflows in the business had no written playbook, and the single most repeated one was being re-solved from scratch on nine accounts, differently every time.
What was getting in the way.
An AI operation accumulates workflows faster than anyone writes them down. Ask "what do our agents actually do for us," and the honest answer is usually a guess assembled from memory. The catalog of written procedures is not the answer either: a catalog records what someone bothered to document, not what keeps getting done. The gap between the two is where operating entropy lives: the most valuable recurring work has no playbook, gets re-derived from scratch on every account, and picks up a different implementation (and different silent failure modes) each time.
Context
Universal. Any organization running AI agents across multiple accounts or projects accumulates undocumented recurring workflows; the register pattern measures the drift instead of guessing at it.
How the work runs.
- 01
Mine two independent record sets.
One read-only miner walked the project records (dozens of per-project state files), another walked the procedure catalog and daily operating notes. Disjoint sources, so each one checks the other.
- 02
Compute every count, type none.
All adoption counts in the register are computed from the underlying data file on every refresh. Nothing is hand-entered, so the weekly refresh cannot drift from the evidence.
- 03
Cross the two corpora for the finding neither holds alone.
The merge showed the two most-adopted workflows in the business had no written playbook, and the most repeated workflow of all, reconciling a revenue source of truth, was being re-solved from scratch on nine accounts with a different join key every time, carrying a silent failure mode. The catalog alone would have missed this completely.
- 04
Read the inverse, for free.
About a third of the written procedure catalog had zero recorded runs, and most of that shelfware arrived in one imported bundle rather than growing from a real job. Everything heavily used was grown, not imported.
- 05
Route the judgment calls to a human, and refresh on schedule.
Which engagements count as active, whether sub-brands count separately, and which uncodified workflow gets the first written playbook all went to a human with a recommendation on the record. The register now refreshes weekly, and a later refresh recorded the loop closing: the first playbook ever written specifically to close a gap the register itself had flagged.
Evidence from the workflow.
Each system has a role.
intake (what work actually recurs, account by account)
Project state records
intake (what has been written down, and what has zero recorded runs)
Agent procedure catalog
record of truth (computed counts, never typed)
Register data file
action (the standing rebuild that keeps the register honest)
Weekly refresh job
Why this is Operator.
Owns a workflow end to end, running the process inside the authority you set.
- 01
Both miners are read-only. The register distinguishes computed facts from inferred entries, and entries resting on thin evidence are flagged rather than counted silently. Roster judgment calls (what counts as an active engagement) belong to a human, with the agent's recommendation recorded beside the decision.
Impact / Outcomes
The business got a measured answer to "what do our agents actually do," with every count computed from records instead of recalled in a meeting.
The highest-value documentation gap became specific and actionable: the most repeated workflow had no playbook and a different implementation on each of nine accounts, which is nine chances for the same silent failure.
Shelfware became visible as a category with a cause: unused procedures were overwhelmingly imported, not grown, which changed how outside bundles get adopted.
The register closed its own loop: a subsequent weekly refresh recorded the first playbook written specifically because the register flagged the gap.
Find where a workflow like this fits.
Start with the systems, work, constraints, and authority already present in your operation.