Repository navigation
Conversation
Fodesu
force-pushed
the
feat/agent-runtime-core-16-loop
branch
from
October 3, 2026 14:43
c1a10a5 to
c7f8819
Compare
Fodesu
marked this pull request as ready for review
October 3, 2026 14:46
Fodesu
force-pushed
the
feat/agent-runtime-core-16-loop
branch
from
October 3, 2026 17:04
c7f8819 to
1d776c4
Compare
Fodesu
force-pushed
the
feat/agent-runtime-core-16-loop
branch
from
October 3, 2026 17:11
1d776c4 to
7a2c998
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the first Run execution Loop. The Loop interprets persisted machine state, commits protocol transitions through the caller-owned
RunStore, and hands external work to an Executor only after the corresponding start barrier has been accepted.Design
Advancealways reloads state and derives its next action throughplan.Next; it does not keep authoritative Run state in memory. Open Runs are prepared through a decision Builder, with the request, digest, prompt token, consumed inputs, and frozen tool specs persisted inModelStepPrepared. Prepared steps are withdrawn when new inputs make the request stale. Model and tool starts resolve optional durable targets, validate with the Executor, commit an effect identity, and then dispatch an immutable Assignment.Tool scheduling honors the frozen parallel/sequential mode and maximum concurrency. Model results are converted into deterministic tool-call bindings: CallIDs derive from step and position, while provider IDs remain round-trip metadata. Malformed results use the configured retry bound; provider failures, cancellation, missing frozen values, and unknown outcomes map to distinct Run commands. Tool failures that may have crossed the external boundary become unknown rather than being retried as known failures.
Delivermatches an Outcome by EffectID against the currently Executing model step or tool call and drops stale outcomes without writing.Runsupplies the blocking form, sharing a settlement Watcher, cancelling effects on ownership loss, and settling accepted results under detached control contexts. Per-Run locking prevents interleaved local drivers while allowing different Runs to proceed concurrently.The implementation establishes the event/observation split: committed Run facts are durable authority; progress and lifecycle events are only observations.