Six hours of work, and a decision that remained mine

By Lavan Nallainathan · Harten Technologies

HART carried out roughly six hours of engineering work today, essentially autonomously. My interventions were to review its outputs and decide the next best course of action. During that work I was also having a separate conversation about the company while HART continued executing. The 44 minutes and 49 seconds shown in the final handoff was the last run segment within that longer workstream.

I am becoming used to this, although I still find myself checking what it is doing. Sometimes it works well. Sometimes it goes awry. That is part of the experience of building these systems, and I think it is worth describing an ordinary piece of work with its unresolved result still attached.

HART is the execution agent I work with at Harten. It operates with persistent instructions, memory, work records and controls around what it may do. Git-Hart provides the governed change process: proposals, review evidence and a connection between the exact change reviewed and the change integrated. These are parts of the working system we are developing, and I use them in the work of building it.

The workstream involved repairs, checks, review and integration within our software analysis workflow. Its final stage was a bounded model comparison. We wanted to see whether a different model could improve attribution and citations against a retained input. The comparison had to preserve that input, remain within an existing allowance and go through independent review. A better-looking answer would not, by itself, qualify the capability for wider use.

There was quite a lot of engineering between that instruction and the result. The comparison path had to be implemented, the model route checked, the input reconstructed and the changes tested and reviewed. During the work, HART reported finding a routing problem before spending the model call: changing the local receipt would still have sent the request to the previous model. It corrected the mapping for the comparison without changing the global route.

The recording then shows the workflow reporting that the original input and request hashes had been reproduced, the frozen change had passed 1,858 tests, and the independent reviewer had also run those tests and reproduced the retained input. Approval was recorded before the reviewed change was integrated. HART carried those steps forward without me reminding it at each transition.

That is the part that has changed my working day. Across the roughly six hours, HART was carrying out the execution. I reviewed outputs, checked that the process was holding together and decided where the work should go next. In the recording, I ask about review pressure, Git-Hart proposals and independent review. After HART reports that an approved proposal is awaiting integration, I tell it to integrate so it does not go stale. Those interventions show the role I was playing throughout the workstream: review and direction, with HART carrying the engineering forward between decisions.

The result was still blocked.

The comparison improved attribution and citations, but independent review found one material missing citation. The final report kept quality qualification blocked. One call had been used, bringing the cumulative count to 31 out of 34. The three unused calls did not automatically become permission to keep trying. Wider execution and acceptance remained gated.

I had to intervene at that point, and I thought that was appropriate. The system had completed the bounded comparison and brought back an unresolved quality issue. My next responsibility was to decide what further work, if any, to authorise. I did not need to take over the implementation simply because the result had failed to qualify.

There is an important distinction here between a change passing its engineering tests and the output meeting the standard required for its intended use. The tests supported the comparison machinery. The citation review addressed whether the resulting analysis was adequately supported. Both mattered, and success in one did not settle the other.

This is also why I care about persistent state. Over a long piece of work, the system needs to retain the objective, the constraints, what has already been established and what remains unresolved. A compressed recollection of a conversation can lose the distinction between something that improved, something that passed a local check and something that was actually accepted. Those differences have to survive the next context window.

I do not regard one run as proof that we have solved reliable autonomy. The screen excerpts show the workflow's reports, and the underlying evidence is what those reports must stand against. We still have failure modes to address. I also want the handoff to become more useful: the unsupported claim, why it matters, the proposed next action and its likely cost should be available together, so I can decide without reopening the investigation.

But this is becoming a practical way of working. For Harten, which is building evidence-first software intelligence for complex systems, the question is whether more useful work can proceed while the authority to accept consequential outcomes remains clear. Today, I had room to step away from execution. When I was needed again, there was a specific reason and an unresolved decision waiting for me.

Addendum — when there is more than one HART

Five days later I saw a different problem.

Two HART tasks were working against the same repository. One was repairing the MaaS baseline demonstration while another was preparing a bounded model-training experiment.

The first task completed its change and independent review. Before it could integrate, `main` changed.

It stopped.

The reviewed change was now stale because the state against which it had been reviewed no longer existed. Rather than treating the approval as transferable, HART rebound the repair to the new base, reproduced its validation and sent the resulting proposal through independent review again.

At the same time, the second HART identified itself to the first. It declared the files it owned, asked that its working changes be preserved, and agreed to hold mutations to `main` during the other's integration window. It did not stop working. It continued preparing the experiment in isolation.

The first HART acknowledged that boundary, integrated the reviewed repair, reattached `main`, verified that unrelated working files had been preserved, and sent an integration-clear message back to the other task. The second HART picked that up and continued.

I did not coordinate that exchange.

That matters more to me than simply running two agents in parallel. Parallelism is relatively easy. The harder problem is allowing independent processes to operate against shared mutable state without allowing one process to invalidate, absorb or overwrite the work of another.

There was useful judgement inside the second task as well. While waiting for the integration window, it discovered that an earlier recovery dataset represented only three code families. Reusing it would have reproduced the coverage problem the experiment was intended to test. It instead constructed a balanced dataset across all twelve original families while leaving the retention tests unchanged. The resulting 120-example dataset was then frozen after its checks passed.

So neither process was simply waiting for instructions from the other. Each continued within its own authority boundary while coordinating the state they shared.

I am still careful about what this demonstrates. These are observations from HART running through Codex, not evidence that the general problem of multi-agent software engineering has been solved. Codex provides capabilities that make this form of task-to-task interaction possible. HART and Git-Hart provide the operating rules around ownership, evidence, review and integration.

But it changes the question I am interested in.

The question is no longer only whether an agent can carry useful engineering work for six hours while a human retains consequential authority.

It is whether several such processes can work on the same evolving system, recognise when their evidence has become stale, negotiate access to shared state, preserve each other's work, and continue independently without turning the human into their coordinator.

---

Clarification, 10 September 2026: the roughly six-hour workstream was essentially autonomous throughout, with human interventions for review and direction. The 44m 49s timer refers to the final run segment. The selected screen excerpts illustrate the workflow; the overall duration and division of work are my account of the session.

Addendum, 15 September 2026: the multi-HART sequence above is a second working observation from the same developing system. It records behaviour observed in HART and Git-Hart running through Codex; it is not a comparative claim about other agent systems or evidence of general multi-agent reliability.

This is a standalone working observation, outside The Modernisation Control Papers. More writing and the complete series are available at the Harten papers archive.