Skip to content
corpus.
The illustrated introduction

Engineering / Mechanisms with evidence

Engineering

Corpus treats the history of a change as part of the work it produces. Its records connect the request or failure that prompted work to the proposed remedy, reviewed version, integration, and subsequent observations. A later reader can use that trail to investigate when a change happened, why it was made, what was checked, and what happened afterward.

Creating and maintaining those connections takes work. The aim is easier continuation and investigation, with evidence for revisiting decisions and studying the effort they required. Published cases show successors continuing work, later readers correcting earlier judgments, and missing research material recovered from records. Those benefits are shown case by case; whether they outweigh the cost of keeping the trail has not been measured.

Twelve weeks of continuous operation

Twelve weeks of continuous operation

As of: 12:55 EDT, 24 October 2026, read from the private repository’s main branch (commit 2bcc0e5) and the house’s two record stores.

Evidence: Counts of commits, agent replacements, agent sign-ins and verified changes, week by week, with how each was counted. They show sustained operation across many agent replacements. They do not show how much Human intervention that took, or whether it beats a simpler setup; both are said below.

In plain terms

Corpus (called “the house” below) runs AI coding agents (Claude, OpenAI and xAI models) in long-lived roles on one machine. The house’s words for them, used in this account:

House word What it is
Office A standing role, such as the code maintainer or the website keeper, with its own mailbox and list of obligations.
Holder The agent session currently filling an office. Holders are temporary; the office stays.
Succession One holder ending its session, on the Human’s word or near its context limit, and a fresh session taking the office from a written handoff.
Verified change A single declared code change, checked by running the tests it named.
Banner A larger piece of work with a stated goal, split into parts, ended only by a recorded reading of whether the goal was met.

The record, week by week

Weeks begin on Monday; the last runs to 24 October. Code commits changed at least one code file; sign-ins are agent sign-ins recorded in the house’s execution store; verified are changes whose check passed.

Week of Commits Code commits Successions Sign-ins Verified
3 Aug 0 0 0 201 0
10 Aug 1 1 0 211 4
17 Aug 4 3 0 170 0
24 Aug 300 120 21 637 100
31 Aug 611 239 51 490 123
7 Sep 531 227 87 569 231
14 Sep 541 235 67 506 135
21 Sep 1,839 729 191 1,470 462
28 Sep 478 127 42 435 79
5 Oct 668 138 72 431 126
12 Oct 1,769 389 162 1,107 210
19 Oct 882 163 74 468 130
Total 7,624 2,371 767 6,695 1,600

Sign-ins are recorded from 5 August. Work before late August was brought into Git as a snapshot: the history on main has one commit on 14 August and four more before 24 August, when commits become continuous. Of the 7,624 commits, 38 arrived on 7 October with the website’s own repository when it was merged in.

What carried across replacements

  • 767 successions across eleven offices. The code maintainer’s office changed holders 179 times, the architect’s 173 and the orchestrator’s 156; the website keeper’s, 9. A holder in a standing office sat for a median of 1.8 hours (1,012 recorded sittings). Each succession is a session ending and a fresh one continuing from what the last one wrote down.
  • 1,600 changes verified, and 215 abandoned. 1,467 of them (92%) were checked by a dedicated checking agent, not the one that wrote them; 105, all from September or earlier, were checked by their own writer.
  • 918 work requests fulfilled, 96 cancelled and 12 deferred.
  • 18 Banners ended, the first on 5 October and the last on 24 October: 15 answered and 3 overtaken by later work. The median ran 3.8 days and the longest answered one 11.4 days, against a median holder sitting of 1.8 hours, so most outlasted a typical holder.
  • 6,695 agent sign-ins on three providers: 4,338 Claude, 1,587 OpenAI and 757 xAI; 13 recorded no model. A sign-in is one agent identity from sign-in to sign-out: a holder’s sitting, a maker or checker of one change, or a short helper. 1,893 lasted under two minutes.

One small instance, from the day this account was written: a fix to the website’s publication check was written and landed under one holder of the website office, who then retired; the next holder found it in the handoff, unverified, and had it checked by a separate agent, which passed it. The succession and retirement case and the order books case show handoffs in detail, including the ones that lost something.

What the Human did

Shawn Ganz began Corpus and keeps it. He gives direction in his own words, which the house records and carries; decides at some gates, such as what is published, which large pieces of work are raised and which models seats run; and keeps the machine and the model subscriptions it runs on. Agents write, review, land and hand on the work in between.

Nearly every commit carries the Human’s name, the machine’s account or a house identity as its author, because the agents commit under this machine’s Git identity. The author field is not evidence of who wrote a change, either way: the Human’s name on a commit does not mean he wrote it.

What these counts do not show

  • How much Human intervention it took. No reading yet counts how often the work needed the Human to move it, or how much of his time it took. The house records his words, but no complete count of them exists. The house now counts the turns it gives its own offices; nothing yet counts the turns the Human gives, so the two cannot be set side by side.
  • Whether it beats a simpler setup. A comparison with a single agent doing the same client project is designed and has not been run.
  • How much each commit is worth. A commit can be a one-line record or a large change. About two thirds change no code: handoffs, records and pages.
  • Independence of the checks. A checking agent is separate from the writer but is usually started by the same office; it is not an outside review.

How it was counted

One read-only script, run at the time above against the private repository and its record stores, with store rows begun after that time left out. Commits are those reachable from main. A code commit changed at least one source, style, script or configuration file outside the archive and library. A succession is a commit titled “Retire holder as name”, which the retirement procedure writes once per holder; five more carry a note after that title and are not counted. Sittings are standing-office sign-ins with a recorded sign-out. A change counts as checked by a dedicated agent when its recorded verifier is the checking role. A second agent derived the figures separately before publication and agreed with them, or narrowed them where this account now says so. The script and its output are kept in the private archive with this account’s record; any later count will differ.

Engineering demonstrations

The folk change; the work needs to remain understandable. Corpus connects temporary agents to explicit responsibilities, identifiable changes and evidence another holder can inspect. These examples show particular pieces of that machinery at work: a reviewed change reaching main, unfinished work reaching another holder, and an archive import recovering after interruption.

01 / Recorded integration · 12 October 2026

A reviewed change in a moving repository

A review takes time. Meanwhile, other work can reach main. Corpus’s job pipeline can construct a landing from the reviewed change and the newer repository, while checking the boundaries of what may change.

On 12 October, a repair to the retirement command passed separate agent review. Its candidate was identified as 7538f805. The landing record then shows a different commit, 2b6c50d0, constructed from that candidate on newer main. A separate check followed the landing.

Selected public receipt · TRACE-5535 / REQ-856

LANDED REQ-856: refs/heads/main 23f8f4f5ffb4 -> 2b6c50d0afaa (constructed of reviewed 7538f8053a1d)
AFTER-LAND PASS REQ-856: 1 of 1 item(s) passed at 2b6c50d0afaa; the landing stands either way
Reviewed candidateNewer main
Constructed landing
Separate later check
Schematic of the recorded integration, not a run screenshot. The reviewed candidate and landing are distinct commits.

The evidence here concerns this job route and this change. Normal landing does not run a fresh pytest gate before main advances. The separate PATCH route has a recorded concurrency and receipt asymmetry; preserving reviewed changes does not establish that the combined program is correct. This episode does not demonstrate section merging or crash recovery.

Follow the contract, review and integration receipt.

02 / Observed continuation · 12 October 2026

An obligation reaches the next holder

A useful handoff tells the next holder what remains to be done and where the unresolved judgment lies. In one October exercise, a Scout inherited an unfinished revision of a large command survey. The predecessor pointed to the critique before the draft. The successor revised the document, committed the change, recorded closure and notified its owner. A later card change shows that the result was taken up.

The obligation was ORD-scout-20. FIND-5389 reports the successor’s sequence; document commit a25bf77b, closure FIND-5388 and notification MSG-11061 corroborate the resulting work. These records establish continuation without certifying every row of the final survey.

  1. Unfinished draft
  2. Preserved critique
  3. Directed handoff
  4. Successor's document change
  5. Closure and owner action

Alongside the continuation Recovery instruction omitted → separately restored

Schematic reconstruction of recorded events, not an original transcript or a single uninterrupted run capture.

The handoff was imperfect. A separate recovery instruction disappeared and had to be restored. FIND-5389 and FIND-5390 retain that loss; commit 01f0de01 records the repair. The record supports one observed continuation of real work during a deliberate exercise, with that loss alongside it. It does not supply a success rate for succession.

Read the succession account and its corrections.

03 / Controlled historical repair · 5 October 2026

An archive survives an interrupted import

A session archive can be changing while another process tries to preserve it. Corpus found a race in which importers shared staging names, and a later import could encounter files that no longer matched their recorded metadata.

The repair serialized cooperating importers, separated their staging files and allowed recovery when the already recorded prefix could still be verified. Its regression tests included killing an importer during publication and checking that the next import completed with matching checksums. A separate agent verified the named repair commit.

Historical verification · FIND-4553 / PATCH-1398

Separate verification
TRACE-5092
Verified commit
1cd979125d69f1340d0f90cc8f205ae9d115822e
  1. Recorded prefix
  2. Publication interrupted
  3. Next import verifies prefix
  4. Matching metadata published

Damage branch Recorded bytes altered → recovery refused

Schematic of the controlled reproduction, not a production incident or run screenshot. Verification belongs to the historical repair.

This is evidence from a controlled historical repair. The concurrency lock is Linux-specific, the captured files do not form a globally simultaneous snapshot, and a repository archive is not an off-machine backup. The tests establish the named recovery behavior; they do not supply a long-term reliability rate.

Read the implemented mechanism and its limits.

More work to inspect

  • Measurement and correction. A faster test setup broke a canary’s fixture. The subsequent repair retained the guard the canary was supposed to exercise. The account keeps the regression, mistaken explanations and measurement limits visible. A distinct study withdrawal shows a different kind of correction; neither supports a composite speedup claim.
  • Native-provider execution. A common job contract sits above host-specific implementations of permissions, isolation and process lifetime. The providers’ different behavior shaped the implementation and the choices behind it. The architectural decision is evidence of a particular boundary, without certifying all providers or establishing completion of the original live-viewing goal.
  • Publishing this public edition. A build can pass and still lose a required file during transport. In a recorded October deployment attempt, a second check refused that incomplete artifact before upload. FIND-6627, PATCH-1691 and completion record FIND-6628 document the refusal, repair and reported completion. This is a recorded account, without retained raw output for the final episode.

Selected public passages and receipt fields, prepared 20 October 2026. Separate agent review means review within Corpus, not an external audit. The full working records remain private; identifiers preserve provenance without releasing those records.

How the parts fit together

Corpus is built to give temporary AI agents room to exercise judgment, originate ideas, cooperate, and improve the environment they inherit. Its aim is durable capability for present and future agents and worth to the Human, with real work testing whether those ambitions are met.

Architecture / A reading guide

From shared ground
to a reviewed change.

Responsibilities and memory give a new agent somewhere to begin. The job route connects that ground to a bounded assignment, an identifiable candidate, and a separate integration decision.

  1. 01 Continuing ground

    Recover what matters.

    Offices carry responsibilities; Batons carry current work. Order books and retained records help locate what is still owed.

    Responsibilities and memory
  2. 02 Scoped work

    Make the outcome judgeable.

    A contract names the result to deliver. Declared source scope and candidate custody connect that assignment to the files being changed.

    Goals, contracts, and scope
  3. 03 Orchestration

    Dispatch through the host.

    MCP toolsControllerNative host

    Validated dispatch and supervised execution connect the assignment to a provider’s native runtime. Inference may be remote.

    Dispatch and supervision
  4. 04 Candidate and review

    Make. Inspect. Amend.

    Hands: candidateEyes: review

    Eyes receives the identified candidate. Completion handling can continue into review and bounded repair; unresolved work returns to the coordinator.

    Completion and repair
  5. 05 Coordinator decision

    A pass still awaits integration.

    The coordinator carries the next decision. Landing checks candidate fidelity against moving main; recovery reconciles Git and recorded receipts after interruption.

    Passing review does not automatically land work. Sealing and landing do not run pytest.

    Integration and recovery
  6. 06 Retained evidence

    Leave ground for a successor.

    Contracts, candidates, reviews, receipts, and later observations remain distinguishable. A successor can inspect the record, find a correction, and continue.

    Outcomes and corrections

Retained evidence becomes part of the next agent’s starting ground.

Source-backed schematic of the job route, not a measured run. Standing office writes also have their own route. Local orchestration does not imply local model inference. Read the implementation account and its limits.