In Making agents work like an engineering team, I described a software-development workflow with agents in separate roles. An implementer picks up a story, reviewers request changes or approve it, and a merge coordinator checks the required evidence before merging. A QA agent tests the product and files defects back into the queue.
The aim is for that loop to keep moving without me directing every step. I still define the work and check that what gets built matches the specification. Operating the workflow also means investigating why an agent stopped and deciding when it is safe to let it continue.
The flow is distributed, with separate agent roles coordinating through shared work records rather than one central orchestrator directing each handoff. The earlier article described that workflow. This is about operating it.
Giving the agents separate environments
I tried running multiple agents on a single machine. It did not work very well. Agents needed access to system resources, and coordinating that access through locks and leasing rules became a recurring difficulty.
I now use virtual machines with one agent identity per VM. Each identity has access to its resources and uses the stack as needed. That separates the identities, but it does not prevent two scheduled invocations of the same agent from overlapping. One run can still be working when the next start time arrives.
Run locks protect particular operations from overlap; they are not required for every role. Environment leases govern stack use separately, and story claims retain work ownership until verified closeout.
Those controls have to remain distinct. Moving an agent into a VM does not establish that its previous invocation has finished or that its resources are safe to reuse.
When a run stops before the work is finished
Occasionally an agent terminates for a reason I cannot immediately establish. A system shutdown is one possibility. In the cases I encounter, the agent then waits for my instruction before recovering the lock.
There is a recovery procedure. The agent can execute an audited helper after the required authorization. The difficult part is establishing that the previous invocation cannot resume and that any child work capable of changing the system has stopped. An absent process or a quiet chat does not prove both.
The documented automatic recovery path requires trusted evidence of that state. Without it, human authorization is required before the agent performs recovery. A lock should not be cleared simply because it looks old.
That safety decision can still require my intervention before work continues.
A blocked report needs investigating too
Other interruptions arrive as an explanation from the agent. Sometimes a scheduled run says it cannot access source control because credentials are unavailable, even though the credential files are present.
That discrepancy needs investigation. File presence does not prove that authentication works or that the credentials permit the required operation. Equally, the agent's report is not enough to establish why access failed.
When I notice this, I investigate the cause, review the skill instructions, and adjust them when needed. The existing procedure already requires checking the relevant operation, recording sanitized failure evidence, and attempting permitted recovery within bounded retries.
I have also seen different behavior from the same instructions. Context and environment changes may contribute; this is not a controlled comparison of model behavior. Written instructions alone have not removed the need to inspect actual runs.
A useful blocked report should tell me:
- Which operation failed, with what evidence?
- Which permitted recovery was attempted?
- What remains owned or running?
- What exact decision or authorization is needed?
Scheduling is another part of the design to improve
The agents currently wake on scheduled jobs. Event-based triggers could improve the handoffs: opening a pull request could wake a reviewer, for example, instead of waiting for its next scheduled run. That is a possible improvement, not something the current flow already does.
A single orchestrator could manage which agent runs next. Our flow distributes that coordination across the roles and shared work records. Central coordination and event-based wake-ups are separate choices; a distributed workflow can also react to events.
Events would introduce their own delivery and retry concerns. A wake-up would still need to respect ownership and check whether another invocation is active. It would not establish that an interrupted run is safe to recover.
The development loop still gives the agents defined work and independent checks. My involvement continues around it: monitoring progress, investigating unsupported explanations, authorizing safe recovery, and checking the result against the specification. There is room to improve how agents get called into that loop without treating those improvements as a substitute for supervision.