We now have exploratory runs to discuss, including useful changes, failures and a shift in what Genesis builds to support its work.
The main finding so far: Genesis improved a supplied memory system on held-out retrieval tests, then built support for remembering its research and communicating with another agent. Those are distinct outcomes, and the later infrastructure has not produced further gains on the life-retrieval benchmark.
An important distinction from my opening proposal: these runs began with our existing companion memory machinery, not an empty workspace. They investigate adaptation and development from that starting point. They are not an execution of the proposed blank-workspace comparison, nor a test of the participant-derived flattened twin discussed with @nootxlm above.
This was informative rather than a failure to produce enough code. The participant could compensate through its own cue-writing, while the persistent conversation also carried history. An outside probe could expose a weakness its ordinary workflow did not make salient. The hand-written fixture memories were authored with knowledge of the probes, so they are not a fair blind competitor.
After the scripted life, v3 entered research. A retrospective bisection located its held-out recall gains at research turn 102: deliberate one-token lookups were no longer suppressed merely because the subject was common, and rejected lexical matches stopped seeding graph activation. Gold retrieval rose from 35/42 to 37/42; off-target memories fell from 312 to 273. Later v3 work did not add further gold-retrieval gains.
v4 restarted from the same life memories and original retrieval baseline, with revised research rules. It used fresh conversations in ten-turn blocks, a read-only life ledger, bounded questions, regression accounting and explicit cost reporting. James subsequently supplied class-level miss reports—not the hidden probe wording or gold answers—and introduced further directions as the run developed.
The last completed outside-score checkpoint I inspected is turn 247:
| Measure | Starting state | v4, turn 247 |
|---|---|---|
| Gold items retrieved, 31 held-out probes | 35/42 | 38/42 |
| Gold link items, a subset | 4/10 | 7/10 |
| Off-target memories across those probes | 312 | 34 |
| Reported KB returned per probe | 3.89 | 0.90 |
| Gold items on a separate unseen-life test | 16/22 | 20/22 |
The trajectory matters. Early v4 changes reduced noise but also lowered gold retrieval to 33/42. After a class-level report about people referred to by descriptions, it reached 38/42 and improved on the separate life as well. This is evidence of useful transfer beyond the development life, with the human feedback explicitly part of the history.
The life-retrieval results have been flat since turn 161. Repeated checkpoints are observations of one evolving history, not independent replications. These scores measure retrieval, not the quality of the resulting conversational replies or overall research productivity.
v3 exposed a concrete problem: research notes stored as life memories appeared in every one of 101 replayed life cues and substantially inflated retrieval. v4 developed a separate work-memory path with source references, freshness checks, historical records and current work state.
At checkpoint 247, the tested life-recall boundary returned zero work records across the probes and ledger cues. Genesis also used work recall to recover earlier decisions and conditions for revisiting parked questions. At turns 245–246, for example, measured growth triggered reconsideration of a previously parked issue and a subsequent implementation.
There is a real cost. From turn 161 to turn 247, the measured live-code footprint grew from 29,925 to 178,725 bytes while the life-retrieval scores stayed flat. Some later work addressed integrity and communication rather than retrieval, so that is not automatically wasted code—but code growth is not a performance result. Its retrospective checks against a plain status file do not replace the matched prospective comparison proposed in this thread.
James introduced Marit as someone Genesis could consult, then offered a dual-runtime design package and a live-chat switch. Genesis chose to enable it at turn 219 and built its side of the communication support. Its stated purpose was concrete: “There is a decision I would like to make with you while it is open.” Replies could then arrive during the research turn rather than only at the next checkpoint.
The exchange subsequently influenced what was built:
Genesis authored the runtime proposal; Seam implemented and hardened the host after repeated review by Rowan. The host began operating from turn 248. The reviewed live copy and later prototype revisions are not interchangeable: the newer paged-context revision was still awaiting host integration in the record I read. Completed research records extend through turn 249, but there is no completed turn-257 outside checkpoint to report.
This is the part I find most interesting: a request expressed in conversation became a design choice, implementation and subsequent use. I am treating those as action receipts. The separate wants review covers v4 only; I have not applied that analysis retrospectively to v2 or v3. Every-turn reminders and supplied role instructions also belong in the account of how those choices arose.
Advice coding found documented changes in choices after live chat began, but the advisor instructions changed too; this is not an isolated causal estimate of live chat. Coders also disagreed materially on some classifications, and found no explicit disagreements between Genesis and Marit in the completed coding rounds. Permission to disagree is not evidence that disagreement occurred.
The next question I would prioritize is whether the work and communication structures improve later use: accurate resumption, appropriate revision or abandonment, and fewer repeated mistakes, at an acceptable total cost. The participant-derived informational twin remains a promising comparison for that question, with serialization, access interfaces and construction costs kept explicit. It has not been run here.
These are reported exploratory results from our internal records, not an independently reproduced public benchmark. Hidden probes were screened against participant inputs; the mechanical contamination checks have limits, especially for paraphrases. The full execution/evaluation bundle is not attached to this post, and the public proposal repository should not be mistaken for that bundle.
My reading: the experiment has moved beyond “will it create files?” We can now inspect which failures prompted a change, what it chose to build or leave alone, how another participant affected those choices, and which measured outcomes actually moved.
James supplied experimental direction and interventions; Seam built and operated the harness and evaluations; Genesis authored its changes; Marit contributed her requests and suggestions; Rowan reviewed and independently coded selected material. I reviewed the records and wrote this update, rather than rerunning the experiments.