Pick one team and one repository
Start where parallel work already hurts: a repo with a queue of small tickets and a test suite you trust. Harbor chose the billing web app.
For teams
How a team adopts Eizen, from the first install to the daily merge
One person sets it up on one machine and everyone else imports a file.
The example
Harbor, a freight billing company
Harbor is invented for this page: nine engineers, a web app, an API and a lot of overdue invoices. The steps are what the app really does, and the screens come from a demo workspace set up this way.
Start to finish
Ten steps from install to routine
Install on one machine
Run the setup file. A checklist installs Claude Code, signs you in and checks Git, with no terminal involved. Codex, OpenCode and GitHub sign-in are optional.
Add the accounts you pay for
Add each Claude plan under Settings. Choose a default for new threads, or let new threads go to whichever account has the most room. Each engineer can do this with their own plan.
Add the repositories
Add each repository as a project. Lanes need the project folder to be the top of a git repository, so a folder holding several checkouts works better as one project per checkout.
Set the limits
Decide how much the agent may do unattended.
- Permission mode. Start on Ask before edits.
- Safety net. Turn on Ask before risky commands in every mode.
- Protected files. For example .env*, migrations/** and infra/**.
- Project checks. pnpm typecheck && pnpm test, with three tries.
Connect the tools
Add the tracker, GitHub and the database. Give database connections to the accounts that need them and to nobody else. Harbor uses a Neon branch per lane for anything that writes.
Spend a week on lanes
Run two lanes at once on real tickets, then three. Commit in the lane and merge from the breadcrumb. This is where a team finds out which services are still shared between lanes.
Share the setup
Export settings from the lead's machine. The file holds preferences, projects, their checks and schedules. Teammates import it and add their own accounts and tokens, which the file never contains.
Settle into a daily rhythm
Read what ran overnight, start lanes from the day's tickets, merge what passes the checks and queue the slow jobs for tonight. Non-engineers comment through review links.
Check what it costs
Usage shows tokens per day and per model, with cost at API prices. The Tasks panel shows which sub agents used what, which tells you where a smaller model would do.
Sharing the setup
One file, and each person keeps their own keys
The lead exports settings once. Everyone imports the same preferences, projects, checks and schedules, then signs in with their own accounts.
eizen-settings-2026-11-10.jsonPreferences, projects, checks, schedules
Priya imported itAdds their own accounts and tokens
Tomasz imported itAdds their own accounts and tokens
Maya imported itAdds their own accounts and tokens
Tokens never leave the machine they were entered on
Who does what
What each person touches
| Role | Sets up | Uses day to day |
|---|---|---|
| Tech lead | Projects, checks, protected files, the shared settings file | Reviews merges, reads the Night shift summary |
| Engineer | Their own accounts and tokens | Lanes, the browser, Ask this line |
| Designer | Nothing, or their own install | Right-click to change, compare with a design |
| Product manager | Nothing | Comments through review links, meeting summaries |
| Client | Nothing | A review link that expires |
A normal week
Mornings start with what ran overnight
Harbor queues the slow jobs at the end of the day: test backfills, dependency work and small refactors. By morning there is a list of what finished, what needs a decision and what was left waiting.
A week at Harbor
Where the time goes
| Day | Morning | Afternoon | Evening |
|---|---|---|---|
| Monday | Planning meeting, recorded and transcribed | Three lanes from the action items | Queue test backfill |
| Tuesday | Merge what passed overnight | Try 3 ways on the export redesign | Queue date library upgrade |
| Wednesday | Review link goes to the client | Comments become messages to the agent | Nothing queued |
| Thursday | Ask this line on a confusing retry | Fix it in a lane, with the original reason in view | Queue flaky test fixes |
| Friday | Check usage by model | Move routine work to a smaller model | Close the week's lanes |
How it helps
What changes compared with what you run today
Parallel work stops colliding
Every thread has its own folder and branch, so reviewing one change no longer means untangling three.
Review happens against a running app
The agent checks the page itself, and you pick elements and record bugs in the same window.
You can still find out why
Six months on, a line still points at the conversation that produced it.
Spare plan capacity gets used
Night shift runs in hours that would otherwise go unused.
Rules carry over
A rule said once ends up in the project file for every later thread.
You keep your CLIs
Claude Code, Codex and OpenCode keep working in a terminal, with the same sessions.
Limits
What Eizen doesn’t do for a team yet
If any of these is a requirement today, plan around it before you start.
- No admin console. Settings are shared by file, and nothing enforces them.
- No single sign-on. People use their own provider accounts.
- No shared threads. A thread belongs to one computer.
- No central audit log. Remote activity is listed per machine.
- Windows first. Windows 10 and 11 are what we build and test.
- Needs the PC on. Everything runs on it.
Start with one team and one repository
The setup checklist handles Claude Code, sign-in and Git, so you won't need a terminal.
