HAR is an open-source, agent-agnostic framework for building multi-agent coding workflows. Run a fleet of coding agents in parallel on any repository, with deterministic validation gates, verifiable proof, and full observability across every agent, all extensible and customizable to your own workflow and tooling.
FetchSandbox
the single in-repo contract replacing scattered CLAUDE.md / README / editor rules / CI config is a genuinely sharp design call. config drift across those files is what makes multi-agent setups brittle, every agent reading a slightly stale version of the truth. curious how opinionated the contract schema is on init: does `har init` scaffold a full contract template, or does it leave most of the structure to the team to define?
Kerno
@rnagulapalle Yea har init` scaffold a full contract template, but you can customize each stage to your own workflow everything is configurable and extensible
HAR
@rnagulapalle Thanks for the feedback, we made sure that the contract is as little opinionated as possible, what we offer on har init, is a template per type of repository contract (web, cli, mobile, ect.). So for example on a web app, we will provide in the template an example of how to start a full web application stack (backend, frontend, postgres, redis, minio, ect..), we found that providing this kind of example allow the coding agent to correctly adapt by searching for this type of information in the targeted repository, because it's able to do a matching more easily.
And as @karim_traiaia said, the template is fully customizable, and similar to shadcn (if you know) we create the file in your repository so you own it, and you customized it has you want. The teams own and know how to start the app, so you can even guide a bit your coding agent to adapt it, as I'm trying to do in the demo video here:
https://youtu.be/XKl4ZzWy7mQ?si=fVofvkBUT583kI7T
On the drift part we have only `har env maintain`, it checks the drift with the initial har template configuration. The next step will probably to have a har doctor command to prompt your coding agent to seek for any recent changes of the architecture (or any other type of structural changes) in your codebase that could break the environment startup flow. We know those changes are a bit rarer so we focus on core feature right now.
Cheers
HAR
Hey PH!
I’m Antoine, and over the past year, as I tried to scale our agentic coding workflows and software factories at my company, I kept hitting the same set of problems. So I built HAR to solve them, and I'm open sourcing it today.
Getting a single coding agent to work in a repo is easy. Scaling to a real multi-agent workflow, where several runs at once and you still trust the output, is where it breaks down. A few things go wrong at the same time:
No standard way to run or verify a repo. That knowledge is scattered across a README, a CLAUDE.md, editor rules, and CI config, all drifting out of sync with each other and the actual code.
Agents on one repo collide. Shared dev server, shared database, shared ports, conflicting git state.
Trusting a change means re-verifying it yourself. Which defeats the point of running a fleet.
Vendor sandboxes lock you in. If the setup lives in someone's hosted dashboard, switching agents later means rebuilding the whole thing.
What HAR does
HAR is a CLI and an MCP server. It works with Claude Code, Cursor, Codex, or any MCP agent, and it closes each of those gaps:
Isolation. Each agent gets its own git worktree, branch, ports, and database. Nothing is shared with the main checkout or another agent's slot, so a fleet runs in parallel without colliding on a dev server, DB, or ports.
Deterministic validation gates. HAR runs your project's real checks through a fixed pipeline, same result every time. The result is bound to the exact code that passed and enforced at commit time, so an unverified tree cannot land.
Verifiable proof. Every run leaves logs, artifacts, and a validated tree hash tied to the exact code checked. A reviewer inspects the evidence instead of trusting the agent's self-report.
Full observability. Mission Control is a local dashboard showing every repo, worktree, run, and validation in one place, so you can watch a whole fleet as it works.
All of this lives in one contract committed to your repo, which every agent reads the same way. It replaces the usual scatter of a README, a CLAUDE.md, editor rules, and CI config that drift apart. You start from a profile that matches your stack, your agent adapts it to the real repo, and you extend verification with plugins (like Playwright) or with any command you already run.
Give it a try and let me know what you think :)
I'd genuinely love feedback, especially from anyone already trying to run multiple agents in parallel.
Zerve AI
Super interesting concept, not an obvious solution to that problem. Will need to give it a bash!
Kerno
@phily_hayes thank you Phily! Looking forward to getting your feedback :D