OMNI-Factory: An Open-Ended Multi-Agent Simulation for Smart City Resilience (OMNI-EPIC + Alpha-Factory v1)

preview

Current runnable path — 1.14.0

Mode: Offline simulation. Runs bounded smart-city episodes with local accounting.

Prerequisites: Python 3.11–3.13; installed project dependencies.

python -m alpha_factory_v1.demos check omni_factory_demo
python -m alpha_factory_v1.demos run omni_factory_demo

The catalog command uses bundled inputs and explicit offline defaults.

Expected result: Two episode outcomes; no token issuance. Simulation failure is reported as a nonzero exit.

Scope: Simplified numeric city model, not a Unity digital twin. Local ledger entries are not on-chain AGIALPHA.

The catalog explains installation, stopping, backups and recovery. Browser charts for legacy demos are labeled sample replays. Original research narratives and advanced scripts below are preserved; they do not expand the tested scope stated here.

This repository is a conceptual research prototype. References to "AGI" and "superintelligence" describe aspirational goals and do not indicate the presence of a real general intelligence. Use at your own risk. Nothing herein constitutes financial advice. MontrealAI and the maintainers accept no liability for losses incurred from using this software. Each demo package exposes its own __version__ constant. The value marks the revision of that demo only and does not reflect the overall Alpha‑Factory release version.

Run the full demo interactively in Google Colab.

To verify local prerequisites before launching the demo, run:

python check_env.py

This checks for key optional packages like pytest, prometheus_client, openai, openai_agents_sdk, google_adk and anthropic so that tests, cloud integrations and metrics work smoothly.

Offline Setup

The demo runs without Internet access when all Python wheels are pre-installed. On air‑gapped systems, install requirements from a local wheelhouse:

pip install --no-index --find-links /path/to/wheels -r requirements.txt

Ensure pytest and prometheus_client are present so the built-in tests and metrics exporter function correctly. See docs/OFFLINE_SETUP.md for more details.

Running Tests

Validate the demo using the bundled helper which falls back to unittest when pytest is unavailable:

python -m alpha_factory_v1.scripts.run_tests

Quick Alpha Discovery

Run the lightweight alpha_discovery_stub.py to generate example cross-industry opportunities. It runs fully offline by default but will ask OpenAI for live suggestions when an OPENAI_API_KEY is configured. The stub exposes a tiny CLI with a configurable output path:

# list all builtin samples
python alpha_discovery_stub.py --list

# record two random picks with a deterministic seed
python alpha_discovery_stub.py -n 2 --seed 42 --ledger ./custom_log.json

The script logs the selected opportunity (unless --no-log is used) to the specified JSON file (defaults to omni_alpha_log.json).

Extending via Plugins

You can augment the planner with custom heuristics without modifying the core code. Place Python files in the plugins/ directory; each may define a heuristic_policy(obs) function. When the demo starts, it loads these modules and invokes their heuristics if the default planner yields no action. The provided plugins/example_agent_plugin.py shows the minimal structure.

Use Case Selection & Rationale

We propose a Smart City Resilience Simulator as the demo’s real-world use case. This scenario entails an autonomous AI-driven “digital twin” of a city that can continuously handle evolving challenges—urban infrastructure management, emergency response, policy changes, and economic optimization. This choice is grand in scope (covering transportation, energy, safety, and more), impactful (directly related to citizens’ well-being and city economics), and useful for policymakers seeking regulatory foresight and infrastructure resilience. It is also engaging and fun to interact with (reminiscent of a city-building simulation game but powered by advanced AI), while elegantly demonstrating powerful AI capabilities (open-ended learning and multi-agent cooperation).

Why Smart Cities? Policymakers are already interested in “digital twin” simulations of cities to test infrastructure policies and disaster scenarios in silico. A smart city simulator aligns with that interest by showcasing how an autonomous system could anticipate and respond to real-world events. For example, the demo can simulate new transit regulations or a sudden flood and show how AI agents adapt traffic flows or reinforce the power grid in real-time. This directly highlights regulatory foresight (the AI can model outcomes of new policies before implementation) and infrastructure resilience (the city remains robust under stresses). Moreover, by tracking economic metrics (e.g. cost savings, efficiency gains as internal “tokens”), the demo illustrates economic impact in terms that matter to decision-makers.

Selection Logic: We considered several grand scenarios (e.g. autonomous manufacturing, global supply-chain optimization, climate crisis management), but the smart city use case best satisfied all criteria: it spans multiple domains (economy, environment, governance) for broad impact; it’s relatable and visual (city simulation is easy to grasp); it supports open-ended task generation (endless urban challenges); and it directly addresses policymaker goals like urban sustainability and crisis preparedness. Crucially, the open-ended multi-agent approach can continuously generate interesting, learnable tasks in the city context – from optimizing traffic lights to designing a flood defense system – ensuring the demo feels endlessly innovative and not scripted. This “Autonomous City” scenario therefore provides an ideal sandbox to fuse OMNI-EPIC’s generative open-ended learning with Alpha-Factory’s agent economy, in a way that clearly demonstrates system autonomy, value creation, and open-ended adaptability to policymakers.

Demo Architecture: Components & Data Flow

The system architecture integrates OMNI-EPIC’s modules for task generation and learning-loop with Alpha-Factory v1’s multi-agent orchestration, forming a closed-loop autonomous simulation. Figure 1 gives a conceptual overview of a distributed multi-agent architecture managing various city domains. The key components and their interactions are detailed below:

Figure 1: Conceptual architecture of a distributed multi-agent smart city system. Multiple AI agents (planner, learners, evaluators, etc.) coordinate via a central knowledge base and task pipeline to manage various city domains (transport, environment, industry, economy, governance). The design enables continuous data flow between environment simulations, agent decisions, and user interfaces in a scalable, distributed manner.

Orchestrator & Task Loop: At the heart is an Orchestrator Agent (Alpha-Factory’s central coordinator) that manages the cyclic workflow. It triggers new task creation, assigns tasks to appropriate agents/policies, and maintains the overall simulation timeline. The orchestrator essentially implements the OMNI-EPIC inner loop: generate task → attempt solution → evaluate → archive → repeat. It ensures agents work “in concert” towards system-level goals, without needing micromanagement of each step (demonstrating the “emergent intelligence without central control” ethos).
Task Generator (OMNI-EPIC): This component uses OMNI-EPIC’s Foundation Model-driven task generation to propose the next scenario or challenge. It consists of a large language model (LLM) that analyzes the Task Archive (a repository of past city scenarios and their outcomes) and produces a new task description in natural language. Guided by a Model-of-Interestingness (MoI), it aims for tasks that are novel yet feasible given the agents’ current skills. For example, it might generate: “A major power outage hits the downtown area during a heatwave; coordinate traffic and energy systems to minimize impact”. Alongside the description, the generator creates environment code that instantiates this scenario in the simulation (e.g. Python code or config to cause a grid outage and heatwave conditions in the city model). It also defines a reward or success criteria for the task (e.g. maintain service to >90% of critical facilities) – effectively programming the environment and objective. This ability to produce arbitrary new environments and goals via code is inherited from OMNI-EPIC’s EPIC module, allowing the system to “create any simulatable learning task” on the fly.
Post-Generation Filtering: Before committing a new task, the system evaluates its interestingness and relevance. An Interestingness Evaluator (another LLM instance) compares the proposed task to archived scenarios to ensure it’s not a trivial repeat and fits policymaker-relevant criteria. This is akin to OMNI-EPIC’s post-generation MoI check – tasks too similar to past ones or not sufficiently novel are rejected or tweaked. The orchestrator may also enforce safety/policy constraints here: e.g. discarding a task that involves unethical actions or unrealistic assumptions. Once a task passes this filter, it enters the active simulation.
Environment Simulator: The City Simulation Environment is where tasks play out. This environment has multiple realizations across platforms (Unity, PyBullet, etc., see Deployment section) but is controlled by a unified backend logic. The environment module takes the generated code/config from the Task Generator and instantiates the scenario: e.g. it will simulate the power outage by “tripping” certain grid nodes, spawn additional traffic on roads during the heatwave, and so on. The environment exposes an interface (akin to an OpenAI Gymnasium environment) for agents to sense state and take actions (e.g. adjust traffic lights, dispatch repair crews, reroute power, issue public alerts).
Learning Agents & Policy Selection: Alpha-Factory’s design includes multiple specialized agents; we incorporate both learning-based agents and potentially rule-based or retrieved policies to tackle the task:
A Planner Agent (possibly LLM-based) decomposes complex tasks into sub-goals or allocates responsibilities to domain-specific agents. For instance, it might split the outage task into “traffic management” and “power grid repair” sub-tasks, assigning each to the relevant specialist.
Domain Learner Agents use reinforcement learning or other AI algorithms to carry out actions in their domain. For example, a Traffic Agent (trained via deep RL) adjusts traffic signal timings, while an Energy Agent (using MuZero-style planning) reallocates power from backup grids. These agents either deploy pre-trained policies from the archive (if a similar scenario was solved before) or learn on the fly if the challenge is novel. The orchestrator’s policy selection mechanism will choose the best approach: it might recall a successful policy from a prior similar outage in the archive, or decide to train a new policy if none exists. This showcases transfer learning and reuse of past knowledge – a key benefit of maintaining an archive of tasks and solutions.
The agents operate in parallel and interact with each other through the environment (and possibly a shared blackboard for coordination). Alpha-Factory’s multi-agent orchestration ensures at least 5 roles (planner, environment generator, learners, evaluator, etc.) are integrated in real time. The whole system behaves as an “agentic AGI” network where the “whole is greater than the sum of its parts” – e.g. the traffic and energy agents collaborating yield a better outcome than either alone.
Success Detector & Evaluator: Once the agents have executed the task (or a simulation timestep/episode completes), the outcome is fed to a Success Detector module. This incorporates OMNI-EPIC’s automated success checking. Concretely, the environment code includes a function (generated alongside the task) to measure if goals were achieved (e.g. did the city return to normal within N hours?). Additionally, an LLM or Vision-Language model can assess qualitative success criteria, especially for complex outcomes. (OMNI-EPIC demonstrated using GPT-4 or a VLM to judge task completion in general settings.) The Evaluator Agent combines these signals to determine success/failure and possibly a performance score. It also monitors unintended effects (if any), providing an extra safety check (e.g. “Was the hospital power lost at any point?”). This automated evaluation closes the loop by confirming whether the generated task was solved or not.
Archive & Learning Loop: Following evaluation, the system updates its Task Archive (a database of scenarios). If the task was successfully solved, it is added to the archive as a “solved task” along with metadata: the task description, the environment code, the policy/solution used, and metrics achieved. If the task failed (agents couldn’t solve it after a certain number of attempts/learning iterations), it is added as a “failed task” with logs on what went wrong. This archive enables the open-ended learning loop: the next tasks will be generated with awareness of these results. For example, the Task Generator will avoid repeating the exact failed scenario until agents gain more skills, but it might generate a slightly easier variant to help the agents learn incrementally (curriculum generation). Successful tasks serve as stepping stones for greater challenges. Over time, the archive in this smart city could grow to include a rich variety of incidents and policy experiments the AI has handled, demonstrating an ever-improving capability.
Scoring & Economic Tokenization: To integrate Alpha-Factory’s “economic tokenization pipeline,” the demo introduces an internal Token Economy that quantifies the value created by each agent and solution. Every task has an associated value score or token reward, reflecting its importance or the benefit of its solution. For instance, preventing the blackout might yield a high number of “CityCoin” tokens corresponding to the economic losses averted. When agents successfully complete tasks, tokens are minted and allocated: e.g. the Traffic Agent and Energy Agent each earn tokens proportional to their contribution (perhaps determined by the evaluator). This mimics an economy where agents “earn” reward for useful work, incentivizing efficient collaboration. The orchestrator also uses token metrics for policy selection – for example, if a particular policy yielded high token rewards in past similar tasks, it will be prioritized in the future (an analog to how markets allocate resources to successful strategies). Conversely, repeatedly failed approaches might be “deprecated” or require spending tokens to attempt again, introducing a notion of opportunity cost. This token system thus provides a scoring mechanism to rank policies and agents by their track record, and a form of credit assignment in multi-agent settings (who contributed what to the overall outcome). It also makes the concept of “value creation” concrete: the system can report, say, “20,000 CityCoins generated today” which could be mapped to real-world value units (dollars saved, etc.) for policymakers to appreciate. The token economy is implemented as a module that logs all rewards, perhaps with a blockchain-like ledger for transparency. While primarily internal, its metrics are exposed on the UI to illustrate economic impact.
User Interface & Control Panel: The demo includes a rich UI layer that allows real-time interaction and monitoring. This isn’t a part of the AI core per se, but it’s an essential component for a human-in-the-loop experience. The UI provides:
Live Visualization: A 2D/3D city dashboard (or map) shows the city state (traffic congestion, power grid status, etc.) and visually highlights agent actions (e.g. rerouted roads glowing, or a pop-up icon where a repair drone is dispatched). Unity 3D renders can be streamed here for realistic visuals.
Control Toggles: The user (e.g. a policymaker) can toggle certain settings – for instance, enabling/disabling autonomous policy mode, introducing a manual event, or adjusting the frequency of random events. They can select different scenario types (“economic focus” vs “environmental disaster”) via dropdown, effectively nudging the Task Generator’s parameters. They might also toggle which agent/policy is active (e.g. use a “ConservativeTrafficPolicy” vs an “AggressiveRLPolicy” for comparison), demonstrating policy rollout control.
Explainable Feedback Panels: The interface displays textual explanations from agents. For example, the Planner Agent’s reasoning (sourced from the LLM’s chain-of-thought) can be shown: “Planner: detected citywide outage, prioritizing hospital power – instructing EnergyAgent to allocate backup generators.” Similarly, when the success detector decides a task is complete, it can output: “Evaluator: Task succeeded – 95% of infrastructure maintained. Criteria met.” These explanations make the AI’s decision-making transparent. We also include policy justification reports – each major action can come with a rationale (in simple language) and a confidence or risk level. This traceability is crucial for trust: policymakers can see why the AI did X, not just what it did.
Metrics & Scoreboards: A dashboard section shows key metrics: current task name and difficulty, time taken, tokens earned per agent, cumulative tokens (value) created, and any policy-relevant KPIs (e.g. traffic throughput, % power restored, etc.). This provides immediate quantitative feedback on system performance. Over multiple tasks, graphs can illustrate learning progress (e.g. decreasing time to restore services over successive outages, proving the system is learning to handle them better).

Data Flow Summary: The overall data flow begins with the user or environment trigger (either the user toggles something or the system decides it’s time for a new challenge). The Task Generator LLM creates a new task description and code, which is fed into the Simulation Environment. The orchestrator then activates the relevant Agents/Policies to address the task. Agents exchange information through the environment and possibly a shared memory (e.g. the Planner shares sub-goals). Their actions modify the simulated city state. The Evaluator monitors the state and, when completion criteria are reached or time expires, computes outcomes using the success detection methods. Results are logged to the Archive, tokens are awarded via the Token Module, and the cycle repeats for the next task. Throughout this, the UI updates to reflect the current scenario and allows user interventions at key points. This architecture realizes a fully integrated loop where OMNI-EPIC’s open-ended task creation melds into Alpha-Factory’s multi-agent problem-solving pipeline, continuously and autonomously.

User Journey & Interaction Modes

From a user’s perspective (e.g. a policymaker or an enthusiast exploring the demo), the journey is designed to be interactive, intuitive, and insightful. Below is a typical user experience narrative, highlighting how one can engage with the system:

Launch & Scenario Selection: The user launches the Smart City Resilience Demo on their platform of choice (desktop app, web browser, etc.). They are greeted with a main dashboard representing a virtual city. The user first selects the scenario focus or lets it run in fully autonomous mode. For instance, they might choose “Autonomous Mode: Continuous Learning” where the AI will keep generating new city challenges. Alternatively, they can pick a specific test like “Simulate Major Earthquake” to see a particular scenario. The UI provides these options via a scenario menu.
Configure Parameters (Optional): Through a side control panel, the user can adjust toggles that influence task generation and policy rollout:
Environment Toggles: Sliders to emphasize certain event types (e.g. increasing likelihood of natural disasters vs. economic disruptions), or to turn on/off random events. They could, for example, set “Enable Regulatory Changes” to true, which means the Task Generator will occasionally introduce a new law or policy constraint for the AI to adapt to (e.g. a sudden emission cap requiring changes in transit strategy).
Agent Policy Toggles: Options to control agent behavior, like switching the traffic control between two available policy modes (manual vs RL) for comparison. A user could disable the learning agent for a test, forcing the system to use archived knowledge, and see how that affects performance – thereby understanding the value of learning.
Pace Control: They can adjust simulation speed (e.g. 1x real-time, or fast-forward) and how frequently new tasks are generated (maybe one major event per simulated “day”, etc.).
All these configurations are optional; a novice user can also accept default settings and simply hit “Start Simulation.”
Observe AI in Action: Once running, the city simulation comes to life. Suppose the first generated task is a heatwave-induced power outage (as per our example). The user sees parts of the city dimming out (visual indicator of blackout) and traffic building up in certain areas (as signals fail). Immediately, the AI agents spring into action. The UI might zoom into affected zones and display agent activities:
The Planner Agent icon pops up with a brief text: “Planner: allocating tasks to sub-agents for power and traffic management.”
The Energy Agent icons (perhaps representing repair crews or grid control centers) move on the city map to address the outage, with a status message like “Restoring power to Hospital… (ETA 5 min)”.
The Traffic Agent adjusts routes; the user sees certain roads highlighted as detours, and a message “Rerouting traffic away from blackout zones to prevent congestion.”
These updates happen in real-time, and the user can click on any agent or region to get more info (e.g. clicking a power plant might show “Power Plant A: output increased 20% to compensate for Plant B outage” as decided by the AI).
A timeline or event log panel lists major decisions and their justifications in sequence, providing transparency.
Intervene or Explore: The user isn’t just passive—they can interact at any point:
They might introduce a manual event: e.g. clicking a “+ Event” button and selecting “Simulate Protest Downtown”. The system will inject this as an additional task (perhaps via the orchestrator’s interface), and the agents will need to handle it (e.g. reroute traffic and dispatch drones for monitoring the protest). This showcases the system’s flexibility to user-driven tasks outside its own generation.
They can tweak a policy on the fly: for example, toggle a switch “Prefer Green Energy”. This could bias the AI’s decisions (through a parameter update) to use renewable energy sources more aggressively. The user could then see how the AI adapts its strategy and possibly observe any trade-offs (like slightly slower recovery but lower emissions). This mode allows policymakers to test “what-if” scenarios easily.
The interface also allows pausing the simulation and stepping through decision frames. In pause mode, a user could inspect the state: e.g. check a table of neighborhoods and see which have power or the exact token rewards accumulated so far for each agent. They might rewind or fast-forward to skip routine periods and jump to the next event of interest.
Explanation & Feedback: Throughout the simulation, the user receives explainable feedback about why agents do what they do:
If the traffic agent closes a highway ramp, the UI might show a tooltip, “Closed ramp to avoid area with non-functional traffic lights – decision by TrafficAgent (explained by policy: safety > speed).”
If the AI fails or struggles (say a scenario is very challenging), the system can output a brief analysis: “Outcome: Failed to restore power within target time. Likely cause: insufficient backup generators. Next step: Task Generator will propose an infrastructure upgrade task.” This kind of commentary helps the user see the AI’s learning process and how it plans to improve.
After each major task, a summary report is displayed. For example, “Challenge: City-wide Blackout — Solved in 45 min. Key actions: 3. Tokens earned: 5000. Notable improvements: reduced traffic jams by 30% compared to last blackout.” This gives both technical and impact-oriented results in plain language.
Multi-User Interaction (if applicable): In a WebRTC multi-agent setting, multiple users (or multiple instances of the UI) could connect to the same simulation. A policymaker in one city department and another in a different department could collaboratively watch or control different aspects. For example, one user might take manual control of a “Policy Agent” role, effectively acting out a human decision while the rest of the system is AI-driven, to see how human-AI collaboration works. The simulation would update for all participants in real-time, demonstrating a kind of shared sandbox for policy experiments. (This is facilitated by the networking capabilities, see Deployment section.)
Iterative Open-Ended Play: As time progresses (could be minutes or hours of real time, representing days or weeks of simulated time), the system continues to generate new tasks and scenarios, many without user prompting. The city might go from dealing with a heatwave to experiencing an economic boom that stresses transport capacity, to a new mayor enacting strict emission rules, and so on – a continuous narrative. The user can drop in or out at will, intervening occasionally or just observing the AI autonomously handle things. They effectively watch an ever-evolving story of a city managed by a benevolent AI collective, and can gauge how well it anticipates problems, how it balances conflicting objectives, and how it learns from failures. The open-ended nature means the demo never plays out the same way twice, keeping engagement high.
Wrap-up and Insights: At any point, the user can stop the simulation and review aggregate insights. The system can generate a brief report or even a slide-deck style summary upon exit: “Over 10 simulated days, the AI handled 8 major events (3 economic, 3 infrastructure, 2 environmental) with an average response time of X. Infrastructure resilience index improved by Y%. Potential policy insight: investing in extra power backup yielded 15% faster recovery in outages.” Such takeaways translate the simulation results into terms a policymaker cares about. The user leaves the demo not only impressed by the AI’s autonomy but also with a better understanding of what strategies worked best for the city, illustrating the decision-support aspect of the system.

Throughout the journey, usability and clarity are prioritized. Short tutorials or tooltips guide new users (e.g. explaining what a toggle does). The interface remains uncluttered by revealing advanced options only on demand. This ensures non-technical policymakers can navigate the demo easily, fulfilling the Alpha-Factory goal of accessible deployment for non-experts. In summary, the user experience ranges from passive observation of a “living” autonomous city to active control of experiments, all with continuous feedback – making the complex AI internals tangible and understandable.

Cross-Platform Deployment Strategy

One of the demo’s core strengths is its ability to run on multiple platforms and environments, ensuring maximum reach and flexibility. The design abstracts the simulation logic and agent behaviors so they can be deployed in various forms without loss of functionality. Below we outline the deployment approach for each target platform and how cross-platform consistency is maintained:

Local Desktop (Native) Deployment: For power users and offline scenarios, the entire system can run as a local application. This might be distributed as a Docker container or an installer that packages the core server (orchestrator + environment backend) and a UI client. Taking advantage of Alpha-Factory’s Docker/K8s readiness, a user can spin up the multi-agent system on their machine (Windows, Mac, or Linux). The local Unity engine (if installed) or a lightweight rendering engine can handle 3D visuals, while Python processes handle the agent logic and environment physics (PyBullet). This mode ensures even without internet, the demo functions (though for full OMNI-EPIC capability an LLM is needed; offline mode might use a smaller local model or pre-generated tasks for demonstration). The local deployment is optimized for performance, leveraging GPU for physics and agent neural nets if available.
Web Browser (Web-Based) Deployment: To reach a broad audience quickly (e.g. during a policy expo or for stakeholders who don’t install software), the demo supports a browser-based experience. Using WebAssembly and WebGL, a simplified version of the city simulation can run client-side, or the browser can act as a thin client streaming the simulation from a server. We employ Unity’s WebGL build for visuals, coupled with a Web backend for the agents. In practice, the orchestrator and agents might run on a server (ensuring heavy computations stay on the server, including calls to large models), while the browser receives state updates via WebSockets or WebRTC data channels to update the visualization in real-time. User commands (toggles, interventions) are sent back to the server instantly. This architecture ensures near real-time interaction with minimal latency. The UI is implemented in HTML5/JavaScript for flexibility, mirrored to the desktop UI design. This web deployment means a user can go to a URL and immediately see the smart city AI in action, significantly lowering the entry barrier. We also ensure compatibility across modern browsers and devices; a tablet user, for example, could use a touch interface to trigger events in the simulation.
Unity 3D Client: Unity is utilized as a high-fidelity visualization and simulation environment. In one configuration, Unity (with the ML-Agents toolkit) is run as the primary environment engine: the OMNI-EPIC environment code generation produces configurations that Unity’s simulation can load (for example, using a predefined city template scene where elements can be toggled or moved via an API). The Unity build may run either on the user’s machine or a server. The agents connect to Unity through the ML-Agents Python API or a custom bridge, treating Unity as just another environment backend akin to Gym. This gives the benefit of realistic physics and graphics. For instance, traffic is simulated with real car dynamics, and infrastructure has physics (buildings can collapse in an earthquake scenario, etc.). The cross-platform design abstracts agent actions so they can target either a Unity environment or a PyBullet environment seamlessly. For example, an agent’s “set traffic light X to green” action can be implemented in both Unity and a pure Python sim – at startup, the system detects which environment is active and uses the appropriate implementation. Unity deployment primarily serves demonstrations where visual impact is key (e.g. live presentations to policymakers). It’s packaged as a standalone app or a Unity Viewer that attaches to the core via network. Unity’s role is strictly modular, ensuring if Unity is not available, a headless mode (with simpler visualization) can still run the logic.
PyBullet / Gymnasium Backend: In parallel, we maintain a Gymnasium-compatible environment (Gym is now Gymnasium in 2025) that encapsulates the city simulation logic in a physics-enabled but non-graphical form. PyBullet is used to simulate any physical aspects (e.g. movement of drones, structural physics for damage) in a lightweight manner. This headless environment is crucial for training and automated testing. Developers or researchers can run episodic simulations rapidly (without rendering overhead) to train the RL agents or test new algorithms. All agents are implemented to interact through a common interface, e.g. env.step(action_dict) returns observations and rewards. This means one can use standard RL libraries to train parts of the system by plugging in the Gym environment. The Gymnasium environment can also be used for continuous integration testing of the demo (ensuring new code doesn’t break the task loop). For deployment, the PyBullet environment runs inside the orchestrator process as the default, and Unity is an add-on that can subscribe to the state if visuals are needed. Maintaining this text/physics-based environment ensures the scientific validity of the simulation (reproducibility, controllable randomness) and cross-platform determinism.
WebRTC-Based Multi-Agent Setting: To support distributed agents and multi-user scenarios, the system leverages WebRTC (or similar peer-to-peer communication) for real-time networking. Each major agent (planner, traffic, energy, etc.) can optionally run in its own process or even on different machines. The orchestrator serves as a hub, and agents join as peers, synchronizing via a protocol (Alpha-Factory’s integration of protocols like A2A – Agent-to-Agent – could be implemented here). WebRTC data channels allow low-latency messaging between agents (e.g. if an agent is running in a browser or a remote server). This architecture has several benefits:
Scalability: More computationally heavy agents (like an advanced deep RL agent) can be offloaded to a dedicated server with a GPU, while lighter agents or the UI run locally.
Multi-Party Interaction: As mentioned in the user journey, multiple human users can connect as special “agent” roles or observers. WebRTC enables peer-to-peer or peer-to-server connections securely (with NAT traversal if needed), so a policymaker and an engineer could literally be seeing the same simulation and injecting different inputs.
Cross-language integration: Perhaps one agent is implemented in JavaScript (running in a browser) while others are Python – a networking layer allows them to work together. For example, an experimental “budget allocator agent” written by an economics researcher could connect to the main orchestrator via a WebRTC channel and participate in the token economy decisions, all without needing to run within the Python core.
The system will use secure communication (DTLS/SRTP in WebRTC) to ensure that even if agents are distributed, the data is protected – aligning with the “secure by default” goal.
Containerization & Cloud: Deployment strategies also consider cloud hosting. We can deploy the orchestrator and environment as microservices on a cloud platform. Using Kubernetes, one could spin up the simulation cluster, auto-scale agent services as needed (if, say, a particularly large simulation is run). The UI would then be accessed via a web client connecting to the cloud services. Containerization ensures that the exact same environment runs in the cloud as locally. For policymakers wanting to run scenarios with their own data (perhaps city-specific data), a cloud-deployed version could be offered where they upload city parameters and let the AI run. The design thus supports anything from a single laptop demo to a distributed cloud service with dozens of agents.

Consistency & State Sync: Across all these platforms, we maintain a consistent state by designing a clear separation of concerns:

A Core Logic Layer (agent decisions, task logic, environment state updates) that is platform-agnostic and can run headlessly.
A Rendering/Interface Layer that subscribes to state changes and presents them (Unity, web UI, etc.).
A Networking Layer that syncs state between core and interfaces or among distributed components. By using standardized data formats (e.g. JSON or Protocol Buffers messages for state, and standardized API calls for agent actions), each platform integration becomes a plug-and-play module. For example, the Unity module might receive a JSON like {"event":"power_outage", "location":"Zone 5", "severity":0.8} and then execute the appropriate visual changes. The same JSON could be handled by a simpler Python renderer for a console output. This design minimizes divergence between platforms – they all reflect the same “ground truth” simulation state and agent behavior.

In summary, the deployment strategy ensures the demo is ubiquitously accessible: a researcher can train agents in Gym mode; a policymaker can run a quick scenario from a web link; a demonstrator can show a rich 3D visualization on a big screen; and multiple participants can collaboratively engage with the scenario remotely. All these modes run on the same underlying engine, proving the system’s versatility and robustness.

Quick Start

Get the demo running in minutes.

# 1‒ Clone the repository
git clone https://github.com/MontrealAI/AGI-Alpha-Agent-v0.git
cd AGI-Alpha-Agent-v0

# 2‒ Launch via Docker (recommended)
cd alpha_factory_v1/demos/omni_factory_demo
cp .env.sample .env  # optional – edit to customise
chmod 600 .env
docker compose up -d  # builds image on first run

# 3‒ Open the dashboard
open http://localhost:8050 2>/dev/null || \
  xdg-open http://localhost:8050 || start http://localhost:8050

# Alternative: run directly with Python
cd ../../..
pip install -r requirements.txt  # install dependencies
python check_env.py              # confirm optional extras available
# If packages are reported missing, install them:
pip install -r requirements.txt  # or requirements-colab.lock in Colab
pytest -q                        # optional quick self-test
python -m alpha_factory_v1.demos.omni_factory_demo --metrics-port 9137
python alpha_factory_v1/demos/omni_factory_demo/omni_dashboard.py

The demo operates fully offline but seamlessly uses cloud APIs (OpenAI, Google ADK, A2A) when keys are provided.

Verification & Validation Strategy

To gain trust from stakeholders (especially when aiming at policy and safety domains), we need a rigorous verification strategy. We will validate the system on multiple levels: from technical correctness of each module to the overall value and safety of its behavior in the simulated domain. The following approaches ensure the demo is correct, valuable, and safe:

Unit Testing of Generated Code & Environments: Since OMNI-EPIC generates environment code on the fly, it’s crucial to verify that this code is sane and does what’s intended. We incorporate a sandbox testing step for any generated code before it affects the main simulation. For example, if the Task Generator produces Python code to create a flood scenario, that code is executed in a restricted sandbox environment and checked: does it create the right objects? Are all required parameters defined? We use static analysis and simple runtime checks to catch errors (e.g. infinite loops or unsafe operations) in generated code. Only after passing these checks is the new environment loaded into the main simulation. This prevents a bad generation from crashing the system mid-demo. Over time, the system will accumulate a library of vetted environment code snippets, increasing stability.
Success Validation & Ground-Truth Comparison: The Success Detector outcomes are cross-validated with ground-truth metrics whenever possible. For instance, if the success criterion for a task was “restore power within 1 hour,” the simulation’s ground-truth data (time when power was restored) can be directly measured and compared to the success detector’s judgement. We ensure that the success detector (whether code-based or LLM) agrees with these ground truth measurements in all test scenarios. During development, we will run a battery of known scenarios with known outcomes to fine-tune the success evaluation. In ambiguous cases (where success isn’t binary), we calibrate the evaluation to be conservative (avoid false positives of success). This guarantees that any claim of success made by the system is reliable, which is important when demonstrating to policymakers (we don’t want the system to declare victory when it actually failed some objective).
Simulation Validity & Realism Checks: Although this is a simulation, we aim for a level of realism that makes insights credible. We will validate the simulation models (traffic flow, power grid, etc.) against known real-world data or simplified theoretical models. For example, we might compare the simulated traffic jams against standard queueing theory or existing traffic simulation benchmarks to ensure the AI isn’t exploiting unrealistic physics. If the AI finds a solution, we examine if that solution could plausibly transfer to the real world. This exercise may involve domain experts in city planning reviewing some of the AI’s actions for plausibility. The idea is to avoid “simulation hacks” – e.g. if a glitch allowed the AI to reroute traffic instantaneously in a way that wouldn’t be possible with real road networks, we’d identify and fix that. Such validation increases the credibility of the demo’s outcomes.
Iterative Scenario Testing (Curriculum Validity): The open-ended nature means the system will venture into uncharted scenarios. We will systematically test increasing difficulty of tasks to see if the system correctly identifies when it cannot solve something and handles it gracefully. For instance, push the system with a scenario that is intentionally too hard (e.g. multiple simultaneous disasters) and verify that it fails safely: it should recognize failure, archive the task, perhaps generate a preparatory sub-task to improve skills (like a training scenario), rather than producing chaotic or dangerous behavior. This echoes the OMNI-EPIC approach of adjusting difficulty. We verify that the agents indeed improve over iterations – e.g. measure time to solve similar tasks after learning, which should decrease. This learning validation ensures the integration of OMNI-EPIC and Alpha-Factory is functioning (the archive is properly used to get better).
Safety & Ethical Guardrails: Given this is an autonomous system making decisions in a societal context (even if simulated), we implement safety checks:
Policy Constraints: We hard-code or learn certain rules that must not be violated. For example, the AI should never “solve” a traffic problem by causing harm (like blocking ambulances or any obviously unethical trade-off). If the Task Generator ever proposed an unethical task (say, “sacrifice one part of city to save power”), the post-filter would catch and reject it. We’ll maintain a list of forbidden actions/outcomes (no loss of human life is acceptable in any solution, etc.). During tests, we create edge cases to ensure these rules hold.
Anomaly Detection: The system will monitor its own outputs for anomalies. If an agent’s action distribution is way off (say an untrained agent thrashing), the orchestrator can intervene and reset that agent or revert to a safer policy. Similarly, if an LLM produces an out-of-character instruction (due to a prompt oddity), another agent or script can flag it. Essentially, a simple meta-agent keeps watch for anything that looks like a bug or misalignment, and can pause the simulation or fall back to predefined safe behavior.
User Override and Emergency Stop: The UI features a prominent “Pause/Stop” button that a user can hit if they see the system doing something undesirable. This immediately freezes agent actions. The user can then adjust parameters or skip the problematic task. While we strive to avoid reaching that point, having this manual override is an important safety net (and also demonstrates that humans retain control, which policymakers will appreciate).
Economic Token Validation: We will verify that the token rewards correlate with actual performance. For example, if tokens are supposed to reflect economic value saved, we ensure the token calculation matches some reasonable economic model (perhaps using known costs: e.g. cost of power outage per minute). This makes sure the token counts aren’t arbitrary. We can test scenarios with known optimal outcomes and see if those yield the maximum token reward as expected. If any agent starts gaming the token system in unintended ways (an analogue to specification gaming), we will catch that in testing and refine the token allocation rules. The token ledger is also auditable – we can trace back why an agent got tokens, ensuring transparency and correctness in the credit assignment.
Performance & Robustness Testing: The system will be stress-tested with long runs and high complexity to ensure it’s robust (antifragile) as intended. We simulate, say, 100 sequential events to see if memory or performance degrades, verifying that the archive management and scaling of difficulty do not slow the system unreasonably. Memory leaks in the environment code loading, or build-up of too many archived tasks, are monitored and optimized. We also test on different hardware (from high-end PCs to average laptops, and on different browsers) to iron out platform-specific issues. If certain platforms can’t handle full fidelity (e.g. mobile browser might struggle with 3D), we have fallbacks (like simpler visuals) and test those specifically.
User Testing & Feedback: Before finalizing, we will conduct closed demos with a few target users (including non-technical policymakers, if possible) to gather feedback. We’ll observe if they encounter confusion or if the system behaves unexpectedly from their perspective. For instance, if a user doesn’t understand why the AI did X, that indicates we need a better explanation at that moment. We treat these user tests as part of validation to ensure the explainability and UX aspects meet their goals. A successful verification here is a user being able to correctly interpret the system’s actions and trust its decisions (even if they test it by triggering unusual conditions).

By covering everything from low-level code correctness to high-level ethical alignment, this verification strategy ensures the demo is not only impressive but also reliable and trustworthy. The result is a system we can confidently showcase to policymakers and researchers as a realistic step toward safe autonomous decision-making.

Metrics of Success

We will evaluate the demo’s success on two levels: technical metrics to quantify the AI system’s performance, and policy-level impact metrics to demonstrate value in real-world terms. These metrics guide development and also communicate the system’s effectiveness to observers.

Technical Performance Metrics: These measure how well the integrated OMNI-EPIC + Alpha-Factory system functions as an AI system:
Task Completion Rate & Efficiency: What percentage of generated tasks are eventually solved successfully? And what is the average time or simulation steps taken to solve them? A high completion rate with decreasing solution time indicates the system is learning and improving.
Task Diversity & Open-Endedness: Using OMNI-EPIC’s analysis tools, we track the diversity of tasks in the archive (e.g. using an embedding space coverage metric). Success would be shown by the system continually adding novel tasks that are not mere repetitions. For instance, after 50 tasks, we might measure that they span a broad range of challenge types (natural disasters, social events, technical faults, etc.). Figure 2 (notional) could plot the variety over time, expecting an upward trend (indicating “continues to innovate throughout the run”).
Learning Curve: We measure the performance of agents on tasks that recur with variations. For example, if the system faces three different blackout scenarios over time, we expect improved metrics on each successive one. We can quantify this as, say, “Average utility downtime” reduced by X% from the first to third blackout incident. Similarly, reward per task might increase as policies get better. If using RL, we also have reward curves and loss curves to ensure training is stable.
Policy Selection Efficacy: We log cases where the orchestrator had multiple policies or agents to choose from, and whether it picked the one that performed best. Over many tasks, an effective system should show that it usually selects (or quickly switches to) the optimal strategy available. This can be measured as the regret (in terms of reward) of the initial choice vs. the best choice – ideally low.
System Autonomy & Interventions: How often does the system require user intervention to handle a scenario? If the demo is truly autonomous, it should rarely need the user to step in for correction. We track “manual overrides” or unsolvable flags. The goal is that the AI handles at least N continuous tasks without human help. A stretch target might be 95% of events handled autonomously.
Scalability & Throughput: If the system is run in accelerated mode, how many simulation days or major events can it process per real hour? Technical success includes achieving near real-time performance (or faster) so that users are not left waiting. We might set a target like processing one complex event (with full agent deliberation) in under, say, 1 minute of real time on average.
Robustness: We monitor the system for any crashes or critical errors over long runs. Success is a zero-crash, zero-deadlock operation over, e.g., 24 hours of continuous simulation. Also, metrics like memory usage remaining bounded indicate the open-ended loop isn’t accumulating debilitating baggage.
Policy-Level Impact Metrics: These translate the simulation outcomes into domain-relevant measures that demonstrate the system’s value for governance and planning:
Infrastructure Resilience Index: We define an index that aggregates how well the city maintains services in the face of stresses (could combine power uptime, traffic flow, emergency response times, etc.). We compare this index for scenarios with the AI system vs. a baseline (either a static policy or initial runs before learning). A significant improvement in this resilience index (e.g. +20%) would show the AI’s positive impact.
Economic Savings / Value Created: Using the token economy as a proxy, we estimate real-world cost savings. For instance, if one token = \$100 of value, and the system earned 50,000 tokens over a month of simulation, that’s \$5 million of savings or efficiencies created. We can break this down per sector: how much value in transportation (reduced congestion costs), how much in energy (prevented outage costs), etc. A concrete metric might be “Total economic impact of AI actions in scenario X”. A successful demo might show that in a disaster scenario, the AI’s proactive measures saved, say, 15% of the projected economic loss.
Policy Insights Generated: This is more qualitative but can be quantified by counting distinct insights or recommendations the system provides. For example, the system might output recommendations like “Installing an extra transformer in Zone 3 greatly improves resilience” or “Flexible work hours policy reduces rush-hour traffic jams by 40% in simulation.” We can count these suggestions and perhaps have experts rate their usefulness. The metric could be “Number of actionable policy recommendations identified.” Even a handful of high-quality insights in a complex simulation would be a win, showing the AI can aid policy deliberation.
Adaptation to Regulatory Changes: We test scenarios where the “rules of the game” change (e.g. a new emissions law). We measure how quickly and effectively the AI adapts to meet the new compliance. Metrics might include “time to achieve compliance” or “degree of compliance achieved.” Success is if the AI can within a short period adjust strategies to fully obey new regulations while maintaining performance elsewhere. This demonstrates regulatory foresight and flexibility.
Human Satisfaction & Trust: Through user surveys or feedback during testing, we gather qualitative metrics. For instance, a Likert scale rating from policymakers on “How much do you trust the AI’s decisions in the simulation?” or “How useful would such a system be for planning?” The target is to achieve high scores (e.g. >8/10) indicating that users felt the AI was generally sensible and beneficial. While subjective, this is important for judging the demo’s reception.
Communication Efficiency: Since the system is meant to explain itself, we could measure the complexity of explanations (maybe average grade-level of the text, or the percentage of events the user could understand without additional clarification). If the explanations are too technical, policymakers might be lost. So a metric here could be “User understanding rate” from a small test – aiming for, say, >90% of the AI’s decisions being understood by a non-technical user based on the given explanation.
Demonstration and Adoption Metrics: Beyond the simulation itself, we consider metrics of the demo’s success as a product:
Cross-Platform Functionality: Ensure the demo runs on at least 5 distinct setups (e.g. Windows PC local, Mac browser, Android tablet browser, etc.) without issues. The metric is number of platforms/environments confirmed.
Engagement Duration: If users are left to interact freely, how long do they engage? A compelling demo might have high dwell time. For example, average session length might be 30 minutes or more, indicating users find it interesting enough to explore multiple scenarios.
Reuse and Extensibility: If released to a broader community (developers or other cities), do they extend it? One metric could be if any external contributions or scenario packs are created (though this is more long-term). This would show the design is generalizable (e.g. a different city data was plugged in successfully).

By monitoring these metrics, we can quantitatively and qualitatively demonstrate that:

Technically, the system is performing robustly, learning continuously, and solving complex tasks (proving out the OMNI-EPIC + Alpha-Factory integration).
Practically, it yields improvements and insights that matter in the real world context of city management and policy (validating it as more than a toy – a decision support tool prototype).

For instance, a final report might state: “Over 100 simulated incidents, the AI improved the city’s resilience index by 25%, saved an estimated \$10M, and generated 5 concrete policy suggestions (e.g. infrastructure upgrades) that domain experts found plausible.” Achieving such outcomes would mark the demo as a success on both technical AI benchmarks and policy-relevant impact measures.

Conclusion

In designing this OMNI-Factory Smart City Resilience demo, we fused cutting-edge open-ended learning (OMNI-EPIC) with a powerful multi-agent architecture (Alpha-Factory v1) to create a living simulation that can surprise and inform us. The use case – an autonomous AI managing a virtual city – serves as a compelling microcosm for real-world complexity, showcasing how AI might continuously learn and add value in society under the right framework. We carefully crafted the system to be cross-platform, interactive, and transparent, so that a broad audience (from AI researchers to government leaders) can engage with it and envision the possibilities and challenges of such technology.

By integrating task generation, code synthesis, success detection, and archival memory from OMNI-EPIC into the agent orchestration, scoring, policy markets, and token economy of Alpha-Factory, we demonstrate a synergistic loop: the more the agents learn, the more interesting tasks they tackle; the more tasks generated, the more the agents must innovate. This open-ended “education” of the AI is visible to the user, demystifying how AI can improve over time. The system operates autonomously yet remains aligned to human-defined goals and constraints, an essential aspect for real-world adoption.

In sum, the OMNI-Factory city simulator stands as a proof-of-concept of how future AI ecosystems might operate – not as single monolithic algorithms, but as ecosystems of cooperating agents that create value and knowledge in a self-driven, endless loop. It’s a demo designed not only to impress (with its autonomous feats and adaptive complexity) but also to engage and educate (by allowing humans to interact with and understand the AI’s decisions). We believe this will resonate strongly with policymakers: they can tangibly see an embodiment of AI that is proactive, economically beneficial, and safety-conscious, giving them a window into how such technology could bolster infrastructure, economy, and governance in the real world.

Ultimately, success will be measured by the conversations and ideas this demo sparks. By presenting a clear, well-structured integration of advanced AI components addressing real societal challenges, we aim to inspire confidence that open-ended AI coupled with careful design can be a force-multiplier for human decision-making – a message delivered vividly through this interactive simulation.

View README on GitHub