Handoff

• 

  Workflow Thumbnail

• 

  Live Board

Why we built Handoff

AI agents are getting good at taking actions, but there is a simple problem: who decides what the agent is actually allowed to do?

We built Handoff to explore a different interaction model.

Instead of telling an agent exactly what buttons to click, a person gives Handoff a goal and constraints. The agent can then inspect the real project, gather evidence, identify problems, and propose different ways to solve them. The person reviews the options and approves what should happen.

For example, in our demo, Handoff connects to a real GitHub repository. The agent inspects the codebase, issues, pull requests, commits, and CI status, then identifies problems with the application's content-management flow. Rather than immediately changing anything, it turns its findings into an implementation plan with cost, risk, tradeoffs, and proposed actions.

The plan appears in Handoff's Decision Room. The human can approve, reject, or change the constraints before anything consequential happens.

Once approved, the authorized actions execute. External GitHub actions are treated as a separate boundary: the agent can propose creating an issue, branch, or pull request, but it cannot authorize those actions itself.

Every step is recorded in the Shift Ledger, including what the agent investigated, what it proposed, what the human approved, and what was executed. The entire collaboration can then be replayed.

What we learned

The biggest lesson was that human-in-the-loop interaction works better when the human is involved at the decision point, rather than being asked to supervise every individual agent action.

We also learned that WebMCP is most interesting when the tools expose meaningful application capabilities rather than simply reproducing buttons as agent commands. Handoff uses the same underlying application state for both the human interface and the agent tools, so an agent is working with the actual project state.

How we built it

Handoff started as a small HTML, CSS, and JavaScript task board. We deliberately kept the implementation lightweight so the WebMCP integration was easy to understand and inspect.

We then built the collaboration layer around it: missions, task state, agent activity, proposals, approvals, permissions, and replay. The project was extended with a backend for GitHub OAuth and repository access, allowing agents to inspect real repositories through WebMCP.

The current implementation exposes 19 WebMCP tools. Read operations such as repository inspection, issues, pull requests, commits, CI status, and blocker detection can be performed autonomously. Consequential GitHub operations are represented as proposed changes and only execute after a human approval.

Challenges

The hardest part was making the approval boundary real rather than cosmetic. We wanted an agent to be able to reason about an action without being able to silently perform it.

We therefore put the permission checks in the application logic itself. An agent can propose a change, but execution of an external action is only reachable through an approved decision.

We also had to handle the practical parts of building a real WebMCP application: keeping the agent and human UI synchronized, recording every state transition, handling GitHub authentication securely, and making the system work with the live state of an external repository.

Handoff is our exploration of a simple question:

What if an AI agent could do the work, but the human could always see what it wants to do before it crosses an important boundary?

Built With

• agents
• ai
• css
• html
• human-in-the-loop
• javascript
• next
• oauth
• vercel
• webmcp