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.
PH 用户
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?
PH 用户
Super interesting concept, not an obvious solution to that problem. Will need to give it a bash!
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.