Start with the surprisingly simple ZIP method
The easiest way to run several AI coding agents at once is often not to connect them at all. Give each assistant a complete ZIP copy of the project in its own chat or coding workspace. Let it unpack the project, inspect the repository, run the tests, and take possession of that copy on its own turf.
This works because each worker receives a self-contained world. One assistant can investigate a failing test while another reviews the architecture and a third builds a narrow feature. They do not overwrite one another's files, fight over a shared terminal, or depend on a fragile message bus. The human operator decides which result is accepted and moves only the approved work back into the real repository.
The ZIP should contain the whole working project, not a random handful of files, unless the task is genuinely isolated. A complete copy lets the assistant follow imports, inspect tests, understand configuration, and discover the assumptions that live outside the file named in the prompt. The same principle appears in Notavello's guide to preparing files for a useful AI-assisted review: good results begin with a clean scope and enough surrounding context.
Use director, supervisor, and worker as roles, not job titles
A useful multi-agent structure has three roles, but they do not require three layers of software.
- The director owns the product goal, architecture, security boundaries, and final acceptance decision. For an individual developer, this is usually the human.
- The supervisor turns a large goal into bounded assignments, checks worker reports, compares diffs, and decides whether a task is ready for integration. A strong AI assistant can help here, but it should not silently approve its own work.
- The workers perform narrow jobs inside separate ZIP copies, Git branches, worktrees, containers, or remote sandboxes.
The important part is authority. Workers may propose changes, but they should not redefine the project. A supervisor may reject incomplete work, but it should not merge around a failing test. The director remains the only role allowed to change the mission or accept a risky compromise.
Each worker assignment should state the objective, allowed files, forbidden areas, test commands, success criteria, and required completion report. “Improve the app” is not an assignment. “Repair the URL parser without changing navigation behavior; run these four tests; return the changed files, test output, and remaining risks” is.
Parallel work only helps when the tasks are truly separate
Multiple agents are useful for independent work: one can research a bug, one can write tests, and one can review documentation. They are much less useful when all three must edit the same central file. That creates three plausible but incompatible versions and leaves the human with an expensive merge puzzle.
Before starting workers, divide the work by boundary rather than by vague topic. Good boundaries include a module, platform, test suite, migration step, or read-only forensic review. When changes must touch the same code, run them sequentially or assign one worker to implement and another to review the finished diff.
Git branches and worktrees are better than ZIP files when the assistants can operate directly on the same machine and the operator is comfortable with Git. ZIP copies are better when the agents live in separate browser chats, different services, or machines that cannot safely share a repository. Both methods solve the same problem: no two workers should be casually editing the same live working tree.
Plan for the moment an agent stops cold
Long AI coding sessions can end for reasons unrelated to the code. A service may reach a usage allowance, a tool session may expire, the context may become unwieldy, or a browser workspace may simply stop responding. Claude is a common example: Anthropic explains that usage limits determine how long a person can work with Claude or Claude Code before waiting for a reset, and on Pro and Max plans the two products draw from shared usage limits.
To the user, the result can feel like a worker walking off the job without warning. The repair is not a clever prompt. It is a restart package. Every substantial task should maintain a small handoff containing:
- the exact project and branch or ZIP version;
- what was completed and what remains;
- files changed and files intentionally untouched;
- commands already run and their results;
- the next safe command or action;
- known risks, assumptions, and unresolved questions.
A replacement session can then resume from evidence instead of reconstructing hours of conversation. This is also why a context window is not the same as permanent project memory; Notavello's explanation of what an AI context window actually changes is a useful companion to this workflow.
What OpenHands is trying to provide
OpenHands is an open platform for coding agents. Its current documentation describes a browser-based interface and backend for running agents and automations, along with terminal, cloud, and local options. Its sandbox architecture gives an agent an environment where it can edit files and execute commands rather than merely suggesting code in a chat window.
That is the attraction. Instead of manually uploading a ZIP, copying commands, collecting results, and keeping several chats organized, OpenHands aims to provide the machinery around the agent: workspace creation, command execution, model configuration, sandboxing, and a persistent interface. For repeated or team-scale work, those capabilities can become valuable.
Its Docker sandbox is the recommended local provider, and the runtime is designed to isolate command execution from the host. That is a meaningful capability, not decoration. An agent that can run arbitrary project commands needs a boundary, and a real sandbox is safer than pointing an autonomous tool at a person's ordinary home directory. Notavello's AI sandbox security checklist explains why the boundary deserves attention.
The setup can become the project
The uncomfortable part is that a platform powerful enough to manage autonomous coding work has many more failure points than a ZIP upload. A recent hands-on attempt to self-host OpenHands turned into a long tour through Docker, Linux, container processes, permissions, networking, model credentials, repository mounting, and sandbox startup behavior. At several points, the work was no longer about the application being developed. It was about persuading the agent infrastructure to stay alive.
The official setup instructions themselves show why local installation has more moving pieces: Docker must be installed and running; Windows users may be routed through the Windows Subsystem for Linux; Docker socket access may need to be enabled; images must be downloaded; and model or API configuration still has to be correct. OpenHands now offers quicker cloud and packaged paths, so the experience will vary, but self-hosting remains a materially larger undertaking than opening three chats and giving each one a ZIP.
This does not make OpenHands bad. It means the platform should solve a problem large enough to justify owning the platform. An individual developer who needs two independent reviews this afternoon may lose more time configuring orchestration than the parallel agents could save. A team that runs dozens of repeatable coding jobs may reach the opposite conclusion.
A one-person workflow that survives reality
A practical system can be run with ordinary AI chats, ZIP files, and Git:
- Freeze a known starting point. Commit the repository or create a clearly dated ZIP.
- Write the director brief. Define the goal, constraints, acceptance tests, and decisions workers may not make.
- Split only independent tasks. Avoid sending several workers into the same core files.
- Give each worker a complete copy. Use a separate chat, branch, worktree, or sandbox.
- Require evidence. Ask for diffs, test output, changed-file lists, and a concise handoff.
- Review before combining. The supervisor checks claims against the actual files and reruns tests.
- Integrate one result at a time. Commit each accepted unit separately so it can be reverted.
- Prepare for interruption. Save the handoff before usage limits, context pressure, or a broken session forces a restart.
Only after this manual system becomes repetitive should the operator consider a heavier orchestrator. By then, the real requirements will be visible: which tasks recur, which permissions are needed, where isolation matters, and which reports are actually useful.
The best multi-agent system is the lightest one that fails safely
Running several AI coding agents at once can accelerate work, but parallelism is not the same as progress. The dependable pattern is mundane: complete project copies, narrow assignments, separate workspaces, test evidence, explicit handoffs, and one human who owns the merge.
OpenHands and similar platforms can automate more of that loop, especially when the volume of work justifies durable infrastructure. But for many individual developers, the breakthrough is much simpler: hand each agent a full ZIP, let it work independently, and never confuse an impressive agent conversation with an approved change to the real project.