Choose the next step from the current project
An application changes as work lands and people refine their decisions. Wildo’s unattended loop reads the project again after each round, then chooses from the methods whose declared requirements hold.
The model contributes judgment about useful work. The runtime controls the available options, admits compatible work and records why the loop stops.
Example — Continue from the decisions that just changed
A research result updates the market information. On the next round, the loop sees the new state and can choose relevant follow-up work, such as revisiting requirements, instead of continuing from an earlier assumption.
For engineers
Read current state for every iteration
This selected runtime excerpt shows the boundary between state evaluation and unattended selection:
for (let iteration = 1; iteration <= input.maximumIterations; iteration += 1) {
const state = await input.readArtifactState();
const board = evaluatePlaybookCatalogEligibility({
playbooks: input.playbooks,
state,
landableFamilies: input.landableFamilies,
});
const eligible = board.playbooks.filter(
(entry) => entry.eligible && !entry.requiresElicitation,
);
// Selection and execution follow for this iteration.
}
The excerpt shortens the surrounding trace and execution code. Methods requiring creator answers are excluded from unattended selection. They remain available through the explicit run path, where the required interaction can occur.
Separate selection from admission
The selector receives eligible references, intent and useful state annotations. Its structured response bounds the number of lanes, rejects duplicate choices and makes stop an exclusive choice. The runtime then checks proposed lanes for overlapping declared write scopes and records any lane held back.
Admitted lanes settle independently. The next iteration rereads project artifacts, so new landed information becomes available through the normal state reader.
| Stop reason | What it tells the caller |
|---|---|
| Nothing eligible | No current method passes the unattended selection conditions |
| Chose to stop | Selection ended the attempt, with its rationale |
| Iteration ceiling | The configured number of rounds was reached |
| All lanes failed | Every admitted lane in a round failed |
Set the scope of an unattended attempt
The companion’s POST /playbooks/loop accepts a goal and iteration/lane settings. One loop is active per companion; a second request receives an explicit refusal. An explicit individual run is a separate path.
The loop’s iteration and fan-out settings are execution ceilings, not token or financial budgets. Completion of an iteration means its lanes settled; it does not establish that every application concern is resolved. Use the recorded outcomes and resulting product artifacts to review the work.