Strict Acceptance and Historical Inheritance Mechanisms

Once compute opens up candidate generation, a new challenge immediately follows:On what grounds can an automatically Agent-generated change be written into the project's main trunk?The strict acceptance and historical inheritance mechanism completely decouplesgenerationfromadoption—any code submitted by an Agent is merely acandidate patch, and it must first pass a set of verification gates before it qualifies to be recognized as part of the project's history.

Default-candidacy principle

Agent output is by default treated asuntrusted input: it is strictly isolated from accepted versions in permissions, storage, and references—it can neither read or write the trunk directly, nor be treated as a stable dependency by other modules. The sole purpose of this principle is to eliminate "generate-then-commit." Only after passing all gates does a candidate patch attain the same standing as the trunk.

Four-layer progressive filtering: escalating cost, early failure

Compilation: Buildable at the syntax and interface level. Lowest cost, fastest elimination—blocks obviously invalid changes at the door first.
Testing: Unit and integration tests pass, covering existing contracts.
Behavior check: Semantic and behavioral consistency, including numerical tolerances, equivalence, and regression comparison, specifically guarding against "tests pass but behavior drifts."
Upper-level acceptance: The final verdict oriented toward task goals and engineering constraints, covering judgments on performance, speedup, maintainability, and more.

Gates are ordered from lowest to highest cost, so the vast majority of invalid changes are cut off at the cheap stages, reserving the expensive upper-level review for a small number of high-quality candidates—this is precisely the economics of "fail early."

The value of rejection and historical inheritance

Failed attempts don't enter the trunk, but can be retained asfailure archives / negative samples, used for diagnosis, deduplication, and preventing repeated exploration—rejection itself is a round of noise filtering. Changes that pass acceptance become the newbaseline version, and subsequent executors continue evolving on this foundation, forming a monotonically accumulating evolution chain rather than starting from scratch each round. As the merge rule and quality contract for multi-Agent collaboration and recursive task decomposition, the acceptance gateway defines "who can write to history," thereby determining whether collaboration results in convergence or entropy increase. In scenarios with strong correctness constraints such as compiler refactoring and scientific software upgrades, this mechanism demonstrates extremely high reliability and delivers considerable runtime speedup.

Failure boundary

The completeness of the acceptance criteria itself becomes a new bottleneck: when test coverage is insufficient or behavior checks are missing, the gates will let through changes that "pass acceptance but are actually harmful." Therefore, observable metrics and manual spot checks are needed as a backstop, along with continuous reinforcement of regression cases and tolerance definitions.

Four-Layer Acceptance Gates and Candidate Isolation

In the diagram, Agent-generated changes are first isolated as untrusted candidate patches, then pass through four gates in sequence: compilation, testing, behavior check, and upper-level acceptance. The gates are ordered from lowest to highest cost, so invalid changes fail early at the cheap stages. Passers become new baselines inherited by subsequent work, while rejections are retained as failure archives and negative samples for diagnosis and preventing repeated exploration.

Question 1

In the strict acceptance mechanism, what status does code submitted by an Agent have by default?

A byproduct used only for logging that takes part in no process

A formal version that can be merged directly into the trunk

A finished product whose usability is determined by the submitter

A candidate patch pending verification, strictly isolated from accepted versions in permissions, storage, and references

Question 2

In what order are the four acceptance gates arranged, and what is the design intent?

Sorted by submission time, first-come, first-verified

From lowest to highest cost: compilation → testing → behavior check → upper-level acceptance, so the vast majority of invalid changes are cut off at cheap stages

In random order, to increase verification diversity

From highest to lowest cost, prioritizing resources on the most expensive upper-level review

Question 3

What kind of problem is the behavior check (the third gate) primarily guarding against?

"Tests pass but behavior drifts," i.e., the new and old implementations are inconsistent in semantics or numerical output

Too few unit test cases being written

The trunk version history taking up too much storage space

Code syntax errors making it impossible to compile at all

Question 4

How should the value of a candidate patch rejected by the gates be understood?

It should be written directly to the trunk as a counter-example for reference

It should be resubmitted repeatedly without modification until it passes automatically

It should be completely deleted to avoid consuming storage and interfering with later judgments

It can be retained as a failure archive / negative sample for diagnosis, deduplication, and preventing repeated exploration

Question 5

Which situation is most likely to let the acceptance gateway pass changes that "pass acceptance but are actually harmful"?

Upper-level acceptance simultaneously evaluating performance, speedup, and maintainability

Multiple submissions from different Agents coexisting in the candidate patch queue

Failure archives being retained long-term for diagnosis

Insufficient test coverage or missing behavior checks, making the acceptance criteria themselves incomplete

Case Study: Acceptance of a Compiler Kernel Rewrite Patch

Read the scenario and answer the two questions below.

A team is using multi-Agent collaboration to refactor a compiler kernel. Agent X submitted a kernel rewrite patch claiming to improve a certain benchmark's runtime speed by about 1.4×. The system processes this patch under the "strict acceptance and historical inheritance mechanism": the patch first enters the candidate patch queue, then undergoes compilation, testing, behavior check, and upper-level acceptance in sequence; if it passes, it's written back to the trunk and becomes the starting point for the next generation of Agents; if it fails, it enters the isolated failure archive.

1. List in order the checks the patch must pass, and explain why upper-level acceptance is placed last.

Answer:
The order is: compilation → testing → behavior check → upper-level acceptance. Compilation checks whether it builds at the syntax and interface level—lowest cost, fastest elimination; testing checks whether unit/integration tests are all green and cover existing contracts; behavior check compares the semantic consistency of the new and old implementations, including numerical tolerances, equivalence, and regression comparison; upper-level acceptance makes the final verdict oriented toward task goals and engineering constraints, judging performance, speedup, and maintainability. Upper-level acceptance is placed last because it has the highest cost and requires human or high-level review involvement—only after earlier stages have cut off the vast majority of invalid candidates can this expensive resource be concentrated on a small number of high-quality candidates, achieving "escalating cost, early failure."

2. Suppose the patch is found during the behavior check stage to have numerical outputs exceeding the agreed tolerance on some inputs between the new and old implementations. How should the system handle it? Does it still have value? What would happen if the behavior check were removed?

Answer:
The patch must not be written to the trunk—it should be rejected and moved to the isolated failure archive. Since it already passed the compilation and testing stages, this precisely shows it belongs to the dangerous "tests pass but behavior drifts" category. It still has value: it can be retained as a negative sample for diagnosing the source of the discrepancy, preventing subsequent Agents from repeating the same dead end, and prompting the team to add regression cases or re-examine the tolerance definitions. If the behavior check were removed, such patches would proceed directly to upper-level acceptance—or even be written back to the trunk—with all tests green, introducing behavior drift into the historical baseline. This is precisely the failure boundary of the mechanism: gates can only block problems they can detect, so observable metrics and manual spot checks are needed as a backstop.