CommitWeb

• 

Inspiration

You ask an AI assistant a simple question:

"I'm moving to Bengaluru. Can you arrange my electricity, movers, mail forwarding, and internet? Keep it within my budget and make sure the appointments don't clash."

You want the AI to handle the details, so you do not have to manage every booking yourself.

But what happens if it confirms three services and then the internet booking fails?

The first three bookings still exist. Starting over could repeat them. Picking another internet slot could clash with the movers. And your approval of the first plan should not become permission to make any change.

That question inspired CommitWeb.

WebMCP gives AI agents tools to act inside web applications. We wanted to explore what comes next: how those actions can work together, and how an agent can recover when only part of your request succeeds.

The moving scenario is our way of making that problem easy to see.

The bigger idea is simple: if we trust AI to take action for us, it also needs a careful way to handle what happens when something goes wrong.

What it does

CommitWeb brings several service actions into one plan. It checks that they work together, asks for your approval, and helps recover when only part of the plan succeeds.

Our demo follows a move from Hyderabad to Bengaluru using four services: electricity, movers, mail forwarding, and internet.

You set the rules. Keep setup costs within 5,000 rupees. No appointments before 10 AM. No overlapping visits. Have electricity ready before the internet installation.

Before booking anything, CommitWeb checks the whole plan. If two appointments clash, it shows the problem and offers a repair.

You review the corrected plan and approve it.

Then comes the important part.

Three services confirm their changes, but the internet slot expires. CommitWeb keeps those three confirmations and looks for a new internet slot that still fits your original rules.

It shows why an unsuitable option is rejected. It checks the replacement against the bookings that already exist. And because the plan has changed, it asks for your approval again.

Only the replacement internet booking runs. The other three are not repeated.

At the end, you get a record of what happened, including the failure and the recovery. That record survives a page refresh and can be downloaded.

How we built it

We built CommitWeb with Next.js, React, TypeScript, and native WebMCP.

Each demo provider has its own browser document, saved state, and WebMCP tools. The coordinator discovers and calls those tools to prepare bookings, check the combined plan, and carry out approved actions.

WebMCP is part of the working system, not just a label on the interface.

Seven checks decide whether a plan meets the user's rules. These checks run in code rather than relying on an AI to guess. For example, the budget rule is:

Total setup cost must stay within 5,000 rupees.

Approval is tied to a fingerprint of the exact plan. A changed plan cannot reuse the old approval. Retry protection prevents the same approved action from creating duplicate bookings.

We used Codex throughout planning, implementation, debugging, and testing. We built in phases, checking the core behavior before moving on to the next part.

The current demo uses four independently stateful provider documents inside one same-origin application. They model separate services, but they are not live electricity, moving, postal, or internet companies.

Challenges we ran into

The hardest part was handling what had already happened.

After three services succeed, showing a single "failed" message is not enough. The system needs to remember which bookings exist, which step failed, and what can still change.

Recovery also had to respect the original request. A new internet slot is not a useful fix if it overlaps with the movers or breaks the budget.

Another challenge was keeping approval meaningful. We had to make sure approval for the first plan could not quietly authorize a different one.

We also worked through browser compatibility and tool lifecycle issues while testing native WebMCP. We checked the flow in a supported Chrome browser, not only through automated tests.

Accomplishments that we're proud of

We are most proud of the recovery sequence.

Three services commit. The fourth fails. CommitWeb preserves the successful bookings, rejects an unsuitable replacement, gets fresh approval, and completes only the missing booking.

We built 38 automated tests covering the core rules and recovery behavior, including expired holds, invalid approvals, duplicate retries, and saved state.

We also captured native browser evidence showing the completed recovery and the receipt after a refresh.

What we learned

A successful tool call is not the same as a successful outcome for a person.

Four bookings can each look reasonable on their own and still make a bad moving plan together.

We also learned that recovery should not hide failure. People need to see what worked, what did not, and what they are being asked to approve next.

That changed how we designed both the system and the interface.

What's next for CommitWeb

Our next step is to test the same approach with real providers across separate websites.

We also want to support more situations, such as travel bookings, where a failed step can leave someone with several confirmed arrangements and one missing piece.

Today, CommitWeb demonstrates recovery by finding a replacement. It can also prepare a fallback proposal for undoing supported actions, but it does not yet automatically carry out that process across providers.

We want to extend recovery carefully, while keeping the user informed and in control.

The goal stays simple: one failed step should not make you start over.

Built With

• next.js
• react
• typescript
• vitest
• webmcp
• zod