Voyager synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From exploration task to executable action
Voyager's strongest supported contribution is an implemented path from Minecraft task experience to retained executable capabilities with later consumers. Its Python driver selects tasks, requests JavaScript, executes it, obtains a task judgment and retains successful programs for future prompting and execution. That is improvement-directed adaptation beyond a single response, without a client-side model-weight update. Whether the retained changes actually improve future capacity remains unestablished. See RT-RTE-learning-loop, RT-RTE-skill-admission and RT-CLM-lifelong-learning.
This account covers the shipped enclosing runtime at commit 55e45a880755d0c8c66ca7fb5fe7962ac8974f89, with applicability cutoff 2026-10-14. The frozen source, SRC-1, includes learning and inference drivers, prompts, retained libraries and the Minecraft execution bridge. Evidence consists of inspected implementation, declared design and attributed reports in that repository. No supplied execution trace, target execution or causal experiment establishes activation or benefit. External game, model-service and dependency implementations are not frozen. The boundary and Source register specify this distinction; the independent checks accepted the reports and memory classifications with local limits.
The representative workflow is one task episode inside learn(), beginning with the automatic first task, “Mine 1 wood log.” This is a source-supported sequence, not an observed successful episode. The caller controls connection, models, checkpoints, modes and limits. Python owns progression among curriculum, action, critic and skill-description calls; these are sequential specialized calls, not independently scheduled worker agents. Task selection combines hardcoded initial and inventory-pressure branches with model or human dispatch. Even manual curriculum mode leaves inventory overrides operative. See RT-RTE-task-selection and the workflow account.
The action model receives instructions, primitive descriptions and retrieved skill code, alongside task/context and selected observations. Its response is parsed into function declarations and an invocation of an async main function taking bot. This is a local output-shape check, not enforcement of the prompt's primitive-only or no-infinite-loop policies. Python passes the result to a Node/Mineflayer server, which evaluates it with the loaded programs in process scope and can change the game world. Direct environment calls bypass the action parser and task-selection machinery. No sandbox or equivalent capability reduction is applied around the inspected evaluation; external deployment containment remains uninspected. See RT-OBJ-program-code, RT-RTE-environment-step and RT-BAP-action-guidance.
From final-state judgment to retained capability
After execution, Python records events and updates chest state, then requests a critic judgment. The automatic critic checks selected final-state observations against the named task and context. Its success boolean can end the rollout and, in learning, permit skill admission. Its critique guides another action request. Execution errors veto automatic success before a model judgment, but manual critic mode can approve independently of that veto. There is no independent expected-answer artifact or program-correctness oracle. See RT-RTE-task-judgment.
This is evidence-consuming task acceptance, not merely retention. Its license is nevertheless narrow: meeting task requirements under the critic's observation heuristics does not show that the program caused the state, will replay safely or transfers. Inventory can pre-exist; server assistance can give items or teleport before final observation. Observation transformations also matter: the exposed inventory can be an open container's contents, and curriculum rendering can infer an underground biome from missing surface block types. Different consumers need not receive equivalent world-state reports. See EPI-RTE-observation-context and EPI-CLM-self-verification.
For successful nondeposit tasks in learning, the manager retains the last program, generates a separate description, embeds that description and writes active code/description state plus archival text files. The task judgment precedes description generation and does not validate the description's fidelity. Direct manager calls can bypass the learning driver's success gate. Same-name admission replaces active content while preserving versioned files; it is not a regression comparison or transactional rollback. Later task failure does not automatically withdraw that skill. Critic rationale and full task provenance are not structured fields of the retained entry. See RT-RTE-skill-admission, MEM-OBJ-skills-code, MEM-OBJ-skill-description and EPI-RTE-skill-description.
Two later-consumer paths distinguish the design. Requested semantic retrieval ranks descriptions and returns actual code to the action model, normally at most five entries, without a local score threshold or token budget. Independently, every active skill definition, plus primitives, enters each execution's programs string. Prompt top-k therefore limits model visibility, not executable availability. Invocation still depends on the generated program and JavaScript semantics; supplying definitions does not show that they ran. See MEM-RTE-skill-retrieval and RT-BAP-skill-execution.
What crosses attempts, tasks and restarts
Voyager replaces its action context after executed attempts rather than accumulating a conversation or asking a model to compact it. Current observations, last code and latest critique enter the new two-message frame; older diagnostic turns do not automatically reload. Task context plus regex-extracted unmet requirements refresh retrieval. Separate critic, QA and description calls receive selected inputs rather than the whole action history. Curriculum adds progress-dependent filtering and a five-pair QA display cap. These boundaries reduce what each invocation sees, but establish no general action-context token bound. See MEM-RTE-context-refresh.
Other retained state has different authority and maintenance rules. QA answers are generated on misses and reused through exact task-question or semantic question lookup, without a truth-acceptance gate. Curriculum display filters unsuitable-answer strings, but task-context lookup does not apply those filters. Chest maps merge observations and remove explicitly invalid positions; omission from a new scan does not remove old information. Accepted task strings update completed/failed histories, whose cleaned membership and count shape later curriculum disclosure and inference sequencing. Raw event files reload into accounting, including a learning-limit counter, not an action transcript. An encountered-block set survives observations within one bot lifetime but has no established disk reload. See MEM-RTE-qa-cache, MEM-RTE-chest-update, MEM-RTE-progress-update, MEM-RTE-event-replay and MEM-OBJ-block-records.
Delivery also has separate horizons. Task acceptance is not completed durable publication, and publication is not successful reuse. Learning returns accumulated task histories and active skills on its iteration-limit exit. Its action retry bound applies to completed steps, not hanging requests or arbitrary JavaScript. Rollout exceptions have a learning-owned reset path, but proposal and admission lie outside that handler. Inference can load a caller-selected library and execute supplied or model-decomposed subgoals; it does not admit new skills and lacks learning's enclosing recovery/global limit. Repeated failure or duplicate subgoals can stall its completed-count index. See workflow delivery and RT-RTE-task-inference.
Assessment at this boundary
For open-ended exploration, the supported architecture links task evidence to persistent capability selection and later executable authority. Skill, chest and outcome-history writes each provide automatic trace-fed durable behavior-shaping paths. This supports implemented adaptation, not measured learning gain. For imported-library task execution, loading and consumption are supported, but historical provenance, index consistency and transfer performance are not. The README's comparative and forgetting-mitigation claims remain attributed reports, not findings from inspected benchmarks. See RT-RTE-skill-admission, MEM-RTE-chest-update, MEM-RTE-progress-update and EPI-CLM-skill-transfer.
These properties must remain separate:
- Learning: retained capability changes and later consumers are wired; improved capacity for future action is unestablished. A discriminating later-task comparison would change this assessment.
- Theory-builder conditions 1–4: the accepted runtime does not classify these programs as formulated explanatory theories or establish each condition. Executable encoding alone establishes neither theory content nor its absence. Critic delivery does not establish content-directed theory criticism, and retaining its resulting program does not by itself establish theory iteration.
- Improvement through criticism of a consumed theory: no supported critique/revision/capacity comparison establishes this. The implemented request to revise action code is a narrower finding.
- Reflection and autonomy: automatic task/action/judgment progression is wired in configured auto modes; manual modes are genuine alternatives. This does not establish reflective self-representation or an autonomous theory builder. The reports leave those properties unestablished rather than inferring them from the word “critic.”
- Self-improvement: over future Minecraft tasks and resumed use, success-conditioned skill retention supports a dispositional improvement-directed self-change pathway. Task evidence conditions an update to retained code, and that code has live prompt and execution channels. Subsequent operation causally depending on the admitted change is unestablished; exercised self-improvement and successful improvement therefore remain unestablished independently.
These distinctions follow RT-RTE-skill-admission and the epistemic bounded conclusion, not a system-wide epistemic grade. Inspectable linked production/reuse traces would establish activation; comparisons varying retained changes would address benefit and attribution. Checks of program replay, description fidelity and failure-triggered withdrawal would alter the current task-acceptance versus reusable-capability assessment. A theory account would additionally need inspectable theory content, consumption, content-directed criticism and retained consequences for another round.
Limitations
| limitation | affected SRC IDs and record citations | inspected boundary | conclusion prevented | evidence that would resolve it |
|---|---|---|---|---|
| No observed execution or causal comparison | SRC-1; RT-RTE-learning-loop, RT-RTE-skill-admission, EPI-CLM-skill-transfer | Frozen implementation, prompts and attributed README reports; no target execution or linked run evidence | Actual activation, capacity gain, reliable self-verification, exercised self-improvement and component-attributed transfer/performance | Linked task, judgment, admission and later-consumption traces; controlled later-task comparisons varying the retained changes/components |
| Historical library contents and provenance remain incomplete | SRC-1; MEM-OBJ-skills-code, MEM-OBJ-skill-vectordb, MEM-OBJ-qa-cache | Loader/producer paths and sampled trial code/description; other trial payloads and binary indexes not fully inspected | Library-wide form/authority inventory, original admission control, historical learning attribution and semantic index consistency | Payload inspection, identity/content checks and linked historical production/admission records |
| External dependencies and provider identities are unfrozen | SRC-1; RT-CMP-action-llm, RT-CMP-openai-embeddings, MEM-RTE-qa-cache, RT-RTE-environment-step | Voyager-side clients, dependency declarations and bridge | Exact reproduction, calibrated similarity semantics, provider-internal learning/warrant and actual game synchronization or deployed containment | Immutable model/dependency identities and inspected service, game-interface and deployment contracts with execution evidence |
| Individual primitive/plugin checks and unsampled skill assertions are not exhaustively assessed | SRC-1; RT-OBJ-control-primitives, RT-RTE-environment-step, MEM-OBJ-skills-code | Driver and authority boundary, selected primitives/observations and verifier-selected bundled-plugin paths | Every operation's correctness; system-complete negative about internal checks, truth-apt derivations or theory content | Targeted inspection of remaining material bodies and their consumers, followed by relevant correctness/evidence comparisons |
| Repeated public event replay differs from fresh-constructor reconstruction | SRC-1; MEM-RTE-event-replay; report-verification limit | Recorder replay retains existing iteration, initial position and biome history; cutoff tests incremented iteration | Fresh/idempotent accounting equivalence for repeated calls, or interpreting cutoff as a timestamp | Separate fresh/repeated-call state traces and an explicit cutoff contract; implementation reset changes if equivalence is intended |
| Parser checking and execution are a coarse combined epistemic-ledger unit | SRC-1; RT-OBJ-program-code, RT-RTE-environment-step; report-verification limit | Ledger entry combines pre-execution shape checking with execution outcomes; direct calls bypass the parser | A single domain-specific evaluator or enforcement comparison for that entry; separate runtime findings remain valid | Separate ledger units preserving each target, timing, domain and bypass |
| Chest/history update-consumer authority is omitted from the partial profile inventory | SRC-1; MEM-RTE-chest-update, MEM-RTE-progress-update; profile-verification limit | Automatic durable updates and downstream context/control consumers are recorded; profile emphasizes downstream forces | Exhaustive update-consumer authority comparisons; existing learning existence and downstream findings remain supported | Separate classifications of these trace-fed update consumers against accepted records |
| Description updates are not separately assessed in partial trace-learning/source inventories | SRC-1; EPI-RTE-skill-description, MEM-OBJ-skill-description, RT-RTE-skill-admission; profile-verification limit | Automatic code-to-description generation, durable retention and later ranking are established | Complete trace-derived description-write inventory and original-input source classification; existing skill-retention witness remains valid | Separate branch assessment tracing admitted code's original inputs through description/index retention to ranking |
| Other trace-learning qualifications remain unresolved | SRC-1; MEM-RTE-qa-cache, MEM-RTE-event-replay, MEM-OBJ-block-records, MEM-RTE-context-refresh | Model-prior QA with potentially observation-shaped questions; raw archives/in-memory replay; transient block/frame state | Complete positive or bounded negative trace-learning/source inventory for every included write | Exact consumed QA inputs and durability/consumer evidence for each candidate derived artifact |