The Countermoves: What to Do After You Name the Pattern

Countermoves
Countermoves

Diagnosis is only useful if it changes how the party moves through the dungeon.

The counter-moves are deliberately unglamorous. The glamorous moves, such as new frameworks, ambitious governance programs, and vendor partnerships, often create the conditions that produce the monsters in the first place.

A counter-move is smaller. It changes a decision before the decision becomes expensive.

Forecast at the scale of success

Ask what happens if adoption grows, context expands, retries accumulate, or agents call agents.

Do not model only the demo. Model the version of the workflow people will ask for after the demo succeeds.

That means looking at more users, more requests, larger inputs, more integrations, and more downstream actions. It means asking who pays when usage expands and who owns the workflow when it stops being an experiment.

Treat expansion as a decision, not as an automatic consequence of success. A successful test proves that something worked under particular conditions. It does not prove that more of it is wise.

Name an owner for every significant AI workflow. The owner does not have to perform every task, but someone must be responsible for the workflow's cost, behavior, review process, and shutdown decision. Without an owner, every problem becomes a committee discussion after the fact.

Separate experimentation from entitlement

Small groups should explore aggressively. That is how organizations learn what a tool can and cannot do.

The problem starts when experiment success becomes an automatic argument for expansion. A successful experiment earns a review at the new scale. It does not skip that review.

Define success before the experiment runs. Pick the metric, the threshold, the deadline, and the decision the result will trigger. If the experiment meets the threshold, what happens? If it misses, what stops? If the result is mixed, who decides whether to continue?

Ring-fence the budget. Keep the scope clear. Make the review a real meeting with a named owner, not a comment buried in a project document.

This is less exciting than saying the pilot "proved" the business case. It is also more honest.

Preserve competition and portability

Compare models deliberately. Do not choose based on rumor, conference afterglow, or one good week of vibes.

Define representative tasks. Run each candidate against those tasks. Evaluate the results using criteria that matter to the actual workflow: quality, latency, cost, failure behavior, and how much human correction the output requires.

Repeat the comparison on a schedule. The habit matters more than the first winner.

Portability is not a theoretical virtue. It is leverage. Vendors that face real evaluation have a reason to stay competitive. Vendors treated as destiny can raise prices after switching costs have been built into the workflow.

Keep the interfaces and prompts portable where practical. Avoid making one provider's quirks part of the organization's only way of working. You may still choose one vendor. Choose it with your eyes open.

Restore selection as a team sport

AI makes proposing work cheap. That is useful until the organization confuses a growing list of proposals with progress.

Reduce the number of active priorities. Make tradeoffs explicit. When new work enters the plan, name what comes off.

"Not now" is a selection. "We are not doing this this quarter" is a choice. "We are doing this later" is a hope unless someone has assigned it a place and an owner.

The Infinite Backlog Engine runs on hopes. It starves on choices.

A team does not need to justify every rejection with a long document. It does need to decide what matters enough to receive attention. AI can generate ten plausible directions before lunch. That does not make all ten worth pursuing.

Clarify authority before the crisis

Name who can stop a workflow. Name who translates technical risk into language finance or Legal can act on.

For each significant AI workflow, identify one accountable person, not a committee. That person may consult many people. They still need authority to pause the system, require a review, or reject an expansion.

Ask the uncomfortable question before anything goes wrong: who owns the worst case?

If the answer after an incident is, "We are still figuring out who owned that," governance failed before the incident.

The connecting principle is simple. AI does not remove the need for judgment. It increases the amount of judgment required because it makes action, output, and organizational self-deception cheaper.

The cost of generating a plan has collapsed. The cost of deciding whether the plan is worth executing has not.

That is where the counter-moves belong.

>