Agentic Neighborhood Planner (CommonGround)

• 

• 

• 

• 

Inspiration

A Full E2E agent feels good but difficult to execute when the decision is consequential. A lot of countries municipalities struggle with neighborhood planning specially developing countries either due to various reasons since municipalities have access to all data to actually make decision a agent that does the planning but leaves the execution and approval to humans is the right bet. Neighborhood planning makes the problem easy to understand: there is a fixed budget, several reasonable projects, and no single answer that is obviously correct.

Agentic Neighborhood Planner (CommonGround) started from the idea that an agent should be able to do the planning work without quietly becoming the decision-maker.

What it does

Agentic Neighborhood Planner (CommonGround) is a browser-based planning desk for a fictional Riverside ward.

The demo starts with a $1 million budget and six possible neighborhood projects. The initial plan includes a youth center and transit shade, leaving $600,000 available. The person using the app chooses an outcome, such as making the neighborhood safer during a heat wave, and selects the priorities they want to protect or improve.

The available priorities are Cooling, Child safety, Accessibility, and Mobility.

When the person asks the steward for help, a WebMCP-capable browser agent can inspect the current plan and create a draft proposal. In the demo, a heat-related goal or the Cooling priority adds projects such as water stations and tree canopy. Child safety keeps the youth center protected, and Mobility preserves or adds transit shade.

The draft shows:

• Which projects are included
• The estimated cost
• The remaining budget
• An illustrative heat-coverage change
• Which priorities are being protected
• A visible activity entry showing what the agent did

The agent can also simulate the draft. This displays the proposal's projected cost and coverage without changing the committed plan.

The most important part is the approval boundary. Calling commit_plan does not silently change the neighborhood plan. It creates an approval request in the interface. The person must click “Approve & apply” before the plan changes.

After approval, the map, budget, and project count update together. If the person changes their mind, Undo restores the previous committed plan and records the reversal in the activity ledger.

The browser agent in this project is an external WebMCP-capable client, such as ChatGPT's in-app browser. Agentic Neighborhood Planner (CommonGround) itself does not contain a separate language model. Its job is to expose a clear tool surface and keep the agent and person working against the same visible state.

The Riverside data is synthetic. Agentic Neighborhood Planner (CommonGround) is a prototype for demonstrating the interaction pattern, not a live municipal planning service.

How we built it

The frontend is built with React, TypeScript, and Vite. The project uses Bun for development and testing, a small Bun/Nifra ( Nifra is own Full Stack Framework https://github.com/nifrajs/nifra )API for the production-shaped server, and Cloudflare Pages for the live demo.

WebMCP is implemented directly through:

document.modelContext.registerTool(...)

Agentic Neighborhood Planner (CommonGround) registers five tools:

• inspect_current_plan
• propose_plan
• simulate_tradeoffs
• commit_plan
• undo_last_commit

Each tool has a name, description, input schema, and an executable action. inspect_current_plan and simulate_tradeoffs are marked as read-only. The commit tool checks that the requested draft is still current, checks the budget, and then asks the person for approval instead of applying the change itself.

The interface and the tools operate on the same application state. A proposal is a draft copy and does not mutate the committed plan. When a commit is approved, the server checks an expected state version before writing it. If the state is stale, the request is rejected instead of overwriting newer changes.

The API exposes routes for health checks, reading the current plan, creating proposals, committing an approved proposal, and undoing the last commit. Request bodies are validated at the Nifra route boundary.

In a browser where native WebMCP is unavailable, the regular interface remains usable through its own controls. Native agent tool registration is active when the browser provides document.modelContext.

Challenges we ran into

This was intentionally scoped as a small prototype, so the hard part was not collecting live city data or building a sophisticated planning model. The real challenge was making the boundary between an agent's suggestion and an actual change impossible to miss.

A proposal had to remain a separate draft. The map and budget could not change until the person approved it. The WebMCP tools, interface, and API also had to agree about the current plan, its version, and whether an undo operation was available.

WebMCP is a browser capability, so the experience also had to account for the difference between a browser that exposes document.modelContext and one that does not. We verified the native flow in ChatGPT's in-app browser while keeping the normal interface usable in other browsers.

Accomplishments that we're proud of

Building a first WebMCP project gives me joy. The part I am happiest with is the approval boundary actually being part of the working product. Calling commit_plan creates an approval request; it does not silently apply the draft. The map only changes after the person clicks Approve & apply.

The rest of the loop is there too: the agent can inspect the live plan, make a budget-aware proposal, simulate it, and undo the last approved change. The WebMCP registry, typed API contract, synthetic data, and evaluation prompts are all in the open-source repository, so the idea can be checked rather than taken on faith.

What we learned

Frankly I was going to create a standard for interacting with web a while back before i came to know WebMCP exist because this was a natural extension to MCP. An agent is easier to work with when the page exposes clear actions instead of forcing it to guess what a button means. A tool such as simulate_tradeoffs gives both the agent and the person a more precise understanding of the next step.

I also learned that human approval and undo need to exist in the state model and the actual interaction flow. They cannot be added later as a disclaimer.

Finally, synthetic data can be the honest choice for a prototype. It makes the interaction repeatable and testable without pretending that a fictional map represents a real city, real residents, or real climate research.

What's next for Agentic Neighborhood Planner (CommonGround) — shared decisions, made visible

The next version would be aimed at neighborhood associations, community organizers, and small civic planning teams preparing for a meeting or vote.

I would connect the workflow to real, consented planning data, show the source behind every important number, and support several people comparing proposals while preserving the history of the decision.

Before using Agentic Neighborhood Planner (CommonGround) in a real civic setting, it would also need stronger accessibility, permissions, validation, persistence, and a clear record of who approved a change and why.

The current project is a working prototype of the interaction model. It is not claiming that the civic planning problem is solved. The Youtube video and Images still shows the old name CommonGround, I changed the name because Agentic Neighborhood Planner is more clearer for what it does and for a challenge.

Built With

• ai
• bun
• cloudflare-pages
• nifra
• react
• typescript
• vite
• webmcp