Landing Page
Simulate real infrastructure problems
Natural language world control
Agents as city residents

God’s Plan: A Living Multi-Agent Urban Planning Simulator

💡 Inspiration

Urban planning decisions rarely affect just one system. Closing a road can delay emergency vehicles. A transit disruption can shift demand onto nearby routes. An evacuation order can create congestion, separate communities, and overwhelm critical infrastructure.

Traditional city simulators are powerful at modeling systems such as traffic and population flow, but human behavior is often represented through fixed rules. This makes it difficult to explore how people with different goals, relationships, responsibilities, and access to information might respond to the same policy.

So, we asked:

What if urban planners could test infrastructure and policy decisions in a city populated by autonomous AI residents?

God’s Plan began as a way to explore serious scenarios such as transit failures, evacuations, road closures, service disruptions, and emergency response. We wanted users to propose a policy in natural language, observe how it affects the city, and inspect why individual residents respond differently.

The result is a multi-agent simulation platform for exploring urban planning decisions in a dynamic, shared environment.

🌎 What It Does

God’s Plan is a 3D urban simulation populated by thousands of autonomous AI residents.

Each resident has its own:

observations → goals → relationships → allegiances → internal state

Residents can move through the city, communicate, drive vehicles, use services, cooperate, flee hazards, and respond to changes in infrastructure or public policy.

This lets users study not only whether a plan works at the city level, but also how its effects are distributed across individual residents and communities.

🏗️ Test Urban Policies

Users can introduce planning and infrastructure changes such as:

Closing roads or transit routes
Evacuating a neighborhood
Adding buildings or public services
Changing population density or demographics
Responding to fires, earthquakes, and power outages
Assigning emergency vehicles or temporary shuttle routes

The simulation then shows how residents, vehicles, institutions, and infrastructure respond over time.

🤖 Multi-Agent Swarms

Residents can belong to larger swarms representing groups such as civilians, emergency responders, police, transit operators, municipal agencies, or custom organizations.

Swarms receive high-level objectives, while individual residents continue making local decisions based on what they know and experience.

This allows coordinated policies to interact with decentralized human behavior.

💬 Natural-Language Policy Control

Users can modify the city by describing the outcome they want:

“Evacuate downtown while keeping emergency routes open.”

“A magnitude 7 earthquake hits Toronto.”

“Replace the closed subway line with temporary shuttle service.”

God’s Plan translates these instructions into simulation events or swarm objectives. AI agents propose responses, deterministic validators check their feasibility, and the transportation simulator measures the resulting effects.

👤 Inspect Individual Impact

Every resident can be inspected individually.

Users can see a resident’s role, relationships, beliefs, current situation, and planned actions. This makes it possible to understand how a city-level policy affects specific people rather than relying only on aggregate metrics.

A plan that improves average travel time, for example, may still leave a particular neighborhood without reliable access to transportation.

🛠️ How We Built It

🧠 The Agent System

Each agent receives only the information available to it, including nearby residents, visible events, messages, memories, relationships, and swarm objectives.

The model reasons over that context and selects from structured actions:

move → inspect → communicate → follow → drive → interact → attack → defend

Our evidence, demand, and planning specialists run as Huawei openJiuwen ReAct agents. Each specialist has access to narrow, read-only tools. They can investigate conditions and propose plans, but deterministic validators decide whether those plans are feasible.

This separation allows language models to reason flexibly without letting them invent infrastructure, ignore capacity constraints, or claim unmeasured results.

We also run resident swarms on different models, including GPT, Claude, Gemini, and Grok, through OpenRouter. Instead of evaluating each model on an isolated prompt, we can observe how different models behave and interact inside the same urban environment.

🕸️ Social Simulation

We maintain a dynamic social graph containing relationships, group membership, trust, and shared history.

These relationships influence future decisions. A resident may follow information from someone they trust, remain with family during an evacuation, assist a nearby person, or reject instructions from an unfamiliar source.

This helps the simulator represent an important part of urban policy: people do not respond to public decisions independently or uniformly.

🏙️ The City

Our backend uses Python, FastAPI, and Pydantic to represent agent state, events, actions, scenarios, policies, and simulation results.

We use SUMO and TraCI for transportation simulation. The frontend uses React, TypeScript, Zustand, and Babylon.js to render the city in 3D.

The environment combines real street geography with Toronto building data, allowing policies and agent decisions to affect a recognizable city rather than an abstract grid.

Scenarios, proposed plans, validation results, and simulation runs persist in MongoDB Atlas. Municipal notices are retrieved through Elasticsearch, allowing restrictions used by an agent to be traced back to their sources. Replay exports are stored through Cloudflare R2.

🚧 Challenges We Overcame

1. Giving Agents Freedom Without Giving Them Magic

Language models are willing to propose actions that sound reasonable but are physically impossible:

“I get in the car and drive away.”

The vehicle may not exist. The road may be closed. The resident may not be nearby. The route may exceed the available capacity.

We built a structured action layer that allows agents to reason freely while ensuring that their actions obey the current physical state of the city.

2. Separating Proposed Policies From Measured Outcomes

A plausible plan is not necessarily a successful plan.

Our AI specialists can estimate demand and propose interventions, but they cannot declare that a policy worked. Deterministic validators check constraints, and SUMO measures transportation outcomes during the simulation.

This keeps generated recommendations separate from verified results.

3. Preserving Evidence and Provenance

Urban decisions depend on notices, restrictions, effective dates, and changing information. An outdated notice can completely change whether a plan is valid.

We preserve retrieved evidence in content-hashed bundles containing source identifiers and effective windows. This makes it possible to inspect the exact information that informed a policy proposal.

🏆 Accomplishments We’re Proud Of

City-Scale and Resident-Scale Analysis

God’s Plan operates at two levels.

Users can zoom out to observe thousands of residents forming crowds, moving through transportation networks, coordinating, and responding to infrastructure changes.

They can then inspect a single resident to understand the individual decision behind the larger pattern.

This connects aggregate outcomes with the people affected by them.

Natural Language as a Planning Interface

We are especially proud that natural language controls the simulation itself rather than acting as another chatbot.

Instead of asking:

“What might happen if downtown lost power?”

a user can tell the city:

“Downtown just lost power. Keep hospitals accessible and reroute transit.”

The system turns that instruction into a scenario, generates a response plan, validates it, and simulates its consequences.

Inspectable Policy Proposals

Each proposed intervention is connected to its evidence, assumptions, validation results, and measured simulation outcome.

This makes the platform useful as an exploratory planning environment rather than an opaque system that produces recommendations without explanation.

🎓 What We Learned

The biggest thing we learned is that urban systems become more interesting when autonomous agents share consequences.

One resident can make a reasonable decision that changes the environment for everyone else. Hundreds of individually sensible choices can create congestion, panic, unequal access, or unexpected coordination without any agent explicitly planning those outcomes.

We also learned that average results can hide important differences. A policy may improve overall traffic flow while making conditions worse for a specific neighborhood or demographic group. Combining city-scale metrics with resident-level inspection makes these tradeoffs much easier to identify.

Finally, we learned that language models are most useful when they propose and explain decisions, while deterministic systems enforce constraints and measure results.

🗺️ What’s Next for God’s Plan

We want to expand God’s Plan into a more rigorous environment for exploring infrastructure and policy decisions.

Long-Term Memory: Allow past disruptions and policy decisions to influence residents over longer simulations.
Richer Social Dynamics: Model how trust, reputation, beliefs, and community relationships evolve.
Equity Analysis: Compare how policies affect neighborhoods, occupations, demographic groups, and people with different transportation access.
Policy Comparison: Run multiple interventions against the same scenario and compare congestion, evacuation time, service coverage, and individual impact.
Emergent Organizations: Let residents form alliances, choose leaders, disagree, and reorganize in response to city conditions.
Live Municipal Data: Replace controlled scenario fixtures with independently sourced notices and infrastructure data.
More Expressive World Control: Support increasingly complex planning scenarios without requiring users to configure the simulation manually.

🧩 How We Used the Sponsor Platforms

Huawei openJiuwen

We used Huawei openJiuwen to run our evidence, demand, and planning specialists as ReAct agents.

Each specialist has an AgentCard that grants access to specific read-only tools through ability_manager. The evidence agent retrieves relevant city notices, the demand agent estimates transportation needs, and the planning agent proposes infrastructure responses. If a proposal fails deterministic validation, the planner receives specific feedback and revises it.

Our resident communication system also uses message fields inspired by openJiuwen’s MessageEnvelope. A deterministic router delivers messages between nearby residents efficiently without requiring a separate model call for every interaction.

Elasticsearch

We used Elasticsearch to index and retrieve municipal notices that affect infrastructure plans.

Notices are organized by city and searched using a title-weighted, fuzzy multi_match query. Retrieved results are stored in content-hashed evidence bundles containing source identifiers and effective dates. This lets users trace each restriction or planning decision back to the information that informed it.

We also implemented a clearly labeled local fallback dataset so scenarios remain reproducible if Elasticsearch is temporarily unavailable.

Rox Best AI Agent

We used the Rox Best AI Agent challenge as the framework for our evidence-based planning workflow.

Our analyst resolves conflicting information by identifying which notices are current and which have been replaced. The planner must then produce a proposal grounded in that evidence. When a plan fails validation, it receives specific feedback and must correct the issue instead of being accepted simply because it sounds convincing.

This creates an agent workflow that can retrieve evidence, reason about conflicting information, propose an urban intervention, and revise that intervention when it violates real constraints.

OpenAI Models Through OpenRouter

We used OpenAI models through OpenRouter to summarize evidence and generate infrastructure plans.

In a recorded Toronto scenario, openai/gpt-4o-mini analyzed the available evidence and proposed temporary shuttle assignments. The system produced two validated plans and completed a SUMO transportation simulation.

The model generates the proposal, while deterministic code verifies its constraints and SUMO measures the resulting transportation outcomes. This separation keeps creative planning flexible while ensuring that reported results come from the simulation.

Backboard

We successfully integrated Backboard as the persistent conversation layer for our planning agents.

We adapted openJiuwen’s chat-completions interface to Backboard’s thread API using a local /llm/v1 compatibility layer. Agent messages, tool calls, and tool results remain connected to the same Backboard thread, with tool outputs returned through /threads/tool-outputs.

This allows specialists to preserve context across multiple tool calls and planning steps rather than treating every request as an isolated prompt. We tested the complete integration through both automated tests and a successful live Backboard run.

MongoDB Atlas

We used MongoDB Atlas as the persistent data layer for scenarios, demand estimates, proposed plans, validation results, simulation runs, evidence bundles, and investigations.

Related records, such as a scenario and its demand estimate, are written together so that one cannot be saved without the other. We also implemented document-size checks, duplicate-write protection, and an explicit offline JSON mode.

This gives every simulation run a durable and inspectable history, from the original policy request to the validated plan and measured outcome.

Cognition Devin

We used Cognition Devin to help review the codebase, deploy the frontend to Vercel, configure single-page application routing, connect the custom domain, and verify DNS.

Devin also inspected the deployed application directly in a browser. During verification, it discovered that the frontend was not connected to the backend, an issue that would not have been caught by checking only for a successful HTTP response.

This helped us validate the complete deployed experience rather than confirming only that the frontend was reachable.