GSoC 2026 ideas

[EwoutH]

Let's start the discussion on 2026 GSoC ideas!

2025 ideas can be found here. Ones leftover from last year:

• Behavioral framework: This project aims to develop a unified behavior and state management system for Mesa, addressing the current limitation of simple discrete-time steps by enabling continuous state changes, time-consuming tasks, and sophisticated decision-making. By creating a comprehensive framework that integrates task priority scheduling, interruption capabilities, and behavioral theories, the initiative will allow modelers to simulate realistic agent behaviors—such as resource depletion and parallel activities—more effectively. The expected outcome is a robust API and event system that empowers users to build complex, theoretically grounded agent-based models with greater ease and flexibility.
  • Relevant discussions and groundwork include #2529, #2526, #2538, and PR #2547.
• Unifying geospatial Support in Mesa: This initiative seeks to merge the standalone mesa-geo(https://github.com/projectmesa/mesa-geo) package directly into the core Mesa library as a mesa.geo module, resolving compatibility issues arising from their separate evolution and simplifying dependency management. By leveraging Mesa's new experimental cell and continuous space architectures, the project will create a unified spatial modeling framework that supports GIS functionality, coordinate transformations, and standard file formats like GeoJSON within a consistent API. The consolidation aims to make advanced geospatial modeling a first-class feature, ensuring that property layers and spatial visualizations work seamlessly across all Mesa projects.
  • Key technical context includes the experimental cell space, continuous space implementation, and the Space conceptual model.
• Mesa Blocks: Mesa Blocks proposes the development of a low-code/no-code extension designed to help users rapidly assemble and run custom agent-based models using a visual drag-and-drop interface. Recognizing the difficulty in building complex models from scratch, this project aims to provide a system of reusable, customizable building blocks that allow users to quickly prototype valid models while retaining the ability to modify the underlying logic. The ultimate goal is to create a prototype that democratizes access to agent-based modeling, allowing for faster decision-making and model exploration through a user-friendly, modular environment.
  • Historical context and inspiration can be found in previous ecosystem attempts and Reusable Building Blocks for ABMS.

What more ideas and ambitions do we have?

[EwoutH]

We did talk about performance optimization in the past, and a Mesa performance optimization project might be interesting this year.

Mesa's scalability to millions of agents depends on efficient core operations in AgentSet, spatial grids, and event scheduling. This project could systematically identify and address performance bottlenecks across the library. The first phase involves comprehensive profiling of Mesa's example models (Boltzmann Wealth, Schelling, Wolf-Sheep, Flocking) using tools like cProfile, py-spy, and memory_profiler to create a performance baseline and identify hotspots. Likely candidates include AgentSet operations (shuffle_do, select, groupby, agg), grid neighbor lookups, and PropertyLayer modifications.

The second phase could explore optimization strategies: expanding NumPy vectorization for batch agent operations, restructuring data layouts for cache efficiency, and evaluating Rust acceleration via PyO3 for compute-intensive components like spatial indexing, large-scale shuffling, and event queue management. Rust is particularly promising for operations with clear data boundaries (grids, coordinate math) where Python object overhead can be avoided.

Deliverables could include a reproducible low-level benchmarking suite, documented performance improvements with before/after comparisons, and potentially a mesa-accel optional dependency for Rust-accelerated components. The contributor should have Python profiling experience and interest in either NumPy internals or Rust/PyO3 (though the discovery phase will determine which optimization strategies yield the best results for Mesa's specific workloads).

@Ben-geo @adamamer20 I'm also curious if there are lessons or techniques of mesa-frames transferable to the main library.

[madhavik-2005]

These project ideas look great! I'm really interested in getting involved with Mesa for GSoC 2026.
I've read through the candidate guide, and it's clear that building models first is the way to go. So that's my plan - dive into mesa-examples, build some stuff, and actually experience what works and what's frustrating. I want my proposal to come from real hands-on experience, not just theory.

The Behavioral Framework project really caught my attention. I find it fascinating how individual agents making their own decisions can lead to complex emergent behaviors in the system. What excites me most is the challenge of taking these theoretical behavioral models - things like BDI or needs-based architectures - and turning them into something practical that people can actually use. It's basically building the "brain" for agents, which is pretty cool.
My plan for the next few months:

• Work through the tutorial and build models that run into the behavioral limitations we're trying to solve
• Contribute some models to mesa-examples
• Deep dive into the discussions in Continuous States #2529, Tasks #2526, and Behavioral Framework #2538
• Learn more about behavior trees, GOAP, BDI architectures, and related concepts
• Try building a simple proof-of-concept for a Task or State management system

One question: which existing Mesa models would you recommend looking at to see how people currently work around things like time-consuming tasks, competing priorities, or continuous state changes? I'd love to understand the current pain points from real examples.

[EwoutH]

Thanks for reading up before asking questions, and then asking targeted, informed questions. That's appreciated!

Most of our models can be improved in this regard, here are some examples:

• Wolf–Sheep Predation: A classic predator–prey model where wolves and sheep move, eat, and reproduce while tracking continuous energy levels. It highlights how even simple agents require juggling multiple drives (survival, movement, reproduction) using hand-coded logic. Pain point: Multi-step actions (e.g., hunting) must be faked with per-tick rules because Mesa lacks task duration or priority management.
• Schelling Segregation: Agents evaluate local similarity and relocate when dissatisfied, producing emergent spatial patterns from threshold-based decisions. It’s a clean example of stateful decision-making driven by continuous dissatisfaction metrics. Pain point: Moves are instantaneous and there’s no concept of gradual action, making it impossible to model multi-step relocation or inertia.
• Epstein's Civil Violence: Citizens and cops interact based on grievance, risk, and legitimacy, approximating BDI-like reasoning through inline formulas. It’s a strong case of complex motivations crammed into a single step function. Pain point: The behavior architecture collapses into bulky conditional logic because Mesa offers no structure for beliefs, desires, or competing goals.
• Boids (Flocking): Agents compute steering forces (alignment, cohesion, separation) continuously, creating smooth flocking. This model stresses continuous state updates and layered behaviors in every tick. Pain point: All behaviors are blended manually each step instead of modularized, showing the need for stackable behavior components or continuous behavior nodes.
• Sugarscape: Agents consume resources, metabolize energy, move based on local gradients, and even trade in extended versions. It demonstrates rich, multi-variable needs that demand arbitration between competing goals. Pain point: All needs (food, movement, vision, trading) get stuffed into one big step method, illustrating how badly Mesa lacks goals, tasks, or behavior trees.

You can find them in https://github.com/projectmesa/mesa/tree/main/mesa/examples

So note there can be two distinct goals:

• Make existing complex behavior easier to implement
• Allow new, previously impossible, behaviour

Project can address either one of these or both.

[madhavik-2005]

This is really helpful, thanks! I'll start implementing these models and dig into the pain points. If I get stuck or have questions along the way, I'll reach out.

[pragam-m25]

Hi @EwoutH, exciting list!

Building on the "Behavioral Framework" and "Performance" ideas, I'd like to propose a distinct direction for 2026 (or potential experiments in 2025): "Generative Agents Integration" (LLM-driven Behavior).

While the Behavioral Framework (BDI/GOAP) is excellent for deterministic, rule-based complexity, there is a growing need for agents that can reason dynamically via LLMs (inspired by the "Generative Agents" architecture by Park et al.).

Idea: Create a LLMAgent class or mixin for Mesa that:

1. Orchestrates API Calls: Seamlessly connects to Local LLMs (Ollama) or APIs (Gemini/OpenAI).
2. Enforces Structured Actions: Uses the new Mesa 3.0 shuffle_do mechanism by forcing the LLM to return valid JSON actions (e.g., {"action": "move", "pos": [1,2]}).
3. Manages Context Window: Handles agent memory (summarizing past steps) so the simulation doesn't crash due to token limits.

I believe this complements the traditional Behavioral Framework by offering a "Probabilistic" alternative for scenarios where defining explicit rules is too difficult (e.g., natural language negotiation between agents or simulating social dynamics).

I've already started experimenting with this using the new Mesa 3.0 syntax and ensuring strict JSON outputs. I would love to explore this further as a potential project area.

[EwoutH]

Thanks for proposing it. You have seen https://github.com/projectmesa/mesa-llm right?

[pragam-m25]

Thanks for pointing that out!

Yes, I have explored mesa-llm. It’s a great foundation.

My proposal is essentially to modernize and expand that initiative for the Mesa 3.0 era. Specifically, I aim to:

1. Update Architecture: Refactor the integration to align with the new Mesa 3.0 standards (removing schedulers, using shuffle_do).
2. Enforce Reliability: Implement strict Structured Outputs (JSON). A common issue with basic LLM integration is "hallucinated actions"; my focus would be on robust parsing so agents don't break the simulation loop.
3. Local LLM Support: Ensure native compatibility with tools like Ollama/Llama.cpp for users who can't afford API costs (crucial for students).

I’d love to take mesa-llm from an experimental state to a core-compatible library that works out-of-the-box with the new ecosystem.

[colinfrisch]

We greatly appreciate ideas for mesa-llm if you have any !

However, I encourage you to take a deeper look at mesa-llm in person and not only through the lens of ChatGPT or other tools like this.
To answer to each of your comments :

• no scheduler is used in mesa-llm, and it's fully up to date with mesa3.0
• we already use enforced structured output as jsons
• we already provide support for local models via ollama as well as online API for bigger models

For next time, it gives better impression if it looks like you've actually seen the library once when you claim to have done it ;)

[EwoutH]

I have two more: Making clean-sheet designs of how we run models in experimental setups and how we collect data.

Mesa's current batch_run and DataCollector were designed for simpler times: single machines, modest datasets, basic parameter sweeps. As agent-based modeling research has matured, users could now be empowered by complex experimental designs, multi-node HPC environments, heterogeneous data streams, and analysis workflows that demand interoperability with the broader scientific Python ecosystem. These ideas offers an opportunity to fundamentally rethink how Mesa approaches model execution and data management for Mesa 4.0, learning from a decade of ecosystem evolution and user experience rather than incrementally patching legacy designs.

Reimagining Model Execution and Experimental setup

The fundamental problem with batch_run isn't what it does, it's what it doesn't know it needs to do. Modern ABM research could benefit from sophisticated and efficient experimental designs (Latin hypercube sampling, Sobol sequences, adaptive sampling), execution across diverse computing environments (laptops to HPC clusters to cloud), provenance tracking for reproducibility, and graceful handling of long-running or failed experiments. This project should begin by deeply understanding the problem space: What experimental workflows do Mesa users actually need? How do other ABM platforms (NetLogo's BehaviorSpace, RePast, FLAME) and general-purpose tools (EMAworkbench, SALib, hyperopt, pyDOE) approach experiment management? What can we learn from how the scientific Python ecosystem handles distributed computing (Dask, Ray, IPyParallel) and workflow orchestration?

The goal isn't to design a specific solution but to map the territory: What capabilities should Mesa provide natively versus enable through documented patterns? Where are the natural architectural boundaries between experiment specification, execution strategy, and result aggregation? How do we balance simplicity for beginners running local parameter sweeps against power users orchestrating thousands of replications across HPC resources? What standards exist for experiment metadata and provenance that Mesa should adopt? The project could start with a comprehensive requirements analysis, ecosystem survey, user research findings, and architectural principles that can guide Mesa 4.0's design. And if time allows, a (proof of concept) implementation.

• Next-gen batch runner #2321
• (and slightly related) A system for managing Model/Agent default values and ranges #2268

Rethinking Data Collection and Management

DataCollector's core limitation is that it conflates too many concerns: what data to collect, when to collect it, how to store it, and how to retrieve it for analysis. As models have grown more complex with heterogeneous agent types, spatial property layers, network dynamics, and event streams, this monolithic approach shows its age. Meanwhile, the scientific Python ecosystem has evolved powerful tools for multi-dimensional labeled arrays (Xarray), efficient columnar storage (Parquet, Zarr), high-performance analytics (Polars, DuckDB), and streaming data processing. This project should explore what a modern data architecture for ABM could look like by first understanding what problems users actually face.

The research phase should investigate: What data patterns do ABM researchers need to capture, and how do current workflows break down? What can we learn from how climate models, computational biology, and other simulation-heavy domains handle output management? Where does the impedance mismatch lie between ABM data patterns and standard scientific data formats? How do users currently bridge Mesa outputs to their analysis tools, and what friction exists? What performance characteristics matter most—collection overhead during simulation, storage efficiency, or query speed during analysis? The contributor should survey existing solutions, prototype integration patterns with ecosystem tools, and identify fundamental architectural questions: Should Mesa embrace lazy evaluation and streaming? How can we handle the "collect everything vs. collect strategically" tension? What's the right balance between flexibility and performance?

The outcome should include a clear problem taxonomy, evaluation of how existing tools address (or don't address) ABM-specific needs, user requirements gathered from community research, and architectural recommendations for Mesa 4.0. Both projects emphasize discovery over delivery: understanding the landscape, learning from successes and failures elsewhere, and establishing principled foundations rather than rushing to implementation. One we know what we need to build and which tools we have to build it, the implementation becomes relatively easy.

• The future of data collection #1944
• (and the older, previous discussion) Multi-Agent data collection #348