Machines directing machines: how software agents can manage other agents under human control

By Lavan Nallainathan · Harten Technologies

Abstract

Software-engineering agents are becoming capable of carrying substantial work without someone directing every action they take. Once several agents can work independently, another problem appears above the implementation work. Someone still has to decide which agent should investigate a problem, which one should implement a change, what should happen when an investigation changes the apparent scope of the work, and whether the result is actually complete.

The obvious response is to introduce another agent to coordinate them. That helps only if the coordinating agent itself has clear limits.

This paper reports an empirical case from Harten in which one HART coordinated work performed by several other HARTs. The coordinating Hart could work with me to establish a bounded work item, allocate investigation or implementation to other Harts, receive their findings and remain responsible for establishing that the agreed work had been completed. It could not decide that an investigation justified a different product outcome, expand the scope I had authorised or inherit my authority simply because other agents were working through it.

Those relationships were not held only in the context window of one model. They were written into HART's operating doctrine. The doctrine described who could delegate, who could investigate, who could implement, what had to return to me, how independent review remained separate from implementation, and what evidence was required before work could be considered complete.

The same period produced a useful failure. A defect in the session-control system left historical Hart sessions unresolved and eventually prevented legitimate new sessions from starting. An earlier Hart identified that the supported recovery mechanism it needed did not exist, but its operating rules caused it to stop at that point. The model was capable of writing the missing mechanism. The system had not yet made that part of the responsibility attached to the authorised repair.

I changed the doctrine. Another Hart implemented the missing recovery route under independent review, the authorised historical sessions were recovered, and future primary Harts inherited a clearer responsibility for seeing this class of repair through to completion.

These observations suggest that increasingly autonomous engineering systems need more than capable models and a way to launch several agents. They need persistent rules that tell each agent what it is responsible for, which decisions it can make for itself, what must return to a human, how evidence moves between roles and what has to be true before shared work is considered finished.

That is what I mean by bounded autonomy.

Why running several useful agents created a new management problem

When I first started using software agents for substantial engineering work, the interaction was relatively simple. I gave one agent a problem, it investigated the system, used tools, changed artefacts, ran tests and worked towards an outcome. I remained involved, but there was only one active line of work to keep in my head.

The experience changed when the agents became useful enough for me to run several at the same time.

The amount of engineering they could do increased, but so did the amount of coordination I had to carry myself. I had to remember what every agent was doing, decide which agent should take a new problem, stop two agents from working on the same thing, carry findings from one conversation into another and work out whether a change in one part of the system altered the assumptions behind work already under way elsewhere.

Completion created another problem. An individual agent could finish its local task while another agent still held a conflicting claim, a reviewed change had not yet been integrated, or the shared system had moved since the evidence was produced. I could not safely treat each local report of "done" as evidence that the wider piece of work was complete.

The agents were removing implementation work from me, but I was still managing the relationships between them.

OpenAI has described a similar pressure in its work on Symphony. Engineers could manage a small number of interactive Codex sessions, but context switching became painful as the number grew. Symphony moves task allocation into an orchestration layer connected to project-management state, while humans review results.[1]

Anthropic's multi-agent research system uses a lead agent that plans a research process and creates parallel subagents. Its account of the production system also describes coordination, evaluation and reliability as problems introduced by having multiple agents rather than problems solved merely by adding more capable models.[2]

Google Research reached a related conclusion in a controlled evaluation of 180 agent configurations. Multi-agent coordination helped on some parallelisable tasks and hurt on sequential ones. The architecture used to organise the agents was part of the performance result.[3]

Those systems are not the same as HART, and I am not claiming novelty for the idea of a supervisor or lead agent. The question I wanted to investigate was narrower.

Could one of the machines take over some of the work involved in managing the other machines, while the decisions that changed meaning, scope or consequence still came back to me?

How we changed Hart 1 so that coordination did not disappear into implementation

HART already had mechanisms for multiple agents to operate against the same engineering system. Earlier work had taught us that ownership had to be explicit, that evidence could become stale when shared state changed, and that an agent reporting its own task complete did not establish that the wider body of work was complete.

Those observations became the basis of two earlier Harten technical papers: Coordinating autonomous software agents under shared mutable state and Establishing completion in autonomous multi-agent systems.

The next problem was that I was still doing too much of the allocation myself.

I changed the role of the primary Hart.

Hart 1 would no longer normally receive a problem and then spend most of its attention implementing the solution itself. Its job became working with me to establish the work item, keeping track of the agreed boundaries, deciding which available Hart should carry the investigation or implementation, coordinating those pieces of work and establishing that the agreed outcome had actually been completed.

That did not make Hart 1 a substitute for me.

The important boundary was that Hart 1 could coordinate work inside an outcome we had agreed together. It could not decide that new evidence silently changed the outcome, move the work into another service because that looked convenient, or accept a broader risk on my behalf.

If the evidence changed one of those things, the decision came back to me.

Inside the agreed boundary, I did not need to decide which peer Hart should investigate the problem or which peer should implement the resulting change.

That management work could move into the machine system.

How the roles are separated so that finding a problem does not automatically give an agent permission to fix it

The current operating structure is easier to understand if the roles are described in terms of the decisions they are expected to make.

I remain the human principal. I decide the intended outcome and retain decisions that materially change scope, consequence, risk or authority.

Hart 1 works with me to define a bounded work item. Once we agree it, Hart 1 coordinates the work, delegates implementation and remains responsible for establishing completion.

Peer Harts receive bounded work and perform the engineering. They can make implementation decisions inside the agreed outcome without returning to me for every file, method or test.

Hart 3 has a deliberately different role. We call it the detective. It investigates unclear or disputed conditions, follows the available evidence and tests competing explanations. Finding the cause of a problem does not automatically give Hart 3 permission to implement whatever change follows from that finding.

Independent review is separate again. The Hart that produced a change is not the only process asked to determine whether that change should be accepted.

The public structure can be represented without exposing the internal control-plane mechanics:

Figure 1 — The HART role structure used in this case study. The coordinator can allocate work, the detective can investigate, peers can implement and an independent reviewer can challenge the result. The human remains responsible when the intended outcome or permitted consequence changes.

The separation is not intended to imitate a human organisation for appearances. It exists because combining some responsibilities creates practical failure modes.

If the agent investigating a problem automatically becomes the implementer, it can converge too quickly on the first explanation that gives it something to change. If the coordinating agent performs every implementation itself, coordination becomes secondary to its own work. If the agent that generated the change is also the only authority deciding whether the change is correct, generation and acceptance have collapsed into the same process. If every ambiguity returns to me, delegation has not reduced the management burden.

The useful question is therefore not which role sounds senior. It is which decisions should and should not belong to the same machine.

What happened when more than 500 Evidence files made a document reader slow

One of the clearest examples arose while we were working on an application that had already been analysed by Harten.

Its generated documentation included 16 main narrative documents and more than 500 supporting Evidence files. The user experience was poor. Opening the documentation appeared to involve dealing with the full Evidence collection even when the person using the system initially wanted to read one of the main documents.

I raised the problem with Hart 1.

At an earlier stage of the system, I might have opened one agent, described what I thought the problem was and asked it to fix the interface. That did not happen here.

Hart 1 sent the question to Hart 3 for investigation.

Hart 3 traced the request through the application and found that the obvious browser-level explanation was incomplete. The server was reading and verifying the full documentation publication before returning several of the responses needed by the interface.

That changed what a useful solution looked like.

An apparently reasonable fix would have been to change the browser so that it did not immediately render hundreds of Evidence entries. That might have made the interface cleaner, but the expensive work would still have happened before the browser received the response.

Hart 3 reported the finding.

Hart 1 then came back to me with a different question from the one I had originally raised.

Should Wayfinder return the main documentation promptly and retrieve individual Evidence files when someone actually needs them, while preserving the verification, citations, downloads and export behaviour that rely on the integrity of the publication?

That question changed the behaviour of the system.

I said yes.

Hart 1 then delegated the implementation to another Hart.

I did not tell that Hart which methods to change. I did not decide how it should represent the publication metadata. I did not choose the tests. Those were implementation decisions inside the boundary I had approved.

What remained with me was the decision about what the application was now allowed to do differently.

How the decision moved between machines without disappearing from human control

The sequence is useful because it shows what I do and do not mean when I say that one machine is directing other machines.

Figure 2 — The decision path used in the Evidence-loading case. Machine-to-machine coordination continues until the evidence changes a decision that belongs to the human principal.

This is different from a human approving every machine action.

I did not decide which source file Hart 3 should inspect next. I did not decide which Hart should receive the implementation. I did not approve every test or code edit.

The decision returned to me when the investigation changed what the system would do.

That is the practical boundary.

Why these relationships are written into doctrine rather than recreated in prompts

The example above would be much less interesting if it depended on me opening a conversation and writing, "You are the manager. These agents report to you. Please behave responsibly."

That relationship would exist only for as long as the model retained the instruction and interpreted it as I intended.

HART carries the important relationships in durable operating doctrine.

The exact implementation is internal, but the public design principle is straightforward. A Hart loads rules describing its role and the authority attached to that role.

Those rules say, in substance, that Hart 1 can delegate ordinary implementation work, but only after the work item has been agreed with me. Hart 1 cannot decide that my agreed scope silently includes something else. Hart 3 can investigate deeply without receiving implementation authority from the investigation. Peer Harts can make implementation decisions inside the bounded work they inherit. Independent review remains separate from the agent that produced the change. Routine execution that is already inside an agreed boundary should not repeatedly return to me for permission.

A new Hart instance can therefore enter the engineering system and recover those relationships without me reconstructing the organisation in conversation every time.

That matters as the number of agents grows. A model context window is useful working memory. It is a poor place to keep the permanent constitution of an engineering organisation.

What happened when the coordination system itself prevented legitimate work

The same morning produced a useful counterexample.

The machinery responsible for keeping track of active Hart sessions developed a lifecycle defect. Historical sessions had not all been transitioned out of their active state correctly.

The immediate symptom looked small. We initially identified four historical sessions that appeared to remain active.

A wider inspection found 57 unresolved historical sessions across earlier dates.

A newer safety check was correctly looking backwards and refusing to create a conflicting active primary session. The result was that the mechanism intended to protect the integrity of the agent organisation was now preventing legitimate new work from starting.

This matters because as soon as software agents acquire durable identities, roles, work ownership and lifecycle state, their organisational machinery becomes another software system.

That system can contain defects. It can retain stale state. It can block legitimate work. It needs recovery paths, validation and review.

The control plane cannot be treated as background scaffolding simply because its purpose is to coordinate autonomous work. It has to be engineered with the same care as the applications the agents are changing.

Figure 3 — Session-control failure and recovery. The coordination layer failed, the wider audit exposed 57 unresolved sessions, and the authorised recovery route restored normal session acquisition.

Why the first recovery stopped even though the model was capable of writing the missing mechanism

The lock failure exposed another distinction that I think is important.

An earlier Hart correctly established that the supported recovery operation required to resolve the abandoned sessions did not exist.

It reported the gap and stopped.

At first, that can look like a limitation in the agent.

It was not a lack of coding ability.

A later Hart was able to implement the missing recovery mechanism. The family of models was capable of doing the engineering.

The difference was that the earlier Hart's operating rules did not give it a clear route from "the recovery command I need does not exist" to "the operator has already authorised this bounded recovery, so building the missing mechanism required to perform it is part of completing that authorised work."

The machine could write the software.

The engineering organisation had not yet made that responsibility explicit.

How changing the doctrine changed what future Harts are expected to do

We could have solved the incident locally by telling the blocked Hart to ignore the normal rules and fix the problem this one time.

That would have restored progress without improving the organisation.

Instead, I changed the doctrine.

The primary Hart now has an explicit responsibility for carrying an operator-authorised bootstrap repair through to verified completion. That does not mean Hart 1 writes every recovery itself. Hart 1 still coordinates. Another Hart can implement the missing mechanism. The change still has to be validated and independently reviewed. The actual recovery still has to remain within the exact authority I granted.

What changed is that discovering a missing mechanical route inside an already authorised repair is no longer automatically treated as the end of the work.

The organisation is expected to solve the missing mechanism safely and continue.

That new rule survives the conversation in which I made the decision. Future Harts inherit it when they load the doctrine.

Nothing about the model weights changed during this event. The organisation became more capable because the rules governing how the machines could use their existing capabilities changed.

Why a machine being able to make a change is not enough reason for it to make the decision

The distinction becomes concrete when you look at the individual cases.

Hart 3 was technically capable of editing the Wayfinder code after discovering the Evidence-loading problem. Its role did not give it permission to turn that diagnosis into an implementation.

The implementation Hart was technically capable of changing adjacent services if doing so looked convenient. The agreed work item did not give it that scope.

Hart 1 was capable of sending work to several peers. It could not decide on my behalf that a changed product behaviour was acceptable.

The Hart examining the session-lock problem was capable of writing software. Its current operating rules did not yet establish that creating a missing recovery path belonged inside the repair it had been authorised to complete.

In each case, technical capability was only part of the engineering question.

The other part was whether this particular machine, in this particular role, had been given responsibility for this particular decision.

What I still decide, and what I no longer need to decide

This changes what human oversight looks like in practice.

The phrase "human in the loop" is too vague unless we say which loop and which decision.

During this work I made decisions such as whether "remove the application" meant removing a registration or deleting the underlying source repository. I decided whether the Evidence investigation justified changing how documentation was loaded, and which trust properties had to remain. When four stale sessions turned out to be 57, I explicitly authorised the expanded recovery rather than allowing the system to infer permission. When the first recovery exposed a gap in Hart's responsibility, I changed the doctrine governing future repairs.

I did not decide which Hart should trace the documentation-loading problem. I did not decide which Hart should implement the agreed fix. I did not decide which source files that Hart should change, how the fix should be structured internally or which test should be written first.

Those decisions happened elsewhere in the system.

The human can therefore remain responsible for purpose and consequence without becoming the scheduler for every machine action.

That is the form of human control I am trying to preserve.

Why this is more than adding a supervisor agent

There are already several established ways of organising multi-agent systems.

A group of workers can operate independently and have their results combined later. A lead agent can divide a problem and create subagents. A central orchestrator can allocate tasks from a project-management system. Those are useful patterns, and HART does not invalidate them.

The additional question we are exploring is what happens when the coordinating machine is itself operating inside persistent rules that restrict what it may decide.

Hart 1 is not simply the most capable model in the group. It has a role that carries some authority and withholds other authority.

The detective has a different role. The implementer has another. The independent reviewer has another. I remain outside those machine roles as the human principal.

Anthropic's more recent work on emerging multi-agent systems points to the broader problem. Agent-to-agent interactions are likely to grow quickly, while many existing institutions assume oversight can happen at human speed. Anthropic distinguishes relatively structured interactions, where one agent can treat another almost like a tool, from harder settings involving longer-lived participants and less obvious hierarchy.[4]

That is close to the systems question HART is exposing for software engineering. The challenge is not simply to make another model responsible for the others. It is to define which decisions that responsibility includes and where it ends.

Why more agents and faster output are not enough to judge the engineering system

A lot of AI engineering is still discussed through capability and throughput.

How much code can the model produce? How many agents can run in parallel? How long can they work? How large is their context? How many tools can they call?

Those measurements matter.

They do not tell us whether the resulting engineering organisation is coherent.

A system can run twenty agents and still leave the human manually coordinating all twenty. Agents can generate large amounts of code while silently widening the intended scope. Several machines can agree with one another and still share the same wrong assumption. An agent can report success while another agent still holds conflicting authority over the same state.

The agent that made the change can also produce a convincing explanation that the change is correct. That explanation is not independent evidence.

Google's results are relevant here because they show that adding agents can improve or degrade performance depending on the task and coordination architecture.[3] The number of agents is not itself a reliability measure.

The engineering questions become more demanding as the models improve.

Who can delegate? What happens when new evidence changes the meaning of the task? Can a diagnosis alter implementation authority? Who checks the resulting change? What happens when two agents believe they own the same state? How does the organisation recover when the control mechanism itself is wrong?

Those questions are part of the system, not administrative detail surrounding it.

What bounded autonomy means in this observed system

I use the term bounded autonomy to describe a practical operating behaviour rather than a general promise about safe AI.

A peer Hart can make many implementation decisions without asking me about each one.

Hart 3 can investigate deeply without asking me which source file it should inspect next.

Hart 1 can allocate work to other Harts without asking me to choose the worker.

Those are meaningful forms of autonomy.

The autonomy also has an edge.

When new evidence changes what the application should do, that decision can cross the edge and return to me. When a task would move into a component we deliberately excluded, the existing authority ends. When a recovery grows from four historical sessions to 57, the original decision is not silently stretched to cover the larger consequence.

The system therefore gives machines room to act without giving them unlimited discretion.

The difficult engineering work is designing those boundaries well enough that the human is not dragged back into every routine decision while the machines still recognise when they have reached a decision that is not theirs to make.

That is the balance I mean by bounded autonomy.

How this extends the earlier Harten technical papers

This paper is the next part of a developing technical argument rather than a separate claim about agentic software.

Coordinating autonomous software agents under shared mutable state examined what happens when independently reasoning agents work against the same changing engineering system. That work focused on ownership, conflicting mutations and the fact that evidence produced against one system state cannot simply be assumed to remain valid after that state changes.

Establishing completion in autonomous multi-agent systems examined another consequence. One agent saying it has finished does not establish that shared work is complete. The system needs evidence about the wider state.

The current paper starts from those two problems.

Suppose the machines can already work concurrently.

Suppose the system can establish whether shared work has actually finished.

The next question is who manages the work between those points.

In the observed HART environment, some of that management work is now performed by another machine. Hart 1 can decide which Hart should investigate, receive the investigation, determine whether the existing scope still applies, delegate the agreed implementation, coordinate several peers and remain responsible for establishing completion.

But when the evidence changes a decision that belongs to me, it returns that decision.

That is the additional observation this paper contributes.

The next step is to make the organisation persist beyond individual Hart sessions

The larger change is not simply that one agent can hand work to another.

I no longer need to act as the dispatcher for every piece of engineering work. I still establish the intended outcome, the consequential boundaries and the standards by which the result should be judged. Hart 1 can then decide how bounded work should be divided, which Hart should investigate or implement it, when evidence changes the decision and whether the agreed outcome has actually been completed.

That moves some of the management of the engineering system into the engineering system itself.

There are important adjacent examples. OpenAI's Symphony turns project-management state into a control plane for coding agents and keeps workflow policy in the repository. Anthropic's research system uses a lead agent to coordinate specialist subagents and describes external memory and persistent artefacts as mechanisms for carrying work beyond one context window. OpenAI's Agents SDK provides guardrails and human approval points around sensitive actions.[1][2][5]

I would not treat those systems as evidence that HART is unique because it uses agents to coordinate other agents. That pattern is clearly emerging elsewhere.

The difference that matters for the work described here is the organisation we are trying to preserve around the models.

Hart 1 does not inherit my authority because it coordinates the other Harts. Hart 3 can investigate without automatically acquiring implementation authority. A peer can implement without becoming the reviewer of its own change. Shared work has explicit ownership. Completion is not established by one agent declaring its local task finished. The operating doctrine can change when a failure exposes a missing responsibility, and later Harts inherit that change.

Those relationships can survive the individual model session.

What does not yet survive as cleanly is the working intelligence accumulated while the organisation is operating.

Each Hart still has working memory that is local to that machine or session. The doctrine can restore role, authority and operating rules, but the detailed understanding accumulated across several Harts still has to be recovered from evidence, artefacts and handoffs. A new Hart does not yet enter the system with the relevant distributed working state of the organisation already available to it.

That is the next architectural step for Wayfinder.

The direction is to integrate Wayfinder with Harten-Nano GPT and move towards a distributed machine model in which model capability, memory, evidence, judgement and persistence are not tied to one Hart process or one local machine.

A new Hart should be able to enter the organisation, recover the relevant responsibilities and live state, see what other Harts have already established, distinguish accepted evidence from unresolved questions and continue the work without me reconstructing the organisation around it.

At that point, the persistent unit is no longer the individual agent session. It is the governed engineering organisation that the agents participate in.

Conclusion

This work has moved beyond showing that several agents can run at the same time.

In the system described here, one machine can direct work performed by other machines. Hart 1 can decide how bounded work should be divided and delegated. Hart 3 can investigate without automatically becoming the implementer. Peer Harts can make technical decisions inside the scope they inherit. Independent review remains separate from implementation. Hart 1 remains responsible for establishing whether the agreed work is actually complete.

That arrangement is working now.

The important change for me is not that I disappear from the engineering system. It is that I no longer need to dispatch every task or manage every relationship between the Harts myself.

My role moves up a level.

I establish what the organisation is trying to achieve, which decisions remain mine, where authority stops, and what standard of evidence is required before the system can treat work as complete. The Harts can then organise a growing amount of the engineering work below those boundaries.

That is a more significant change than agent orchestration on its own.

The enduring thing is beginning to become the engineering organisation rather than the individual model session. The roles, authority boundaries, separation of responsibilities and completion rules are carried in durable doctrine. When a failure exposes a missing responsibility, that doctrine can change and later Harts can inherit the correction without silently inheriting more authority from me.

The remaining architectural limitation is much more specific.

Working memory is still local to individual Hart machines and sessions.

A new Hart can recover its role and authority from doctrine, and it can reconstruct state from evidence and artefacts, but it does not yet naturally inherit the accumulated working intelligence of the organisation. What another Hart has established, which evidence has already been accepted, which questions remain unresolved and what changed during the work still has to be recovered across local contexts.

That is now the next stage of Wayfinder.

Wayfinder will integrate with Harten-Nano GPT and move towards a distributed machine model in which model capability, memory, evidence, judgement and persistence are shared across the organisation rather than tied to one Hart process or one machine.

A Hart joining the system should be able to recover the relevant live state, understand what other Harts have already established, distinguish evidence from unresolved questions and continue the work without me rebuilding the organisational context around it.

The larger engineering problem is therefore no longer whether machines can direct other machines under human control. We have observed that working.

It is whether that machine organisation can preserve its identity, decision rights, accumulated understanding and accountability as individual models, machines and sessions come and go.

That is the next problem Harten-Nano and Wayfinder are intended to address.

---

References

[1] OpenAI, "An open-source spec for Codex orchestration: Symphony", 27 April 2026. https://openai.com/index/open-source-codex-orchestration-symphony/

[2] Anthropic, "How we built our multi-agent research system", 13 June 2025. https://www.anthropic.com/engineering/multi-agent-research-system

[3] Google Research, "Towards a science of scaling agent systems: When and why agent systems work", 28 January 2026. https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/

[4] Anthropic, "Patterns and problems in emerging multiagent systems", 13 August 2026. https://www.anthropic.com/research/multiagent-systems

[5] OpenAI, "Guardrails and human review", Agents SDK documentation. https://developers.openai.com/api/docs/guides/agents/guardrails-approvals

This is an empirical working paper from Harten. It reports observed behaviour from a governed multi-agent engineering environment and extracts provisional design principles from that case study.