Merge-Queue

Inspiration

Most agent demos quietly assume the human stops touching the application while the agent works.

That assumption will not survive the real world.

A person might reassign an urgent task while an agent reorganizes the project board. A store manager might correct inventory while an agent prepares a merchandising update. Both actions can be reasonable, yet the application normally accepts whichever write arrives last and silently erases the other participant’s intent.

Software teams solved a similar problem for source code with branches and three-way merges. We wanted to explore what that collaboration model could look like for everyday web applications.

That became Merge Queue: humans keep working, agents get a branch.

What it does

Merge Queue is a local-first project board where a person and an AI agent can edit the same workspace concurrently without overwriting each other.

When the agent begins a task, Merge Queue snapshots the current workspace and creates an isolated agent branch. The agent can stage multiple structured changes—moving tasks, assigning owners, changing priorities, updating deadlines, or archiving stale work—without mutating the live board.

Meanwhile, the human continues working normally.

When the agent finishes, Merge Queue performs a semantic three-way merge between:

Base: the workspace when the agent started
Human: the current live workspace
Agent: the agent’s proposed workspace

For every changed field, the merge engine determines whether:

Only the human changed it, so the human value is preserved.
Only the agent changed it, so the proposal can merge safely.
Both selected the same value, so the duplicate change is collapsed.
Both selected different values, so the decision returns to the human.

Compatible work is merged automatically. Genuine disagreements appear as focused conflict cards showing the original value, the human’s choice, the agent’s proposal, and the consequence of each decision.

The agent can request a merge review, but it cannot approve its own work. There is intentionally no agent-accessible commit tool. The final merge is committed through the visible human interface as one atomic revision.

How we built it

Merge Queue is a dependency-free web application built with JavaScript, HTML, and CSS. It runs entirely in the browser, persists versioned state locally, and requires no API key or backend service.

The application is organized around a shared deterministic command layer. Human interface actions and WebMCP tool calls invoke the same underlying operations, which prevents the agent from using a hidden automation path with different behavior from the visible application.

We implemented WebMCP using imperative tools registered on the top-level page with document.modelContext.registerTool.

The tool surface allows an agent to:

Read the live workspace and its revision
Open an isolated agent branch
Stage bounded task updates
Stage new tasks
Inspect the branch diff
Generate a semantic merge preview
Read unresolved conflicts
Request visible human review
Check the branch status
Abort an uncommitted branch
Revert the latest completed merge

Each tool uses a narrow JSON Schema, validates its inputs again inside the domain layer, clearly describes its side effects, and returns enough structured information for the agent to verify the result and select the correct next action.

Agent proposals are visually distinguished from live state. A moved task can appear as a proposed destination while its original live card remains intact. An activity timeline interleaves human actions, agent proposals, and system merge events so the collaboration remains understandable throughout the workflow.

Merge previews are bound to a specific workspace revision. If the human changes the board after a preview is generated, that preview becomes stale and cannot be committed. The merge must be recalculated against the latest human state.

Commits are atomic and idempotent. Repeated commit attempts cannot apply the same branch twice. The previous workspace snapshot is retained so an approved merge can be reverted as a new revision without deleting history.

We also built a deterministic walkthrough that consistently produces safe changes, duplicate choices, and three meaningful conflicts. This makes the concurrency problem—and the value of the merge—visible in under ninety seconds.

Challenges we faced

Defining what a “conflict” means outside source code

Text files have lines. Application state has meaning.

Moving a task and changing its owner are independent operations that should usually merge. Moving the same task into two different workflow stages is a real conflict. Archiving a task while the other participant edits it also requires special handling.

We had to model these cases semantically instead of treating every modified object as one large conflict.

Preserving live human work

The most important invariant was that an agent proposal must never mutate the human workspace before approval.

We maintained separate base, human, and agent snapshots and forced every staged operation through the isolated branch. We added tests for independent edits, overlapping edits, creation, archival, stale previews, repeated commits, aborts, and reverts.

Designing human control without approval fatigue

Confirming every agent action would technically keep the human in control, but it would make the product painful to use.

We moved approval from the individual-action level to the merge level. The agent can prepare a substantial body of work, while the human reviews only the places where their intentions actually differ.

Making the agent understand what happened

A correct interface is not enough if the agent receives an ambiguous result.

Every tool response includes the current revision, branch status, affected records, and valid next step. The agent can distinguish between “staged,” “waiting for human resolution,” “ready for approval,” “merged,” and “aborted” without guessing from the page.

Remaining useful without WebMCP

The complete human interface and deterministic walkthrough work in ordinary browsers. When WebMCP is available, the agent discovers the structured tools and participates directly. When it is unavailable, the project remains a functional demonstration of the merge model rather than displaying a broken screen.

What we learned

The most important lesson was that safe agent collaboration is not only about restricting what an agent can do. It is also about defining how agent intent coexists with human intent.

Audit logs explain what happened after the fact. Approval dialogs interrupt actions before they happen. Merge Queue explores a third primitive: allow both participants to work, calculate where their intentions are compatible, and return only the irreducible decisions to the person.

We also learned that tool results are part of the user experience. A useful WebMCP tool needs more than a successful return value—it should explain what changed, what remained untouched, what state the workflow is now in, and what the agent should do next.

Most importantly, WebMCP feels strongest when it enables a collaboration model that ordinary browser automation cannot reproduce reliably. Merge Queue is not simply a faster way for an agent to click task-board buttons. It gives the agent a typed, versioned role inside the application.

What we are proud of

Agent proposals never mutate live state before approval.
Human work can continue while the agent stages a multi-step plan.
Compatible changes merge automatically.
Genuine conflicts remain human decisions.
Stale previews cannot commit.
Commits are atomic and idempotent.
Completed merges remain recoverable.
Human actions and WebMCP calls share the same application logic.
The complete experience runs locally without an API key or backend.

What’s next

Merge Queue’s engine is intentionally domain-independent.

The same protocol could power a wedding seating planner where a couple moves family members while an agent balances tables, or a merchant catalog where a store manager protects prices while an agent prepares a collection update.

Future versions could add multiple agent branches, collaborative network persistence, configurable application schemas, dependency-aware conflict explanations, and a reusable withMergeQueue() library for adding branch-and-merge semantics to existing WebMCP applications.

Our broader goal is to make concurrent human-agent editing a standard capability of the agentic web.

Humans keep working. Agents get a branch. Intent gets merged.