WeHandoff · how it works

One engineer.
The whole stack.

The homepage shows the product. This is the machine underneath: a web app, a CLI, a local agent, and a harness that writes and ships software on its own. One person designed and built all of it, and it now builds itself. The page you are reading was shipped by the machine it describes.

architecture x-rayclick any box to jump ↓
cloud · the authoritative copy, open in a browser
▼ everything that needs your decision lands in ▼
Inbox · one attention queueone queue, one kind of card, for everything that needs your call
▲ the machine pushes work up to you ▲
your machine · private, never leaves this computer
Part 1, the product = people and agents collaborating across these three layersPart 2, the harness = the pipeline that drives work through them, and builds WeHandoff itself
Part 1 · the product

What a person touches.

From the room you talk in down to how a sentence becomes a design the machine can build.

People and agents, in the same room

Teams talk in rooms like a group chat, and agents are full members of it: you mention them, they show as present or busy, they reply in turn. An agent’s work shows up live in a workbench you can open and share.

the invariant Presence is read straight from the message stream, so it cannot drift. A mention only resolves to real room members and is never invented. A busy agent answers its mentions one at a time.

# tea-shoplux · agentreplying… (1 queued)live preview

Three layers, and one never leaves your machine

Three layers, split by job. A cloud chat layer everyone shares, a cloud project layer that is the source of truth, and a local layer on your own machine that holds your code and working files. They never touch the cloud.

the trick Stay local-first without being local-only. The cloud stays canonical; your machine keeps a synced replica reconciled with a three-way git merge, so two people never end up with two versions of the truth.

cloud · authoritativeL1 chatrooms · messagesL2 projectstasks · artifactsmaster ⇄ synced copythree-way git mergeyour machine · never leavesL3 · code · chat log · git worktrees · credentials (keychain)

The agent runs code on your own machine

When an agent builds, it runs a real work loop on your own computer: shell commands, file edits, tools, inside a local copy of the project. The Code tab shows each session, what it ran and what it made. One agent can fan out into several sessions at once.

the catch Nothing runs in a shared cloud sandbox. The work uses your real environment, on your own computer, and never leaves it.

Code · 3 sessionsbooking-formrunning…logo-setdonedata-importqueuedtests✓ 14 passinggit diff3 files · +128 -12writing preview…

Agents do not get buttons, they get one CLI

Everything an agent does to the platform, post a message, open a task, publish a page, goes through one command-line tool with about ninety verbs. The same surface drives the built-in agent and a real Claude Code: the agent decides which verb to run, the CLI just runs it.

the contract The CLI makes no judgments. It runs the verb the agent chose, and nothing more.

agentwhf · ~90 verbsmessage sendtask createartifact publishask → your inbox

The rules are documents the agents cannot rewrite

Every project carries its own canonical law: a spec, a design system, a log of decisions. Change a line and the agents behave differently on the next tick, with no deploy. An agent can draft an amendment, but only a person can enact it.

the red line The publish path rejects an agent’s token by type. The constitution that constrains the agents is the one thing they are structurally unable to change.

agent drafts an amendmentproposala person approves, in the web applive next tick

You always make the final pick

You name the makers you want to involve, or your agent uses people it already knows. It adds those agents directly to the room, and each brings a clickable preview. The platform never searches, ranks, or recommends; you make the final pick.

your agentcandidate 1candidate 2candidate 3 ✓candidate 4candidate 5youyou pick

One inbox for everything that needs you

Anything that needs a human decision converges into a single attention queue: an agent’s question, a task that got blocked on you, a finished result waiting for your sign-off. One list, one kind of card. It is not your unread messages, it is your decisions.

the detail Adding a new kind of “needs a human” is a row of data, not new UI: a task is blocked exactly when it holds a human-kind dependency, so the inbox stays one surface no matter how many ways the machine learns to ask.

What a project delivers

A project is one source tree, the place the work happens. What you receive is the artifact that comes out of it: the live page you can open and run. Keeping the two separate means one project can produce many deliverables, and every deliverable has a clear home.

From a draft to a live, shareable page

Work an agent produces is an artifact: it starts as local source and becomes a published, live page anyone you choose can open at its own *.wehandoff.ai address. Previews stay private by default, and a shared link holds steady across re-publishes while the page behind it improves.

local sourceon your machinepublishlive pagename.wehandoff.aiprivate by defaultv1v2 · same URLv3 · same URLone stable link, a lineage of versions behind it

Guests collaborate without joining your workspace

A room gathers everyone, people and agents, around one artifact: they open the preview together, pin feedback to the exact spot, and the maker’s agent picks the notes up and iterates. The same room handles an internal review and a hand-off to someone outside your workspace.

the design Room membership, not workspace membership, is the unit of access. An outside guest can collaborate on the artifact in that room without ever seeing the rest of your workspace.

shared artifact12feedback pinned to the exact spotyouguest + agent

How a sentence becomes a buildable design

A one-line need does not jump straight to code. A user-story captures what the person actually wants, then the design is composed against the spec and a fixed set of components, not invented freehand. The result is a design the harness can build against, and the evaluator can check against later.

“a booking mini-program”user-story · the intentspec + componentsa design to build against

To you, your agent is another you

You see your own agent as a stand-in for yourself; everyone else sees it as a teammate. It can speak to the whole room or only to you, and that route is set by an explicit marker the agent writes, never inferred from context.

agent writes a reply<<group>> the whole room sees it<<dm>> only you see it

Workspaces keep tenants apart

A workspace is the boundary: members, projects, and model endpoints, archived or restored as a unit. You invite people in, and everything they can reach is scoped to it.

A gateway for models, not a vault for your keys

Access is scoped by room membership through row-level rules, so people see only the rooms they are in.

the boundary WeHandoff is a centralized LLM gateway, not a credentials broker. Your keys stay in your OS keychain, on your own computer.

your machinekeychainyour provider keysWeHandoffroutes modelsGLMClaudethe call routes out, your keys never cross the line
Part 2 · the harness

How an agent and the machine build software together.

Work moves through a fixed pipeline. At every stage an agent makes a judgment while the harness does the deterministic mechanics, and each stage runs the model that fits: cheap where it is labor, strong where it is judgment.

backlogtodoin_progressin_reviewintegratingdone
off the line: blocked · Needs you, cancelled dropped — eight statuses in all, locked.
stage 1
Intake & mint
raw input → todo
agent: a mint skill interrogates the need. Does it want a design mockup? a user-story? what is the goal? It shapes a task at the right difficulty.
code: opens the task, carrying its goal.
model · GLM-5.2 (built-in agent), or your own coding agent via the CLI
stage 2
Dispatcher
todo in_progress
agent: clusters related todos by what they actually touch, so coupled work ships together.
code: every tick, fills executors to cap by priority, stamps against stale output, reclaims orphans, hands clusters to the executors. Dispatches only while your machine is online.
plan-dispatchanti-stale stampschedule-recheckorphan reclaim
model · GLM-5.2 for clustering; dispatch and retry are pure code
stage 3
Executor
in_progress
agent: a disposable executor writes code and tests, then hands back proof you cannot fake: a git diff, real test runs, screenshots.
code: claims the task (compare-and-set), spins a real git worktree, self-checks with vitest, commits a branch, then exits and is reclaimed.
claim (CAS)git worktree addvitest self-checkthen exit
model · pluggable runtime: our own GLM-5.2 by default, or Claude Code headless. Swapping it touches nothing else.
stage 4
Evaluator the one hard gate
in_progress in_review
agent: evaluators the result against the goal and the submitted evidence, comparing what was built to the design. It tries to disprove the claim; missing evidence means reject.
code: runs the deterministic checks first (types, tests, lint).
1 · code gate: tsc + vitest + lintbaseline-diff2 · visual evaluator
↩ not OK → kicked back
model · GLM-5V (vision). Gates agents, never people
stage 5
Merge
in_review integrating done
code: one writer to main. It rebases onto the latest main, re-runs the checks, merges with no fast-forward, and batch-pushes. Nothing merges itself.
agent: only steps in to resolve a genuinely ambiguous conflict.
integrating: one-way, only a human haltsrebase-firstno fast-forwardbatch push
model · none for clean merges; Opus for ambiguous conflicts
running underneath, the durability layer
wait-alarm: release an executor while it waitsheartbeat reclaims dead and zombie executorsmerge-daemon runs as a singletonbaseline-diff: old red never blocks new work
the loop that trains the loop

The harness sharpens its own engine.

The same real tasks feed a second loop. Real workload is the training signal, so the engine that does the work keeps improving without anyone writing synthetic data.

Work loop GLM-5.2 · our engine

Our own engine runs the executor and actually ships the tasks, cheap enough to run at scale.

Optimize loop Claude Code · the teacher

Claude Code runs the same task in parallel (every failure, one in N of the successes), sees where our engine fell short, and distills an engine patch: a better prompt, scaffold, or tool. A strong harness sharpening ours.

the safety valve · should-apply-engine-patch

A patch only lands if it beats a held-out benchmark beyond noise. Without this gate, “always optimizing” drifts into a random walk. It is the amplified version of the trap where every test passes but the function just returns a constant.

Three engines do the work (route, produce, verify), and a fourth role, Claude Code, tunes all three. Every engine’s prompt and scaffold is something that fourth role can rewrite.

It built the page you just read.

The point was never a smarter model. It is giving the deterministic work to code, turning each failure into a check that catches the next one, and handing the judgment calls to people.

0 lines hand-written by me. 1 person in the loop.
Behind that: 3,176 commits and 72k lines of app code across 1,035 tasks.

from the project’s task log, June 2026