Scion studies an agent that leaves more than an answer. Its successor can inherit working code, mathematical lemmas, local tools, instructions, notes, and unfinished attempts. The research question is whether this accumulated state improves later work.
The runtime preserves actual workspaces and evaluated checkpoints. Environment adapters provide the task and independent checks; fresh and inherited agents can then receive the same task and budget. This separates the benefit of a capable starting model from any additional benefit of its acquired methods.
Why this approach
From a better artifact to a better next attempt
Scion records which inherited tools are used and whether they change success rates or construction cost relative to a fresh agent.
The work has moved from arithmetic search and framework revision to proof agents, a common runtime for different environments, and resident-assistant tasks. The model weights remain fixed in these studies; learning is expressed through the retained agent-created package and the way later work uses it.
A generation is a handoff boundary, not necessarily the end of a problem. Keeping the last editable state lets a successor continue a difficult attempt rather than inherit only a winning checkpoint. That makes partial lemmas, failed approaches, and working tools part of the learning question. An external check decides whether the task is solved; a separate progress review can decide that further work is no longer justified.
Where it stands
The common runtime separates the agent’s work from the environment that checks it. Agents can revise code, tools, proofs, instructions, and notes; evaluations capture immutable versions while the editable workspace continues. The continuing controller passes the final workspace, including unfinished attempts, to a successor and advances to another task only after the checker confirms completion.
Later versions let evaluation run asynchronously and preserve work through interruption. After repeated generations without a score increase, an independent progress review examines whether useful partial results justify continuing. The same mechanism has been exercised across a 20-task sequence spanning data processing, language semantics, planning, optimization, and proof; completing that sequence does not by itself measure the benefit of inheritance.
Later studies exercise persistent project tasks through Harness, including interrupted work, scoped changes, changed dependencies, planning, repair, and clarification. The earlier allocation comparison below measures a separate question: how many inherited proposals to admit into search.
What the work has shown
A successor reused checked mathematical knowledge
The proof warmup produced six reusable addition lemmas and two Lean-verified target proofs. In a later fresh-versus-inherited comparison, the inherited agent kept all six lemmas and added two for parity; its new proofs directly depended on earlier lemmas. Both agents proved the two new targets and retained the warmups, with empty axiom-dependency lists in their final target proofs.
Using the inherited toolkit did not produce a score or speed advantage in that exploratory pair. The fresh agent independently built comparable methods. The next useful distinction is which new problems benefit from that accumulated toolkit.
The same agent mechanism carried a proof workspace into programming
The common runtime passed the inherited proof package into an event-log reconstruction task without embedding either task’s semantics in the core. Fresh and inherited agents both passed 16 development cases and all 48 held-out final cases. The inherited agent adapted its instructions and notes while preserving the proof modules byte for byte.
The workspace survived the change of task, but the comparison showed no inheritance advantage: both solved the programming task on their first scored attempt, leaving little room to measure improvement.
Resident tasks exposed a ceiling in the experiment
A later resident calibration completed 24 encounters through the real Harness path, retaining project state through reopened sessions and outside changes. The original score was 22/24; inspection found that the grader had wrongly forbidden changes to agent-created methods. A separate correction preserved the original scores and gave 24/24 without rerunning the agent.
The tasks covered interrupted delivery handling, evidence becoming stale after dependency changes, scoped policy revision, and executable utility repair. But there were no recurring substantive failures left to improve. The planned learning comparison was therefore not launched; harder failures from actual resident work were the next source of cases.
Experiments and evidence
Selected recorded studies. Each keeps its original conditions, date, interpretation, and limits.
Completed comparison · 8 September 2026
Changing the allocation of inherited proposals
A shared discovery phase passed the success checks for 3 of 16 fresh functions. Two continuations then received the same task-specific memory and seed. The control admitted up to twelve directly inherited proposals; the treatment admitted four, leaving more room for other proposals under the existing schedule.
The primary question concerned the 13 functions left unsolved by discovery. The study ran 48 episodes with 0 model calls during this comparison.
A task passes when its selected program matches all supplied examples and all separate evaluation cases within the execution budget. The saved record calls this “mastery”; it is a finite test, not a proof of correctness on every input.
Neither allocation passed the checks for an additional task
Measure
Control: cap 12
Treatment: cap 4
Additional tasks passing / 13
0 / 13
0 / 13
Candidate submissions
2,500
2,490
Search interpreter steps
11,426,160
11,498,684
Retained discovery successes
3 / 3
3 / 3
Inspect all sixteen task outcomes
All tasks retained; already-solved tasks are outside the primary denominator
Task / family
Discovery
Control
Cap 4
Primary comparison
1 · bilinear
Passed
Passed
Passed
Passed in discovery
2 · bilinear
Not passed
Not passed
Not passed
Included
3 · triangular
Passed
Passed
Passed
Passed in discovery
4 · triangular
Passed
Passed
Passed
Passed in discovery
5 · scaled triangular
Not passed
Not passed
Not passed
Included
6 · scaled triangular
Not passed
Not passed
Not passed
Included
7 · triangular composition
Not passed
Not passed
Not passed
Included
8 · triangular composition
Not passed
Not passed
Not passed
Included
9 · nested sum
Not passed
Not passed
Not passed
Included
10 · nested sum
Not passed
Not passed
Not passed
Included
11 · scaled nested sum
Not passed
Not passed
Not passed
Included
12 · scaled nested sum
Not passed
Not passed
Not passed
Included
13 · triangular product
Not passed
Not passed
Not passed
Included
14 · triangular product
Not passed
Not passed
Not passed
Included
15 · nested triangular
Not passed
Not passed
Not passed
Included
16 · nested triangular
Not passed
Not passed
Not passed
Included
Changing the cap did not change the outcome
The altered cap changed the admitted proposals, but mostly made room for more of the same kind of additive composition. The structural mutation fallback was never reached in these episodes. Tuning the cap did not test the stronger hypothesis about extending inherited partial work.
Limits
Freshness was checked on a finite grid within eight existing families. There was one matched seed per task and no held-out-family or independent RNG replication. This bank is now exposed development evidence.