The agent system took 389 of 689 sessions in the first three weeks of September. That is 56.5 percent. The product that earns the money took 183, or 26.6 percent. BizOps took 63 sessions, 9.1 percent, and the blog took 9, 1.3 percent.
The audit says the goals were clear on paper: the product that earns the money comes first, and the agent system is a multiplier only. On September 21st an audit checked the goals against the work, and the picture did not match.
One caution on the numbers before the story. These are session counts from the manifests, and the count includes sessions we dispatched from other sessions. It is not hours. The commit counts told the same story from another angle: 1,319 non-merge commits across the tooling repos against 712 across the repos that earn money. The multiplier absorbed nearly twice the commits of the income side, and agent system was the largest area in every one of the three weeks (61, 47 and 59 percent).
The audit’s own conclusion was that nothing at the point where work gets picked enforces the goal. Per the audit, entry is a generalist session choosing among many overlapping skills, the agent system has no intake budget, and every tooling friction met during income work becomes its own agent-system session.
Writing the priority down was not the same as enforcing it. A goal document is a statement of intent. It does nothing at the moment a session decides what to work on next. The audit found 333 sessions, 48 percent, with no task attached at all.
The audit proposed a fix at the point of pickup. Tooling friction met during income work becomes a one-line note, batched into a fixed agent-system slot, unless it blocks the ticket in front of us. That was a proposal waiting on our decision when the audit was written, not something running.
The lesson is narrow. A goal that is only written down does not steer the next pickup of work, so the check has to sit where work is picked.
AI Skills
Use this lesson with the AI assistant you already use
An audit of 689 sessions found 56.5 percent in the agent system, the part written down as a multiplier only. Nothing at the point where work gets picked enforced the stated priority.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: A Written Priority Does Not Steer Work Unless The Check Sits Where Work Is Picked
SOURCE: dxdev.com/blog/goals-drift-when-nothing-enforces
WHAT HAPPENED: An audit of 689 sessions found 389 of them (56.5 percent) in the agent system and 183 (26.6 percent) in the product that earns the money, although the written goals put the product first. Commits showed the same lean, 1,319 on the tooling side against 712 on the income side. The audit found no check at the point where work gets picked, and proposed batching tooling friction into a fixed slot unless it blocks the current ticket.
THE RULE: A priority that exists only in a document does not decide what gets picked next. Put a check or an intake budget at the point where work is chosen, and measure the split from your own work log.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Something at the point where work is picked compares the candidate against the stated priority split, and does not rely on a goals document being read.
2. The share of work per area is measured from real records (sessions, commits), and the measure says whether it counts sessions or hours.
3. Tooling friction found during priority work has a defined place to go that does not start a new unplanned work session by default.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
