This is a submission for the MLH x DEV Writing Challenge In fairytales, kings and queens are remembered not by the crowns they wore, but by the kingdoms they built.
Today, we have the opportunity to shape the world around us, too. What if we could redesign the cities we live in, simulate the consequences of our decisions, and use AI agents to help us build better places?
Meet Meridian, an agentic workspace for designing and simulating real cities.
I worked on this project with Sriram Mupparapu, Saketh Sripada, and Siddhant Maji.
If you have ever taken a walk during summer in Texas, you know the feeling. You find yourself hopping between patches of shade under the trees, trying to avoid the sun for just a little bit longer. It sounds like a small problem, but it reveals something much bigger: the way we design our cities directly affects how people experience them.
Street trees influence pedestrian heat exposure. Impervious surfaces affect stormwater runoff. Street layouts determine how easily people can walk, cycle, or reach public transit. Parks, buildings, and infrastructure all interact in ways that are difficult to understand when planning tools are scattered across separate applications.
We wanted to make that process more visual, interactive, and accessible. What if we could explore a digital model of a real city, describe a problem in plain English, make changes with an AI agent, and simulate how those changes affect the surrounding environment, all in one workspace?
That idea became Meridian.
Meridian is a browser-based, 3D city planning and simulation workspace built around a detailed digital model of central Austin.
Our initial model covers approximately 17 km² of Austin, including Downtown, the Texas Capitol, UT Austin, East Austin, Rainey, Bouldin, and both banks of Lady Bird Lake.
The model brings together:
We can orbit around the city, search for landmarks, explore streets at ground level, and move through a day-and-night cycle with changing sunlight and illuminated windows. We also built a blank 3 × 3 km sandbox for experimenting with entirely new cities.
Meridian isn't just a 3D viewer. We can actively redesign the city.
We can add bike lanes, bus lanes, medians, rain gardens, wider sidewalks, green roofs, and new buildings. Our geometry system propagates changes through related streets, intersections, parcels, buildings, and infrastructure instead of simply drawing new shapes on top of the map.
For more complex designs, we built 220+ configurable objects and design primitives, ranging from buildings and schools to parks, trees, utilities, and entire subdivision layouts. We also built a sketch-to-city workflow. We can upload a photograph of a bird's-eye sketch, whiteboard drawing, or rough neighborhood plan, and our vision workflow converts it into a structured plan that a deterministic builder turns into an editable 3D district.
But the feature we were most excited about was the ability to let AI agents actually make changes.
Instead of building a chatbot that only recommends planting more trees or improving drainage, we built agents that can inspect the city, use tools, preview proposed edits, and commit approved changes directly to the shared city model.
Our agent platform includes geographic work zones, concurrent sessions, Plan and Edit modes, coordinated changesets, and human approval for potentially destructive operations. This lets our agents work toward a goal while keeping their changes inspectable, constrained, and reversible.
A proposed design is only useful if we can investigate how it might perform.
We built simulation models for:
| Simulation | What it helps us investigate |
|---|---|
| Urban heat | Surface temperatures, building and tree shadows, pedestrian heat exposure, and shaded walking routes |
| Stormwater | Runoff from design storms and the effects of rain gardens, green roofs, and retention features |
| Flooding | Potential inundation based on terrain and connected low-lying areas |
| Traffic | Congestion, traffic flow, intersection capacity, and daily changes |
| Cycling | Bike-stress levels, low-stress routes, and connectivity gaps |
| Accessibility | Walking times to parks, groceries, schools, and frequent transit |
| Emergency access | Fire and EMS response times relative to a four-minute benchmark |
| Capacity and growth | Development potential under zoning rules and redevelopment scenarios |
These simulations run in Web Workers against replayed scenario copies, allowing us to compare alternatives without blocking the main editor or permanently modifying the baseline city.
For example, we can investigate urban heat using weather data, land-cover information, measured tree canopy, and building and tree shadows. Our stormwater model uses NRCS TR-55 curve numbers and NOAA Atlas 14 design storms. Our goal is to make city planning an iterative process: design, simulate, compare, and improve.
Try Meridian: https://ge0.tech We've also put together a video walkthrough of Meridian, showing our project in action.
Watch the full demo on YouTube →
Here are a few workflows that demonstrate what we've built:
1. Explore Austin. Navigate the 3D city model, search for a location such as UT Austin, and inspect the surrounding streets and buildings.
2. Redesign a street. Modify street components or add objects such as trees, parks, and rain gardens. Meridian updates the relevant geometry and infrastructure.
3. Ask an agent to solve a planning problem. Describe a desired change in plain English, let the agent inspect the relevant area, and review its proposed operations before committing edits.
4. Compare environmental outcomes. Explore the urban heat, stormwater, flooding, traffic, or accessibility models to investigate how a design performs.
5. Turn a sketch into a city. Upload a rough neighborhood drawing and let Meridian transform it into a structured, editable district.
One example that captures our vision is asking an agent to redesign a paved parking lot as a small park optimized for stormwater drainage. Instead of stopping at a text response, our workflow is designed around making changes to the city model and evaluating the resulting design.
Two of the most important technologies in Meridian's AI workflow were Gemini and SerpApi. We wanted both to contribute to the actual planning process, rather than treating AI as an isolated chat interface or search as a separate information panel.
City GIS data, census information, and infrastructure inventories tell us a lot about a place, but they cannot answer every question about current businesses, nearby amenities, recent developments, or changing local conditions.
We integrated SerpApi's Google Search, Google Maps, Google News, and Google Scholar capabilities through three agent tools.
web_search — Researching planning questions
Our agent can research questions that extend beyond the local city model, including population growth, household size, rent, rainfall, local ordinances, transit information, and recent development news.
We normalize search results into compact responses containing facts, snippets, dates, and sources. The agent is instructed to cite figures, identify relevant years, and acknowledge when reliable information is unavailable rather than inventing an answer.
find_places — Understanding neighborhood accessibility
We can ask questions such as, "Are there any grocery stores within a 10-minute walk of the Texas Capitol?"
The agent searches Google Maps, retrieves relevant locations, and converts their coordinates into Meridian's local map.
Crucially, we don't rely on straight-line distances to estimate walking accessibility. We calculate walking times over the actual street network using Dijkstra's shortest-path algorithm, at the same walking speed used by our accessibility model.
This allows us to identify potential accessibility gaps, display nearby amenities as map pins, and investigate which parts of a district may be underserved.
import_places — Making search results part of the simulation
With our opt-in import tool, discovered locations can be added to the city as points of interest in a reversible changeset.
Once imported, these destinations can be included in our walk-access and cycling models. This connects live external information to the actual planning workflow: find a missing amenity, incorporate it into the model, and rerun the analysis.
Engineering within a limited API budget
We had a budget of 1,000 SerpApi credits for the hackathon, so we designed the integration to be deliberate and efficient.
We built a server-side proxy to keep API keys out of the browser, restricted requests to approved engines and fields, normalized large responses, cached searches on disk, and deduplicated identical concurrent requests.
We also added a search toggle to the agent composer so users can deliberately request live research.
The biggest takeaway was that search becomes much more useful when it can influence the model itself. SerpApi connects real-world knowledge to the geometry, accessibility calculations, and design decisions happening inside Meridian.
We used the Gemini API to interpret planning requests in plain English, reason about the changes needed to achieve them, and translate those decisions into actions the simulator can execute.
One particularly exciting application was our sketch-to-city workflow.
Using Gemini's multimodal capabilities, we interpret an uploaded image of a neighborhood sketch and convert it into a structured plan describing features such as streets, blocks, parks, bodies of water, and rail lines. We validate the resulting plan before a deterministic builder turns it into 3D geometry. Gemini also supports the reasoning behind our agentic planning experience. Given a request, the model helps determine which tools to use, which areas of the city to inspect, and which operations are needed to work toward the user's goal.
We deliberately avoid allowing free-form model output to modify the map directly. Instead, structured tool calls pass through Meridian's validation and safety systems, and each edit produces an explicit changeset that can be inspected, undone, and compared.
We also implemented a request router that classifies tasks as quick, standard, or deep. A straightforward location question shouldn't need the same reasoning budget as generating an entire neighborhood, so our router lets us adapt model configuration, output limits, and execution budgets to the task.
We built our core application using Next.js, React, and TypeScript, with MapLibre GL JS and deck.gl for mapping and 3D rendering.
Some of our key architectural decisions included:
Our broader stack includes Tailwind CSS, Radix UI, Zustand, WebGL, GPU-based raster blending, and Vercel hosting.
Together, these systems let us connect AI reasoning, real-world search, editable geometry, and environmental simulations in a single workspace.
We built Meridian in a single day, which meant balancing an ambitious vision against real engineering constraints.
One of our biggest challenges was rendering a detailed city without overwhelming the browser. We wanted Austin to look like a real place, not a collection of placeholder boxes. Rendering thousands of buildings, facade details, trees, and other objects simultaneously is expensive, so we invested in lazy , chunked scene streaming, level-of-detail tiers, frustum culling, instanced meshes, and custom GPU shaders.
Another challenge was managing state across a system with so many moving parts. We needed to preserve projects, scenarios, changesets, agent sessions, conversation history, and undo/redo operations. Explicit changeset history and persistent storage helped make the experience more reliable.
The hardest problems often appeared when we let multiple agents work on the same city. An agent might be working from an outdated preview while another agent changes the relevant street. A user might even switch scenario branches during a long-running operation.
We addressed these cases with a world lock, session-tagged changesets, scenario pinning, and checks for changes made since each agent last inspected the city. We also added approval flows for destructive operations and revalidated changes after approval, since the underlying city might have changed while an agent was waiting.
Despite the constraints, we came away with a working foundation for something much more ambitious than a conventional city-building demo.
We're especially proud of three things:
We also wanted Meridian to feel like a place to explore, not another generic dashboard. We chose an old-atlas aesthetic because we wanted the workspace to feel like opening a map of a kingdom.
The most important lesson we learned was that building a useful AI agent is about much more than choosing a capable model.
Agents need reliable tools, clear boundaries around what they can change, feedback about what happened, and a way to recover when something goes wrong. In a complex environment like a city, those safeguards are essential.
We also learned how interconnected urban planning really is. Drawing a road is easy; ensuring that the surrounding streets, curbs, buildings, parcels, drainage infrastructure, and simulations remain consistent is a much harder problem.
Finally, we learned that speed and accuracy don't always have to compete. Caching, compact tool responses, and task-specific reasoning budgets can make a system more efficient without simply relying on a less capable model.
Most importantly, we found that hackathon projects become much more interesting when we pursue the problems we genuinely care about. We could have built a chatbot that answered urban planning questions. Instead, we wanted to see whether an agent could explore, reason about, and redesign a real city.
That decision made Meridian much more ambitious—and gave us a much more interesting engineering challenge.
Austin is just our starting point.
We want to expand Meridian to additional cities, improve sketch-to-city with 3D visual input, develop more detailed traffic and heat simulations, and support shared planning projects where people and agents can collaborate on proposals.
Ultimately, we want to make it easier to explore what our cities could become before we build them in the real world.
Watch our demo: https://www.youtube.com/watch?v=zxUWpjdwFfw We built Meridian because the places we live in matter. We hope tools like this can help more people imagine, test, and create better ones.
Thanks for reading!