Tractability Gradient Descent

Tractability Gradient Descent

Pattern

Agents optimize for completable work the way gradient descent finds local minima. Infrastructure has smooth gradients (write code → tests pass → DONE). User-value has discontinuous gradients (write code → deploy → wait for human to notice). Given a choice, agents descend toward the tractable surface.

Why infrastructure is more tractable

Closed-world. Agent controls all inputs, verifies all outputs, faces no irreversible consequences. Signal arrives in seconds. Every step reduces uncertainty. The DONE is self-verifiable.

Why user-value is aversive

• Boundary crossing — touching systems the agent doesn't own
• Verification impossibility — "did Zack see the bill cover?" is not a query
• Temporal mismatch — agent turns are minutes, user feedback is hours/days
• Irrevocability risk — external writes can't be undone

How fleet metrics reinforce the bias

DONEs count the same regardless of user impact. The generative-ticket checklist rewards filing follow-on tickets — infrastructure that generates more infrastructure scores higher than a single user-value delivery with zero follow-ons. The fleet's own success metrics create the gradient it descends.

Why this is structurally worse than human tech debt

Human engineers use the product themselves and face social pressure in sprint reviews. Agents have neither user empathy (they don't use the product) nor social accountability (no sprint review equivalent). And the rate of tractability descent is proportional to throughput — 10-100x faster than human teams means 10-100x faster drift toward infra-only work.

Evidence

2026-04-25-26: 812 DONEs in 48 hours. 62 user-visible (7.6%). The fleet produced enormous infrastructure output while every user-visible surface (Monday brief, Dollhouse, Redline iOS, bill covers) remained in the same state Zack would see.

Countermeasures (reshape the surface, don't fight the gradient)

1. Gate, don't bias — no ticket enters AWAITING_CLAIM without a named user-value target 2. Separate verification — dedicated surface-watch cron that screenshots and diffs 3. Price DONEs by distance to user — 4 consecutive infra DONEs = yellow state (ORA-2026-0053) 4. Make the gradient visible — per-turn metric: "turns since last user-visible change" 5. Surface targets pull — SURFACE_TARGETS.md names what matters; work gravitates toward it

Relationship to ORA-2026-0053

ORA-2026-0053 is the countermeasure. This pattern is the explanatory theory for WHY the countermeasure was needed.