For organizations using standardized, cost-visible agent workflows across multiple squads, under what conditions does strict enforcement that all production-like coding work must go through cataloged workflows (no ad-hoc prompts in generic chat) actually improve pilot-to-scale adoption and governance, and when does it backfire by pushing developers to off-platform or shadow tools—i.e., where is the threshold beyond which governance rules start eroding rather than reinforcing durable adoption?

Answer

Strict “catalog-only for production-like work” improves adoption and governance when it is workflow-centric, noticeably safer/easier than alternatives, and leaves clear space for sanctioned experimentation. It backfires once rules are experienced as blocking real work faster than they reduce real risk. A rough threshold: when more than a small minority of squads feel they must bypass the catalog to meet delivery or quality expectations, strictness starts eroding rather than reinforcing durable adoption.

In-scope conditions where strict routing helps:

• Catalog coverage: most common production-like tasks have at least one acceptable workflow; new gaps are filled in weeks, not quarters.
• Experience quality: catalog workflows are reliable, well-documented, and usually better than generic chat (fewer errors, better context handling, clearer logs).
• Governance posture: enforcement is framed and reviewed at workflow/portfolio level, with clear incident/cost rationales, not as individual policing.
• Experiment channels: squads have lightweight ways to try variants (shadow catalog, exploration budgets) and promote them into the main catalog.
• Cost handling: token visibility and budgets live at workflow/portfolio level; high-cost runs that match approved use cases are explicitly “safe.”

Conditions where strict routing backfires:

• Coverage gaps: many real production-like tasks have no usable workflow, and adding one is slow or politically hard.
• Inferior UX: golden workflows are slower, more brittle, or less flexible than generic chat; retries and overrides are common.
• Person-level pressure: leaders treat expensive runs as individual faults; dashboards feel like squad scorecards.
• Blocked innovation: shadow catalogs or variants exist but are hard to promote; override spikes and local forks are common but not acted on.
• Shadow migration signals: growing off-platform use, rising generic-chat usage tagged as “exploration” for clearly production work, or squads quietly disabling tooling.

Threshold indicators that strictness has tipped into harm:

• Metrics: sustained override spikes, stalled promotion of new workflows, high-cost modes unused despite clear need, and large outcome-adjusted spend gaps between squads that governance pushes to equalize.
• Behavior: more work done in untracked tools, repeated requests for exceptions, retro feedback about “approval pain” or “token anxiety,” and leads steering critical work away from agents.

Below this threshold, strict routing acts as a scaffold: it concentrates learning in shared workflows, stabilizes costs and incidents, and supports durable adoption. Beyond it, developers treat rules as obstacles, adoption plateaus or declines, and governance loses legitimacy until it is relaxed and re-centered on workflow value and experimentation.