HAR – open-source harness for multi-agent coding workflows

HAR is an open-source project from the os-factory organization on GitHub that presents itself as a harness for multi-agent coding workflows. The project surface is the repository at github.com/os-factory/har. On Hacker News under the AI Agents lane it had drawn 2 points and 0 comments at the time of this note, so the public signal is still early and thin relative to the claim in the title.

As a harness rather than a single model or chat UI, HAR sits in the layer that coordinates how multiple coding agents are started, scoped, handed context, and joined into one workflow. That is the operational shell around agents: task routing, session boundaries, tool access, and how outputs from one agent become inputs for another. Exact internals are defined in the repository itself; the product category is orchestration and control of multi-agent coding runs, not a new foundation model.

For engineers and builders already running more than one agent on a codebase, the hard problems are usually process, not prompts: who owns which files, how failures are isolated, how review gates sit between autonomous steps, and how a workflow stays reproducible across machines. An open-source harness is useful only if it makes those control-plane choices explicit and inspectable. HAR is relevant to teams that treat multi-agent coding as a pipeline with defined stages instead of a loose set of concurrent chat sessions.

Competitively, multi-agent coding tooling is crowded: vendor agent products, IDE-integrated copilots, and ad hoc scripts that chain CLI agents all claim parts of the same job. A dedicated open-source harness competes on transparency, self-hostability, and the ability to plug in different models or agent backends without locking the workflow to one vendor. With only 2 HN points and no discussion thread yet, HAR is still at the discovery stage next to better-known agent frameworks and commercial coding agents; traction will show up in adoption of the repo and whether people run real workflows on it, not in headline score alone.

Practical next step is to treat the GitHub repository as the source of truth: clone or browse os-factory/har, map how it defines agents, tasks, and handoffs, and test it against one constrained multi-step coding job (for example plan → implement → review) before wiring it into production pipelines. Watch for whether the project documents stable interfaces for agent plugins, failure recovery, and audit logs of agent actions—those three decide whether a harness is experiment-only or fit for team use. On the public side, the HN thread at item 49210031 is still empty; any real usage signal will appear first in the repo’s issues, stars, and downstream forks rather than in early link votes.