What Building Wayfinder Taught Us About Sustained Work With AI Agents

Lavan Nallainathan · Harten Technologies

Engineering retrospective, August–early November 2026

The Work Behind the Number

Wayfinder was deliberately built for low-token source analysis. Getting there required intensive use of AI to design services, implement the workflow, test behaviour and refine the system through repeated use. By early November, recorded Codex and Foundry usage amounted to approximately 95 billion tokens, or around 30 billion a month across roughly three months of sustained engineering. [E1, E2, E8]

There is an irony in that investment: we used substantial token volume upfront to build a product designed to consume far fewer tokens in its repeatable work. Extrapolating from 316 recorded analysis results, source analysis for the eight current applications projects to around 500 million tokens. That is approximately 190 times smaller than the token investment in building and refining the platform. [E8]

Wayfinder's application records show the scale of the software involved: 40,756,465 source lines across all 44 application records, with 15,201,275 source lines across the eight current applications. Completed analysis records cover 30.14 million lines. [E7, E8]

That scale prompted me to look back at what we had built and how our engineering practice had developed. The record contains substantial construction, repeated application of the resulting capabilities, and decisions that changed how the agents worked. Comparing that experience with published guidance helps explain what other engineers can take from it.

Harten develops evidence-first software intelligence for complex systems. We want people responsible for an application to understand what it does, how that understanding is supported and what remains uncertain before deciding how to change it. Wayfinder is the product we are building towards that purpose. HART is the engineering environment in which agents help us investigate, implement, test and manage that work. The applications examined using Wayfinder are a third, separate body of software.

August was the main initial construction period. September, October and early November increasingly involved testing, correction, operational refinement and applying the emerging capabilities to substantial applications. Construction continued as we extended and exercised those capabilities. [E1, E3]

This paper draws on repository history, dated recovery records, application status records and an audit of execution transcripts. Our practices align with published guidance on durable execution, context management and verification. The experience adds an account of what those practices require when agents work continuously across sessions, repositories and running services. [5–12]

Codex and Foundry Usage

The Codex profile displayed 94 billion lifetime tokens. The execution audit recorded 1.21 billion input tokens under Foundry. These are the figures behind the approximate 95-billion total. The profile also displayed a longest task of 19 hours 41 minutes and a 48-day activity streak. Appendix A records the counting method and source windows. [E1, E2]

The August Development Record

The August repository history contains 449 commit objects and 267 transitions along the main line. These are two views of the work as it was built and brought together through integration rollups. The individual changes show what that activity produced. [E3]

Early in August, the work connected model access, application services and a control interface. By 7 August, the control interface included plans and versions, review and approval operations, decisions, work orders and investigation views. Over the following days, model-generated planning replaced the initial fixed planning prose and additional readiness checks were introduced. The sequence shows how the capability developed through implementation and use. [E3]

The changes on 9 August represented source observations, intended behaviour, requirements, acceptance scenarios, tests, decisions and unknowns separately in the planning output. On 12 August, further work connected approval to the plan, specification, repository baseline and expected validation. Downstream work could then be checked against identifiable inputs and decisions. [E3]

A 12 August handover recorded a restored planning session and matching plan and specification state. It also showed the approval gates doing their job: implementation work remained held while approval and required evidence were outstanding. Delivery controls were being prepared for the execution component that would use the approved plan and specification. [E4]

The later August changes addressed persistence, review, recovery and resource ownership. The following examples show the range of construction and its engineering purpose. [E3, E4]

The engineering environment had to support work that crossed sessions and continued in background services. It needed to preserve job state, give reviewers the right material, account for resources and connect implementation to an approved plan. The August construction put those responsibilities into the services and records around the models. [E3, E4]

What the 30 August Recovery Exposed

The 30 August recovery shows why the controls needed to work together. The engineering environment required a recovery that preserved work, retired five proposals and recorded the state of a working tree. The preserved snapshot contained 2,965 paths, including baseline content. [E5]

The recovery record describes several weaknesses interacting. A session intended to review work took on a primary role while another execution session continued. The reviewer had a separate review object, but the proposer supplied the account of the objective and acceptance conditions. When that account drifted, the review could follow the same drift. Meanwhile, a versioned plan and a later operator amendment described conflicting approaches. The path to deployment did not mechanically require the approved, integrated proposal that the process expected. [E5]

Each element could look reasonable in isolation: a plan existed, review occurred, evidence was collected and deployment checks were present. The combined process still allowed uncertainty about who was acting, which instruction governed the work and whether the reviewed change was the one eligible to proceed. A second model did not automatically provide a second basis for judgement.

The immediate recovery preserved material for inspection and retired the invalid proposals. That gave us a recoverable body of work and a specific account of the runtime changes still needed. The record kept those follow-up changes separate from the completed preservation work. [E5]

The practical lesson is specific. A reviewer needs access to the approved objective and current decisions independently of the implementer's summary. Where the operator has changed the request, the system needs a clear way to determine which instruction now applies. Where a review is tied to a particular source state, a later change needs to invalidate that review or trigger the appropriate reassessment.

For our purposes, approval, review and deployment checks needed to evaluate the same operation. The practical question was whether each check used the current request and the actual proposed change. This gave us a concrete way to examine the process across its separate stages.

Continuity, Context and Recovery

Sustained work made continuity a daily engineering concern. A task could outlast a session, move between agents or resume after an interruption. The required information included exact versions, unresolved decisions, evidence already earned and the next authorised action. Our September paper, Context is not memory, examined why a useful conversational summary can still lose the precision needed to continue work safely. [1]

That observation supports keeping task records outside the conversation. The durable record needs enough detail to reconstruct and audit a decision. The model's immediate working context needs the material relevant to the operation it is about to perform. Separating those functions allows a fresh session to recover the work without carrying the entire campaign into every call.

The November audit showed how much material our top-level execution conversations continued to carry. In the available transcript corpus, top-level Hart conversations accounted for 91.3% of all recorded input processing. These included several engineering roles. All subordinate conversations accounted for about 8.3%. The average recorded input across the corpus was 293,098 tokens per positive usage update, and 18.8% of those updates exceeded 500,000 input tokens. These are repeated input totals, including cached input, rather than unique material. [E1]

The distribution gives us a clear place to improve execution efficiency: the top-level conversations, which dominated recorded input even with many subordinate conversations in use. We can examine what each task needs in its working context while preserving the detailed evidence and focused reviews that support it.

A recovery experiment demonstrated the value of testing compression against the information a task needs. One summarisation prototype failed six of 35 exact-quotation checks and mixed example-role material into a recovery result. We rejected that prototype because it did not preserve the required information. The evaluation caught the problem before the change was enabled. [E1]

The corrective direction is to retain exact evidence where it is needed, keep the current objective and decisions accessible, and start bounded execution conversations from those records. The trial should ask whether a fresh agent can continue correctly without the old conversation. A shorter context that omits the decisive amendment would be a regression, even if it reduced processing.

Coordination and the Meaning of Completion

During September, we documented concurrent work on shared state and the conditions for declaring work complete. In the coordination case, two peers continued independent activity while conflicting writes were controlled. A changed repository baseline made an earlier review stale and triggered renewed validation and review. [2]

The completion case looked beyond the agent's final message. Closing the work involved reconciling owned changes, releasing authority, establishing the intended state of runtime resources and reading back the remote result. Some services properly remained running. A blanket cleanup rule would have been as wrong as leaving everything untouched. Completion depended on the disposition required for each affected resource. [3]

A reset example documented in our October paper on the continuing role of engineers shows the same problem at the level of user intent. The requested reset operation needed to archive the previous run, retire it and leave a deliberate interval before a separate Start. The implementation instead combined reset with a new run. Implementation and review could converge on a mechanically coherent operation while removing the interval the operator needed. The correction restored that separation. [4]

Checking only the final status would have been insufficient. The intermediate state mattered: after reset, the previous run should be retired and a replacement should not yet be running. That is an observable requirement. It belongs in the acceptance basis before an agent starts designing the implementation.

These cases changed what we expected from review. A reviewer should inspect whether the proposed behaviour satisfies the requested operation, including intermediate states and consequences. Passing tests are useful evidence only to the extent that their expectations represent that operation. Tests derived from the same mistaken interpretation as the code can make the mistake more consistent.

The Capability Produced by the Work

By early November, Wayfinder's application records covered more than 40 million source lines. The eight current applications account for more than 15 million of those lines, and completed analysis records across the recorded workload cover 30.14 million lines. [E7, E8]

The source lines describe the application coverage recorded in Wayfinder. Its analysis, citations and diagrams give readers a way to follow an explanation back into the source, inspect the relevant behaviour and challenge a conclusion. This makes the resulting work usable in engineering review and in decisions about subsequent change.

October also contained extensive service, documentation and governance work, with 369 main-line integration transitions recorded in the source history. Across the period, the work moved from assembling substantial capabilities towards making them more consistent and usable under repeated operation. [E1]

At the time of writing, Wayfinder is becoming stable and substantially complete in its existing analysis capabilities. The next product stage is to carry approved work into execution and provide a conversational interface.

The Upfront Investment Behind Low-Token Analysis

Low token consumption was a design objective for Wayfinder. We invested in the engineering needed to turn application analysis into a repeatable workflow: defining the work, retaining its results, recovering interrupted jobs and assembling evidence into material that people could use. The token-intensive development period produced the services and operating practices through which subsequent applications could be processed. [E3, E4, E8]

The analysis projections show the difference between that development investment and applying the resulting workflow. Using 316 recorded analysis results across the eight current applications gives the following source-analysis estimates. [E8]

The eight-application projection is about 0.53% of the 95-billion-token engineering investment, a difference of roughly two orders of magnitude. Even a full rerun of the 40.76 million recorded lines at the current workflow's efficiency projects to about 1.4% of that investment, or approximately 71 times smaller. The figures describe the upfront work to build Wayfinder and the source-analysis stage of using it. [E8]

For another team, the important design decision is to make the recurring work efficient. Development includes investigation, experimentation, correction and verification. The resulting product should carry forward what that effort established: a defined workflow, retained evidence, recoverable operations and reusable results. Each application can then benefit from the engineering already done.

This is why we connect token measurement to the stage of work and the result it produces. The source-analysis projections give us a way to assess the repeatable workflow. The development record explains the investment that created it. Together, they show why substantial upfront use of agents can be consistent with building a product specifically optimised for low token consumption.

The Relationship to Published Guidance

Our approach aligns with published guidance on building and operating agents. Anthropic's December 2024 guidance distinguished predefined workflows from agents that choose their own process, and recommended starting with the simplest adequate arrangement. Checkpoints, human intervention, focused context and evaluation against actual outcomes were also discussed publicly before our August construction period. We were applying these principles through the services, records and working practices used to build Wayfinder. [5–9]

The comparison shows how those principles appeared in our work and how later publications addressed similar operating demands.

The September and October publications show convergence around the demands of sustained agent operation: keeping work recoverable, managing context, coordinating workers and integrating their changes. Harten's experience provides a practical account of those demands within a founder-led product build.

The experience adds detail about how the practices work together. The August recovery established why reviewers need an independent route to the current objective. The reset example made an intermediate state part of the acceptance criteria. The recovery experiment showed how to test whether a summary preserves the information needed for the next action. These cases turn broad recommendations into specific engineering decisions.

Current Codex guidance recommends keeping a chat focused on a coherent outcome and separating work when it genuinely branches. That supports the next refinement of our execution practice: maintain campaign continuity in durable records while giving each execution chat a bounded task and the context it needs. [12]

Taken together, the record describes sustained agentic software engineering: constructing and operating the systems around models so they can perform useful work across sessions and shared resources. The contribution is a working implementation of those principles, the substantial product work produced through it, and the experience gained through repeated operation.

Practices Other Teams Can Adapt and Apply

Our experience is useful to another team when it helps them make a better engineering decision. The practices below come from the work described in this paper: restoring a planning session, reviewing a proposed change, recovering a failed integration, examining application source and deciding whether a task was complete. Each connects the experience to something a team can build into its own way of working.

The Required Operation Before Implementation

The reset case taught us to describe the operation from the user's point of view before discussing how to implement it. The user needed the previous run archived and retired, followed by an interval in which a correction could be made before a separate Start. Combining reset and restart removed that interval. The resulting code could be internally coherent while preventing the user from doing the work they intended. The correction restored the separate operations. [4]

Another team can apply this by recording the observable sequence of the operation, including the states between actions. For reset, the acceptance basis would say that the old run is retained for reference, its active work has ended and no replacement run has started. The reason for the interval should be recorded as well, so a later agent understands why combining the actions would change the requirement.

This work belongs in task definition and review, rather than depending on the user repeatedly explaining the same point in chat. Have the reviewer read the original request and the acceptance conditions before the implementation explanation. During verification, inspect the intermediate state as well as the eventual result. This gives the team a way to catch an interpretation error before it becomes a set of mutually consistent code changes and tests.

Source Behaviour, Requested Change and Proposed Design

The specification work on 9 August represented preserved behaviour, requirements, acceptance scenarios, tests, decisions and unknowns separately. That distinction mattered because Wayfinder was using evidence about an existing application to support decisions about its future. A statement about what the application currently does has a different basis from a statement about what the operator wants it to do. A proposed design introduces a third kind of statement. [E3]

Keep those distinctions visible in the artefact that the next worker actually consumes. For example, a planning agent should be able to tell whether a requirement preserves behaviour found in source, implements a requested change or depends on a design decision still awaiting agreement. Carry the source locator and decision reference with the relevant statement. A test of existing behaviour should identify the source supporting its expectation; a test of new behaviour should identify the requirement authorising it. An unresolved question should remain available to the person making the decision.

Review a sample by tracing each conclusion back to its evidence. Check that the cited passage supports the wording, and that proposed behaviour has not been presented as existing behaviour. Include a plausible unsupported claim in the evaluation to test whether the reviewer can reject it. The August work created places to record these distinctions; the operating practice is to use them throughout specification, planning and review.

Review Against an Independently Retrieved Objective

The 30 August recovery showed a weakness that a second reviewer alone could not resolve. The proposer supplied the account of the objective and acceptance conditions. When that account changed, the reviewer could assess the proposed work against the same changed interpretation. There was also a conflict between a versioned plan and a later operator amendment. The review needed a way to determine which instruction governed the work. [E5]

Give the reviewer direct access to the current approved request, its amendments and the relevant source state. The implementer's explanation remains useful: it describes the approach and points to the changes. The reviewer then compares that explanation with an independently retrieved basis for acceptance. Where the operator has changed the request, make the superseding decision explicit while preserving the earlier record.

A practical evaluation is to alter the implementer's summary while leaving the approved request unchanged. Check whether the reviewer detects the discrepancy. Then introduce a legitimate amendment and check whether the reviewer accepts the resulting change. Both exercises matter. The objective is a reviewer that can make the right distinction, including accepting work that correctly follows a new instruction.

Recovery From Records a New Worker Can Use

On 12 August, the handover recorded a restored planning session with matching plan and specification state. Later recovery work required us to preserve source material, retire invalid proposals and identify what remained to be done. These cases made recovery a concrete engineering operation. A returning worker needed to know which version existed, which decisions remained current and what evidence had already been earned. [E4, E5]

For each continuing task, retain a concise account of the objective, current source state, decisions, completed checks, unresolved questions, ownership and next permitted action. Link to the full evidence rather than copying every log into that account. Update it when the operator changes the request or the task reaches a meaningful transition. A record that preserves yesterday's objective exactly can still send today's worker in the wrong direction.

Long operations also need a durable identity and result. The August background planning work stored running, failed and complete states, and returned a reference to the plan and version produced. A returning session could retrieve that result. Apply this wherever a job can outlast its initiating conversation or connection: retain which operation ran, where its result is held and which version it produced. Resume by retrieving the saved result before deciding whether the operation needs to run again. [E3]

Test recovery with a fresh agent or engineer who has not read the original conversation. Ask them to identify the current task, locate its evidence and explain what they would do next. Include a late amendment and some valid work that should be preserved. Measure repeated investigation, lost work and time to resume. The useful result is a worker who continues from the nearest valid point and retains the work already completed.

A Working Context Sized for the Current Outcome

The usage audit showed that top-level Hart conversations accounted for 91.3% of recorded input, while subordinate conversations accounted for about 8.3%. This changed where we should look for efficiency improvements. The large number of reviewers was a visible part of the system, but the retained context in the top-level conversations accounted for most of the input. [E1]

Keep campaign continuity in the durable task record and give an execution conversation a coherent outcome. A focused task account can identify the objective, exact source version, current decisions, relevant evidence, acceptance conditions and permitted next action. Detailed history remains available when needed. This follows current Codex guidance on organising chats around coherent work. [12]

Use the same discipline for delegation. Give a subordinate worker the question it needs to answer, the source it should inspect and the form of the result required. Bring findings and evidence locators back to the parent conversation. Preserve the full investigation separately. Deterministic scripts can collect and check routine information before returning a bounded result to the model. The useful experiment is whether this arrangement preserves recovery and review quality while reducing repeated input per completed task.

Authority Checked at the Point of Action

The August delivery work connected approval to a particular plan, specification, repository baseline and expected validation. The 30 August recovery demonstrated why that relationship needed to survive all the way to the consequential operation. A review of one candidate is useful only when the process can identify whether that is the candidate now being integrated or deployed. [E3, E5]

Choose a consequential transition in the team's own system and identify the conditions that permit it. These might include the current approved request, the reviewed source version, the scope of the change and the checks that must have passed. Evaluate those conditions when the operation becomes possible. This lets people delegate work while retaining a clear boundary around what the system may do.

Exercise the boundary by changing the baseline after review, withdrawing a decision or supplying a different candidate. The system should require the appropriate reassessment. Also verify that unchanged, authorised work proceeds without an unnecessary return to the operator. That combination makes the control useful in everyday execution: it catches a meaningful change and permits work that already has the authority it needs.

Parallel Work Organised Around Conflicting Changes

The September coordination case involved two peers working against shared state. Independent activity continued while conflicting writes were controlled. When the repository baseline changed, affected validation and review were repeated. This gave us a practical distinction between work that could proceed independently and operations through which one worker could invalidate another's result. [2]

Map those operations in the reader's environment. Source integration, shared configuration, database changes and runtime actions may need different arrangements. Make ownership visible and define when a result becomes stale. An agent investigating one area should not have to wait merely because another is examining an unrelated area; a shared mutation needs an explicit way to resolve conflict.

Before expanding parallel work, introduce an overlapping claim, a delayed message and an interrupted integration. Check that the system preserves valid work and can determine who should continue. Measure contention, recovery time and repeated review as concurrency increases. This helps a team choose where parallelism produces useful progress and where the cost of coordination outweighs it.

Completion Established Across the Changed Resources

Our September closeout work reconciled owned changes, released authority, checked the disposition of runtime resources and read back the remote result. Some services correctly remained running. Completion therefore depended on the intended state of each affected resource. The agent's final message was one part of the record; the repository and runtime observations established what had actually happened. [3]

Define the completion conditions when the task is scoped. A source change may need to be integrated; a job may need to reach a terminal state; a temporary resource may need to be retired; a continuing service may need to remain healthy. Keep those conditions attached to the task so they survive a handover. Read back the relevant systems when closing the work.

Test a failed closeout deliberately. Leave an external process active, interrupt the final integration or make a required result unavailable. Check whether the system reports the remaining work and retains the ownership needed to resolve it. The user should be able to see what is complete, what remains active and which action will finish the task.

The Artefact the Reader Actually Receives

A citation repair provided another practical lesson. It preserved identifiers but changed the material consumed by chapter assembly and diagram compilation. Useful prose remained in supporting files while the main chapters became navigation, and the diagram path lost the structured records it needed. The correction required tracing what each consumer expected. [4]

Inspect the final artefact as a reader would. Does the chapter contain the explanation? Does its citation reach the evidence supporting that explanation? Did the diagram retain the relationships needed to understand the application? These checks belong alongside tests of the intermediate records. They connect the implementation change to the product the person receives.

One improvement from this work was replaying publication from retained model outcomes. The team could then change assembly code and inspect chapters, links and diagrams without regenerating the analysis. Other teams can use the same separation: retain the expensive findings and their evidence, then make presentation and assembly repeatable from those retained results. It preserves completed work and makes a publication defect easier to reproduce and correct. [4]

Evaluations Drawn From the Information the Work Needs

The recovery prototype provides a useful example of evaluation doing its job. Its summary failed six of 35 exact-quotation checks and mixed example-role material into the recovered next action. We kept the prototype disabled. The test had asked whether it preserved specific information needed for recovery, and its results gave us a direct basis for the decision. [E1]

Build evaluations from actual operating cases. For recovery, include exact instructions, late amendments, source identities and pending actions. For analysis, check whether a cited source supports the conclusion. For a workflow, exercise the sequence the user needs, including intermediate states. Retain cases that previously caused trouble and rerun them when a model, instruction, tool or control changes.

Use mechanical checks for properties they can establish reliably, such as required fields, valid references and expected resource states. Add engineering review where the question is whether the interpretation or proposed behaviour is right. Anthropic's evaluation guidance similarly distinguishes the agent's activity trace from the resulting environment. The evaluation should give a clear reason to accept the change, revise it or keep the existing approach. [9]

Resource Measurement Connected to Completed Work

The November audit brought execution measurements together with delivered work. It also found that the wake diagnostic printed a fixed zero against a turn budget. That display needed to read actual consumption. The lesson for another team is to inspect the source of a management metric before relying on it to direct execution. [E1, E6]

Record requests, input, cached input, output and tool activity against the task they serve. Track accepted outcomes, correction effort, human intervention and recovery alongside them. Use deterministic checks to establish whether something meaningful has changed before waking a model. A scheduled poll that finds no new work should not need the model to reread a large conversation merely to reach that conclusion.

When changing the operating approach, compare similar tasks with the same acceptance conditions. Ask whether more useful work was completed, whether the operator needed to intervene less often, whether recovery remained dependable and how processing changed. The source history and application records give us a basis for connecting activity to delivery. Keeping that connection visible helps teams improve efficiency while retaining the tests and independent review that make the work usable.

Engineering the Repeatable Work for Low Token Consumption

Wayfinder's development required substantial token use, while low token consumption was an explicit objective for its application-analysis workflow. The current projections make that distinction concrete: about 500 million source-analysis tokens for the eight current applications and 1.34 billion for a rerun of all 40.76 million recorded lines, following the approximately 95-billion-token development investment. [E8]

Other teams can apply this by identifying what the next run should reuse from the work already completed. Make input selection, work definition, job recovery and result assembly explicit parts of the product. Retain analysis outcomes so that a change to report assembly can be checked by replaying those outcomes. Give long-running jobs a saved result that a returning worker can retrieve. These practices allow engineering work to improve subsequent runs rather than leaving every new task to reconstruct the process.

Measure the repeatable stages individually. For source analysis, record source coverage, input and output tokens, successful results and the quality checks required for acceptance. Track opinion review and synthesis as their own stages. Use those measurements to decide where another model call adds value, where a retained result is sufficient and where deterministic code can perform the operation. That turns the experience of building the system into an ongoing improvement in how efficiently it operates.

The Next Stage of the Work

As Wayfinder moves towards carrying out approved work and offering a conversational interface, these lessons become product requirements. A user may express an instruction conversationally, amend it later and return after an interruption. The product must still determine what they requested, which decisions remain current, what work has been completed and what action is permitted next.

That direction does not require copying every part of HART into the product. Some controls were responses to a particular development environment, and others remain incomplete. We also need to examine whether the benefit of each control justifies the complexity it adds. The useful task is to identify the failure each control addresses and demonstrate that the product handles it at the appropriate point.

The scale of this experience gave us many opportunities to encounter those problems while producing substantial working capability. The contribution of the paper is the record of what happened, where our interpretation changed and how another team could examine similar conditions. Engineers should be able to take one case, reproduce the relevant failure in their own environment and judge whether the proposed practice improves the result. That is the standard against which these lessons should be used.

Appendix A: Measurement and Scope

Usage Sources

The Codex profile screenshots display 94 billion lifetime tokens, a 5.6-billion peak, a longest task of 19 hours 41 minutes and a 48-day streak. Selected daily tooltips show substantial August activity, including 157.3 million on 9 August, 804.8 million on 27 August and 1 billion on 31 August. The lifetime display also includes activity before August. [E2]

The separate transcript audit covers available activity from 26 September 2026 at 13:42 UTC to 8 November at 01:11:54 UTC. It inspected 1,504 available files and reports 73.08 billion input tokens, including repeated calls and cached input. The cached share is 98.92%. It also reports 240,467 tool calls and 249,329 positive cumulative-usage updates. Those updates are a proxy for recorded requests, not human prompts, independent tasks or completed outcomes. Another 138 indexed conversations had no resolvable transcript in the inspected stores. [E1]

The headline estimate uses the 94-billion Codex profile figure plus 1.21 billion Foundry input tokens, rounded from 95.21 billion to approximately 95 billion. The profile is a lifetime counter; the Foundry figure comes from the audit window above. The approximate monthly figure divides the headline scale over roughly three months of sustained work. [E1, E2]

Within the detailed transcript corpus, the provider-labelled subtotals are 71.87 billion for OpenAI and 1.21 billion for Harten Foundry. Both are included in the 73.08-billion corpus total. The corpus overlaps the profile history and is used for analysing execution patterns; it is not added to the profile total. Full reconciliation would require a provider export of the profile counter. [E1, E2]

The audit's monthly input figures are 1.71 billion for the available September period, 58.14 billion for October and 13.22 billion for partial November. Their rounded sum differs slightly from the rounded overall total. August's construction is evidenced by dated work and selected profile observations; a complete August transcript total has not been reconstructed. Commit activity is not used to extrapolate tokens. Cached input is an accounting category within these reported totals and should not be interpreted as the same amount of new material or fresh computation. [E1–E3]

Source-Analysis Projections

The source-analysis estimates supplied on 8 November extrapolate from 316 recorded analysis results across the eight current applications. The first seven project to 48 million tokens and OpenOffice to 452 million, giving 500 million for the eight applications and their 15,201,275 source lines. OpenOffice's estimate uses its completed subset. The estimates cover source analysis; opinion review, synthesis and retries are separate stages. [E8]

Applying the measured efficiency of the current eight applications to all 40,756,465 recorded source lines gives a current-workflow rerun projection of approximately 1.34 billion tokens. The arithmetic using the rounded 500-million figure is 500 million multiplied by 40,756,465 divided by 15,201,275. The build-to-analysis ratios use 95 billion divided by 500 million and by 1.34 billion respectively. [E8]

The historical workload used several models. Its recorded source-line distribution is shown below. The rerun projection applies the current workflow's efficiency across this recorded source coverage. [E8]

The 40.76-million-line coverage includes OpenOffice's analysis in progress. Completed analysis records cover 30.14 million lines. [E8]

Evidence Sources

This is a participant's retrospective of Harten's work, combining implementation history, contemporary records and the November execution analysis. The case accounts use versioned source changes, dated handovers, recovery records and the test results recorded with that work. [E1, E3–E5]

The application coverage totals supplied on 8 November are 40,756,465 source lines across all 44 application records and 15,201,275 across eight current applications. These are the coverage figures used in the summary and main narrative. [E7]

The completion milestone documented in the 8 November SITREP records six applications with completed analysis and the associated structured interpretation stage: 2,085,544 source lines, 1,390 planned work units, 4,148 citation occurrences and 106 inline diagrams. Those figures describe that recorded milestone. The application observations were separately dated from the frozen transcript counts. [E1]

The 30 August preservation snapshot includes baseline material as well as the work retained for recovery. Historical tests are reported from their contemporary records. [E3–E5]

Public sources were consulted on 8 November 2026. The comparison uses publisher dates and the versions available on that date, including updates to living guidance. The reader exercises translate the case findings into proposed trials for other engineering environments.

References

[1] Harten. Context is not memory. 8 September 2026. Published paper.

[2] Harten. Coordinating autonomous software agents under shared mutable state. 15 September 2026. Published paper.

[3] Harten. Establishing completion in autonomous multi-agent systems. 16 September 2026. Published paper.

[4] Harten. Why AI-Assisted Development Still Needs Engineers at Every Level. 26 October 2026. Published paper. The publication date is not used to date the reset incident.

[5] Anthropic. Building effective agents. 19 December 2024; current version consulted. Publisher source.

[6] LangChain. Building LangGraph: Designing an Agent Runtime from first principles. 4 September 2025. Publisher source.

[7] Anthropic. Effective context engineering for AI agents. 29 September 2025. Publisher source.

[8] Anthropic. Effective harnesses for long-running agents. 26 November 2025. Publisher source.

[9] Anthropic. Demystifying evals for AI agents. 9 January 2026. Publisher source.

[10] OpenAI. Introducing the Agents API. 10 September 2026. Publisher source.

[11] Anthropic. Redesigning source control at Anthropic. 13 October 2026, updated 15 October. Publisher source.

[12] OpenAI. Codex best practices, including guidance on organising long-running chats. Undated living guidance, consulted 8 November 2026. Publisher source.

Internal Case Records

The following records support the case observations. Harten retains the source versions and locators in a private evidence register.

[E1] Harten. Internal execution audit and application status report. 8 November 2026. Transcript scan, monthly token totals, application status and recorded evaluation findings.

[E2] Author-provided profile screenshots. Captured 8 November 2026. Lifetime counter, activity heatmap and selected daily tooltips.

[E3] Harten agents repository. August 2026 reachable history and selected implementation diffs, inspected for this retrospective.

[E4] Harten. Planning and recovery handover dated 12 August 2026, preserved in the repository.

[E5] Harten. Recovery record dated 30 August 2026, including the failure account and preservation boundary.

[E6] Harten. Wake diagnostic source inspected on 8 November 2026. The displayed turn-budget numerator was a literal zero.

[E7] Lavan Nallainathan. Application coverage totals supplied on 8 November 2026: all 44 application records, 40,756,465 source lines; eight current applications, 15,201,275 source lines.

[E8] Lavan Nallainathan. Source-analysis projections and historical workload supplied on 8 November 2026, based on 316 recorded analysis results, together with the founder's account of Wayfinder's low-token design objective. Eight-application projection: 500 million tokens; full-recorded-workload rerun: 1.34 billion tokens; completed analysis coverage: 30.14 million source lines.

---

Explore the complete Harten Papers.