Bayesian build-outcome confidence

Bayesian build-outcome confidence assigns each plan step a prior probability of succeeding (derived from features of the change — files touched, test coverage of those files, recency of related failures) and updates that posterior every time the build pipeline returns a verdict. The agent reads the posterior and either proceeds, pauses for review, or rebatches the step.

The prior comes from features of the step itself: number of files touched, test coverage of those files, whether the AUTO-TABLE row for the affected entity changed recently, and the historical failure rate of similar steps in this repo. Every PostToolUse build verdict is an observation; the posterior update is a beta-binomial — cheap enough to run inside a hook. The thresholds are operational: above 0.9 the agent proceeds, between 0.6 and 0.9 it batches the step with its dependents so one build verdict covers them, below 0.6 it pauses for review before spending the tokens.

The closest adjacent prior art is build-failure prediction in CI: USPTO patent 10,684,851 (“predicting build failures”) and AutoStan both model failure probability from change features. The difference is where the number goes — CI predictors route human attention after the fact; build-outcome confidence feeds the agent’s own scheduler before the step runs.

When to use

• Agentic sessions across solutions large enough that build-test cycles cost more than a few seconds.
• Greenfield features touching multiple subsystems, where ordering plan steps by confidence shortens the loop.

Compare with

A static plan-step ordering picks once and commits. Bayesian build-outcome confidence reorders based on evidence — closer to a runtime scheduler than a planner output.