Skip to main content
Just because a model can write code doesn’t mean the result meets the requirements. It may miss an acceptance item or mistake “the test command has been run” for “the function has passed”. Native Loop is about the step between “the code has been written” and “it is confirmed to meet the requirements”: the Builder is responsible for implementation, the Runtime is responsible for controlling the process and saving evidence, and the brand-new read-only Verifier Subagent independently judges based on brief.md, Specs and acceptance items. Only when both the necessary inspections and the final full acceptance are passed can the current change be filed. This article takes the implementation of the Comet 0.4.0-rc series (from rc.1 onward, RC below) as the standard. Each round of implementation has explicit constraints: what the input is, what evidence already exists, how many failures or retries are still allowed, and what conditions stop the loop. The model does not reflect on itself indefinitely.

​
The implementation and acceptance loop

When entering Verify for the first time, the Verifier will check the complete acceptance range. If only a few projects fail, the next round of Build only needs to focus on fixing these projects and pay attention to other projects that may be affected by this modification. After the partial acceptance is passed, the Runtime will still arrange A final full acceptance to prevent the damage to the already passed B when repairing A. Therefore, Native Loop takes into account two things simultaneously: it does not repeat irrelevant work during the repair stage and does not lower the acceptance standards before delivery.

​
Division of responsibilities between Agent and Runtime

The Builder submits a candidate implementation, not proof that it has “passed”. Before each new candidate implementation enters Verify, it must first be handed over to a new read-only Reviewer Subagent for code review. Subsequently, the Runtime will run the necessary checks and start another brand-new read-only Verifier Subagent to determine whether the implementation truly meets the requirements. Neither the Reviewer nor the Verifier is the Builder itself, and they are not the same task. The Verifier will first read the acceptance items, brief.md, Specs, actual implementation and inspection results, and only then take the Builder’s summary as an auxiliary clue. This reading sequence can reduce the impact of the Builder’s self-description on the acceptance judgment, truly separating implementation from acceptance.

​
The acceptance process led by Runtime

  1. Lock the candidate implementation. The Runtime records the candidate ID, the current implementation round, and the scope of this acceptance to ensure that subsequent results correspond to the correct code version.
  2. Run necessary checks. The Runtime executes test, build, or other project commands. The check results provided by Builder are only for reference and cannot replace the actual execution results of Runtime.
  3. Start the new Verifier Subagent. The Verifier checks the code in read-only mode and gives a conclusion only once for each acceptance ID within the current range.
  4. Verify the returned result. If the result contains missing items, duplicates, unknown acceptance ids, expired responses or identity mismatches, the Runtime will directly reject it and will not mistakenly mark it as passed.
  5. Decide on the next step. After the full acceptance is passed, it can be filed. Return to Build when acceptance items have failed; pause when product decisions or external information are needed and return the decision-making power to the user.
If the existing evidence is insufficient, the Verifier can request supplementary examination. The Runtime will perform checks and save the results, and then proceed with the current acceptance to prevent the Verifier from relying on guesswork to draw conclusions when there is insufficient evidence.

​
Partial repair and final full acceptance

Assuming the complete acceptance range is A1 to A8, the first Verify found that A3 and A7 failed. After the Builder completes the repair, the Runtime will hand over A3, A7, and other acceptance items declared by the Builder that may be affected by this modification to the next Verifier.
  • If the local scope still fails to pass, the Runtime will return the failure reasons to Build.
  • If a partial range passes, the Runtime will not directly archive but restore all A1 to A8 to the pending acceptance state.
  • The current change is only ready for archiving after the new Verifier has completed the final full acceptance.
This approach of “partial repair and final full confirmation” reduces meaningless repetitive checks while maintaining a complete defense line against regression issues. For the same candidate implementation, the Runtime can reuse the checks that have been completed in the current acceptance attempt to avoid duplicate execution. When the Verifier finds the existing evidence insufficient, it sends a request-checks request to the Runtime stating which project commands still need to run; the commands are still executed and recorded by the Runtime, never by the Verifier itself. For such requests, the Runtime limits the number of rounds and filters out duplicate items. The complete log will be saved on the local machine, and user-readable reports will only present conclusions and necessary summaries. This way, not only the details needed for troubleshooting are retained, but also the truly important acceptance results will not be drowned out by a large number of stdout and stderr.

​
Progress counters: iteration and attempt

The Native Loop uses two dimensions to locate the current progress: For instance, when the Runtime starts a new Verifier acceptance attempt for the same candidate implementation, attempt will increase, but iteration remains unchanged. The Verifier requests supplementary checks in the current attempt and does not add attempt separately. Only after the Builder modifies the code and submits a new candidate implementation will iteration proceed to the next round. An acceptance result belongs only to the execution it came from: when the Runtime records a result, it saves it together with the candidate ID, the Verifier that performed the acceptance, the iteration and attempt at the time, and the acceptance scope. So when a slow old task returns its result very late and it does not match the current state, the Runtime does not adopt it. Long-running tasks, recovery from interruption, and parallel execution all rely on this rule to keep state from being overwritten by old results.

​
Progress judgment based on unresolved acceptance items

The Runtime does not assume that progress has been made just because “a lot of code has been changed this time”. It will compare the acceptance items that remain unresolved for two consecutive rounds: only when the unresolved items are indeed reduced and no new unresolved items are added can it be considered that reliable progress has been made. In terms of set relations, this means that the current unsolved item must be a strict subset of the previous round. RC will record the following counts:
  • no_progress_count: The number of times that have not been strictly reduced for unresolved acceptance.
  • failed_iteration_count: Realize the rounds that have not passed the acceptance.
  • execution_failure_count: The number of times the Verifier task itself fails to execute.
When there is no reliable progress for two consecutive rounds, the Runtime will require the Builder to adopt a different approach to the repair. If there is still no progress in the third round, the Loop will be paused, allowing the user to decide on the next step. The number of failed acceptance rounds is also subject to the native.max_verify_failures limit, with a default maximum of 5 rounds. “Failed acceptance” and “Verifier task execution error” are two different types of issues. The former means the implementation still does not meet the requirements, or the requirements themselves are flawed; the latter suggests that the Verifier has not completed the task properly. RC allows a maximum of 3 consecutive execution errors, and each acceptance attempt can accept a maximum of 2 rounds of additional inspection requests. When the upper limit is reached, the Runtime will explicitly pause and will not retry indefinitely, nor will it treat an exception as a pass.

​
Fall back precisely according to the type of problem

The issues exposed by Verify are not necessarily all code errors. The Runtime will return the corresponding stage based on the type of problem:
  • Implementation omissions or code defects: go back to Build and fix the existing implementation;
  • Changes in user-visible behavior or acceptance criteria: return to Shape, update the requirements and ask the user to reconfirm;
  • New requirements that are not related to the current change: create another change to avoid expanding the current acceptance scope;
  • Lack of user decision or external conditions: enter await-user and specify what information needs to be supplemented.
In this way, Loop will not rewrite the confirmed goals at will just to “run the process smoothly”.

​
A persistent state that can be recovered across tasks

The Native Loop does not rely on a certain model and always remembers the entire context. The Runtime will save the states for different purposes separately:
  • comet-state.yaml saves a stable state that is synchronizable and recoverable, as well as the next step.
  • verification.md saves user-readable acceptance reports;
  • .comet/runtime/native/ saves the running status, logs, locks and transaction information of this machine.
After a task is interrupted or switched to another device, the Runtime will rebuild the process based on a trusted YAML state. Unfinished local tasks will be regarded as interrupted. Even if the current change has entered the “archivable” state on another device, it still needs to be re-verified after changing devices and cannot directly follow the execution conclusion on the original device. The recovery process itself will not be counted towards the number of acceptance failures or halts.

​
Automatic propulsion with clear boundaries

The Runtime will stop the automatic advancement in the following situations and return a clear action:
  • There are still product decisions, external conditions or blocked acceptance items that need to be handled by users.
  • The current code, branch, worktree or artifact root is inconsistent with the Runtime record;
  • There is no reliable progress, failed rounds or execution errors reaching the budget;
  • The Verifier is unavailable, or the current platform cannot prove that it is independent of the Builder.
  • When multiple parallel changes modify the same capability, the archiving sequence needs to be determined first.
Some platforms can start the Verifier but cannot prove to the Runtime that it is indeed running in an independent task. In such cases, the Runtime will truthfully mark this reliability limit and require the user to confirm the result. It will not package “has been isolated as much as possible” as “has completed independent acceptance”.

​
The core value of Native Loop

  • ** Completion of standard credibility ** : Whether archiving is allowed depends on Runtime checks and item-by-item acceptance, rather than the Builder’s own statement.
  • ** Mutual checks and balances of responsibilities ** : Implementation, code review, inspection of execution, and requirement acceptance are handled by different roles.
  • ** Controllable repair cost ** : After failure, focus on the unresolved issues and conduct a full confirmation at the end.
  • ** Bounded execution rounds ** : Stagnation, failure, execution errors, and additional checks all have explicit round limits.
  • ** Can be safely restored ** : The state is recorded to the disk, the old response is subject to version constraints, and it does not rely on model memory to continue after an interruption.
  • ** Transparent boundaries to users ** : When there are changes in requirements, external blockages, or insufficient independence, the process will stop to explain the reasons.
The model continues to be responsible for understanding and implementing what it excels at, while the Runtime transforms the delivery process into a verifiable, recoverable, and auditable workflow. Continue reading Verification and Repair to learn about the Verifier protocol and failure handling. Read Task progress and interruption recovery to learn about continuation, Checkpoints and Recovery Mechanisms
Last modified on September 4, 2026