Roadmap to LLM decision making in Mesa

[colinfrisch]

The idea here would be to work on a roadmap to LLM decision making in Mesa. For now, I agree that the roadmap should first focus on features that can be implemented not only for potential LLM agents but for all agents.

Here are the main ideas that I could gather until here (in addition to some contributions from myself)

From previous discussions on behavioural framewoks in mesa, the first thing would be to develop a modular framework in Mesa that “integrates theoretical behavioral models with practical agent behavior”. In a few lines, these were the ideas that @ewout suggested as features :
• State Management : tracking of agent states (discrete/continuous) and transitions
• Decision System : for decision-making mechanisms (rule-based, learning, utility) and priority management
• Action Framework : controling execution timing, resource constraints, and interruptions
• Goal System : handles dynamic short and long term priorities for agent
• Event System : responses through decoupled communication -> could be interesting to link with SimulationEvent class

My personal suggestion to this would be to add a Memory System. I have created a working prototype for one, (PR#2735) and built a foraging ants model using it as an example of how it could function if you want to take a look. The idea is to create something handy but very flexible that is used as much for LLM based agents (talking) and classic ones (communication of other elements such as positions, states, etc.)

Better details on #2538, but main takeout here is that mesa is very handy because it is simple, so it’s important to make something that the user can understand and manage without to much complications.

I think that pure reasoning and decision making are the logical next steps to finding and implementing a frame to general behaviour and perception. And now we start talking about LLMs (but if you ideas to attach this to agents without LLMs, please tell ). Here are two interesting structures that I gathered for a potential complete module. The second one looks a little like the suggestion of features previously mentioned. This could be a good start to try and define the big picture.

(from https://www.nature.com/articles/s41599-024-03611-3)

(from OpenAI/Ewout)

Purely speaking of a roadmap, I think that memory for the agents and state management (maybe merge both) are a good way to start, because they may be developped completely independantly from an LLM agent and still be very useful to agents. Goal and action systems should maybe be thought more accordingly to what we want to do with the LLM, as LLM could have needs that other agents don’t in these areas.

I’d be happy to discuss this more with you guys if you have any ideas for what there is to do technically or for the timing !

[wang-boyu]

Just a thought - a more suitable title might be something like "roadmap to behavioral frameworks in mesa", since you're trying to generailzie to all agents, not just LLM-based agents. If you're up for a gsoc project following this path, it may make more sense to apply to the behavioral framework project, not mesa-llm. I will try not to think about two ideas at the same time (especially when we don't have a concrete project for mesa-llm yet), even though there might be some connections between them.

Hopefully this will help free you from having to think about LLM vs. non-LLM agents, and focus on a more generic perspective for behavioral frameworks of agents in general.

[colinfrisch]

Thanks for your feedback @wang-boyu ! My take on this was that since we are going to need a behavioural module specific to the LLM-based Agents (at least some memory, goal and decision making building blocks), might as well make some them generalizable to all agents. Do you think it's incompatible ? Where would you draw the line ?

I have quite a bit of experience in LLM techniques and usage and a few ideas that I really like for the LLM agent project in mesa, so I will prepare a proposal for this project, but the behavioural also interests me. Do you think I can submit one proposal for each of these projects ?

[WingchunSiu]

That totally makes sense—Colin’s roadmap aims to build a general, reusable behavioral framework for all agents, LLM-based or not. I do think there’s a natural complementarity between his idea and mine. While his project focuses on defining what agents can do (e.g., memory, goals, decision logic), my top-down orchestration approach is more about how and when those behaviors get activated in a hybrid simulation, especially when LLMs are introduced as conditional reasoning modules.

[wang-boyu]

Do you think it's incompatible ? Where would you draw the line ?

I haven't really thought about generalizing any components of LLM-based agents to all agent types. While it may be feasible and beneficial to do so, I would just say that such generalization is beyond the scope of mesa-llm gsoc project.

Do you think I can submit one proposal for each of these projects ?

Yes definitely. See GSoC FAQ: https://developers.google.com/open-source/gsoc/faq#can_i_submit_more_than_one_proposal

Can I submit more than one proposal?
Yes, each GSoC Contributor may submit up to three proposals. However, only one per GSoC Contributor may be accepted. No more than one proposal per GSoC Contributor will be accepted, no matter how many proposals you submit.

In my understanding you can submit up to three proposals in total to different organizations. Only one of them can be accepted.

[sanika-n]

Hi, from what I understand the current memory system that has been proposed is agent specific, right? I was wondering if in addition to this, an environment specific system would be beneficial especially in case of simulations involving LLMs. So, this would basically store information about the environment's state (maybe a dictionary that maps the grid location to the variables relating to that location). These are some use cases that I could think of where this might come in handy:

• In disaster response& search and rescue simulations for example, all agents (fire-fighters, rescue teams, etc) will have access to locations of collapsed buildings/fire/survivor location and can update the memory once they have finished work in a particular location.
• Or maybe if we are working with models in transportation and traffic congestion, the model could possibly create a heat map
  depicting the congestion rates, and cars(agents) could have access to this data and could take a path that avoids congestions