Meta agents needs to go beyond hierarchical groups. There are several other modeling paradigms that excel at top-down approaches, such as system dynamics. Agent based models are good at bottom up.

To me the challenge is it is often both, top-down and bottom-up, making the larger question, how do we provide a module that allows for both. An agent can influence an organization and an organization can drive the behavior of agents. I think this is why the foundational theory matters, it forms the conceptual basis, and so far I constantly go back to dynamic sets of active and dormant agents (until I find a better perspective).

Does this make sense?

Thanks for the clarification!! So your main goal is top-down and bottom up that means agents can affects the orgs and orgs can affect the agents behavior i hope i am understanding it correct

@ShreyasN707 Meta-agents should behave as full first class agents and influence should be able to go both ways.

The primary goal is to explore and understand the dynamics of multi-level adaptive networks.

Does this answer your questions?

Thanks @tpike3 that clarifies the direction.

Given meta-agents are full first-class agents with bidirectional influence, how are you envisioning membership being represented internally?
Should membership live primarily inside the meta-agent (like a managed AgentSet), or should base agents also maintain references upward?

I’m asking because the choice seems tightly coupled to scheduling and performance — especially if agents can belong to multiple meta-agents and influence propagates across levels.

Curious about your thinking is on that layer.

Good questions --- in general remember Mesa's job is to provide options not solutions. How do we provide a meta-agents module that is intuitive and rigorous for users to explore their phenomenon of interest.

My thoughts are:
1 - It should be configurable, and I think can blend seamlessly with what already exists, as all meta-agent are treated as agents - https://mesa.readthedocs.io/latest/tutorials/2_agent_activation.html

2 - Yes they should be bi-directional, and as for guardrails, I am honestly not sure that is something that needs to be figured out.

3 - This should also be configurable and allow users to put in their own "conflict resolution", however I think have some out of the box options would be helpful, but I think that will go beyond the scope of this effort.

4 - I think the question is how do we provide these options and make them intutive, in that agents, meta-agents have their own logic for joining, emerging, leaving, dissolving etc.

1 - I am not sure I understand exactly what you mean by this, could you please elaborate?

2 - This is a tough one, I think it will be either a meta-agent class like it is now or there will be a couple of archetypes

3 - I don't think we need to worry about this at this juncture

4 - Great question, I think this integrates with 2. Broadly I think these are the general types and the question is do they each merit their own archetype (that can be mixed and matched in a model) or not.

1 - I am not sure I understand exactly what you mean by this, could you please elaborate?

Should Mesa define a built-in, standard way to compute a group/meta-agent's state from its member states?

• reducers/aggregators = functions like sum, mean, max, vote, custom combine logic.
• Example: if members have wealth should group wealth be sum(member.wealth) by a standard interface?
• The design question is whether this should be:
  • standardized in the API (consistent, reusable) or
  • left totally custom per model (flexible but less uniform)

@trevorgor289 -- All Mesa GSoC projects are open and in fact proposal cannot yet be submitted, proposal period opens March 16th and closes March 31st.

I would review these resources --- https://github.com/mesa/mesa/wiki/GSoC-2026-Project-Ideas

I always like to remind people the point of GSoC is not build a library for Mesa and be done. The point of GSoC is to expose contributors to open source and from the point of Mesa and GSoC, we are always looking for contributors that are interested in Mesa for the long term, not just a GSoC for their resume.

I think the hypergraph framing and the separation between a mathematically rigorous backend and a user-facing facade make a lot of sense.

One architectural question I wanted to raise is whether it would be valuable to make the backend pluggable, while keeping a single frontend/facade API.

That would mean users interact with one meta-agent interface, while the internal representation could potentially vary depending on the use case, for example:

• a backend oriented toward clarity/reference behavior,
• and a backend oriented toward performance and overlapping memberships at scale, such as the hypergraph / incidence-tensor direction you described.

My thought is that this could help separate:

• user-facing modeling concepts,
• lifecycle semantics,
• and backend-specific storage/optimization choices.

Do you see the proposed architecture as:

1. one canonical backend from the beginning, or
2. a common facade/API with room for multiple backend implementations?

I think that distinction would help a lot in shaping the GSoC proposal and scoping the implementation plan.

I see it as one canonical backend. Otherwise I think it would become to hard to manage or even for users to implement. In addition, different backend may produce different behaviors, which would cause further issues for users.

I would think more abstractly about it. The goal is from sets of active and dormant groups in a hypergraph, you can implement different groups/organizational behaviors.

Thanks @trevorgor289 that is an intriguing idea and yes the hypergraph and incidence tensor are just proposed and not implemented.

It is what you should plan to develop as part of GSoC. As for the potential I have to read the paper on not just the abstract. However, on the surface it seems sound.

But to make sure I am understanding correctly, step 1 GSoC build the tensor architecture on which meta-agents sits. step 2 to n - integrate behaviors via tensor logic functions. Potentially the functions that calls these operations would be facade functions that would be more intuitive for users to understand and employ. Is this what you are thinking or no?

Yep, that’s what I was thinking. Although, it sounds like the first focus for the GSoC project should be building the core tensor architecture itself, and then something like behaviors as tensor logic operations could be a follow up project. From what I understood in the paper, one of the recommended next steps is turning the theoretical idea into something more practical and user friendly which could fit into this project nicely. I think it could also tie into the bidirectional information exchange you mentioned.

For the proposal, I’m mostly trying to figure out what level of scope makes the most sense. Is it better to focus on one major part of the architecture, like the entire backend, or to narrow in on a smaller component? For example, should it be framed more specifically as, “this is how I plan to implement bidirectional influence between agents”? Also, is this expected to be a one person effort, or if this is something multiple people will work on?

Also, in terms of timing, is it better to submit the proposal earlier, even if it is still a little rough around the edges, or is it better to wait and make it more complete as long as it is submitted before the deadline?

The scope for this one would be on the base architecture.

GSoC projects are always one person, with the focus being contributing to opens source but the mentor and the maintainer can/do work together.

As long as it is submitted before the deadline is fine.

@falloficarus22 I think that is a very good laydown and interpretation.

@Krishsharma179 that raises some interesting questions on the user dynamic. My gut reaction is those are good generalizable categories. Only thought in addition to kwargs, how does the user specify functions the meta-agent and/or potential constituting agent uses to to assess membership.

@tpike3
Thank you for the feedback! Here is my updated thinking:

If the policy is hierarchical (join_rule="approval", leave_rule="approval"), the MetaAgent will have an assess_member(self, agent) method where the user defines the group's selection logic.

On the agent side, the user defines a wants_to_join(self, group) method the agent's own decision on whether it wants to join.

The lifecycle I have in mind:
Step 1 agent.wants_to_join(group) (does the agent want to join? If NO, stop.)
Step 2 policy check (does the agent follow the rules? If NO, stop.)
Step 3 agent added to MetaAgent
Step 4 membership recorded in the hypergraph and tensor updated

What do you think about this?

@tpike3 Hi Tom, quick design question if no Policy is provided by the user, should the MetaAgent use a default Policy (free join, free leave, multiple membership) to maintain backward compatibility, or should we raise an error? Want to make sure the architecture aligns with your vision before finalising.

I am thinking to set some default parameter for these policy like

join_rule = "free"
leave_rule = "free"
exclusivity = "multiple"

what do you think about this ????

@KpradeepKumar25 That is a lot to process, and putting it in a somewhat different approach. I think there is two things to consider, but maybe I am oversimplifying.

1 - What are the sets of agents, and meta-agents? This is captured in an incidence matrix. So instead of worrying about tracking the agent in meta-agents and vice versa, it just references the incidence matrix and adds or deletes the connection.

2 - How do users specify the dynamics? I think these fall into two categories, simple and complex. Simple is a kwarg type set up, similar to the policies mentioned in this discussion and complex is functions that do some type of calculation. So what is the easiest/ most intutive set up for the the user to specify their vision for their ABM.

I think this will then lead to the third part which has discussed throughout, which is a toolkit of common behaviors/tensor logic that users employ to rapidly build their simulations.

Hi @tpike3,

That separation into representation (incidence structure) and user-defined dynamics really clarifies the direction. It shifts the problem from state management to structural indexing, which feels much more scalable and aligned with Mesa’s design philosophy.

A few thoughts on making the user-facing layer intuitive:

Facade Primitives
Since the incidence structure is the single source of truth, exposing high-level queries like get_members(meta_agent) and get_groups(agent) would allow users to operate in ABM terms, while the backend handles tensor-level operations transparently.

Unifying Simple and Complex Dynamics
To bridge the gap between simple kwargs and user-defined functions, simple configurations (e.g., thresholds or policies) could be internally compiled into functions. This would give a consistent execution model while keeping the API accessible.

Active/Dormant Sets as Views
Treating active/dormant agents as dynamic views (or masks) over the incidence structure seems like a clean way to support both performance and flexibility, especially for large-scale simulations.

Bidirectional Influence
Given the importance of top-down and bottom-up dynamics, I’m also thinking about how these queries and views can naturally support influence propagation across levels without introducing additional tracking complexity.

I’m currently building a small prototype around this incidence-based backend + unified dynamics approach to better understand trade-offs in practice.

Does this direction align well with the intended “toolkit” vision?

Thanks!

That is a very good write up @KpradeepKumar25 and so yes it does align with the intended vision.

The intent is a complete refactor.

ok understood

So the agent doesn't necessarily have to update the meta-agent. The agent is typically taking action in his self interest, these actions may or may not influence the behavior of the meta-agent. Likewise the meta-agent is working towards an "organizational" goal, and those actions may influence how the agent acts in the next step.

There is a gray area in the middle, that becomes important. The meta-agent may be trying accomplish something, but can't rally support to do it, because its constituting agents have selected an local option that prevents the meta-agent in accomplishing its goal.

To be clear this is a very non-trivial challenge that I have never seen addressed, so it will take some iteration to get right.

@tpike3

The way I see it the bidirectional influence is handled through two layers:

Policy as the gate:
join_rule and leave_rule already control whether an agent can join/leave
User can set approval mode to prevent joins that would block the group goal

Override hooks for reactions:
on_member_join() / on_member_leave() meta-agent updates its group state
on_join() / on_leave() agent updates its own state
So the flow becomes:

agent wants to join
    ↓
Policy checks (user defined gate)
    ↓
on_join() → agent updates itself
on_member_join() → meta-agent updates group state

The user has full control at every step without us hardcoding any behavior. Does this align with what you had in mind, or is there a case this doesn't cover?

@tpike3

The way I see it the bidirectional influence is handled through two layers:

Policy as the gate: join_rule and leave_rule already control whether an agent can join/leave User can set approval mode to prevent joins that would block the group goal

Override hooks for reactions: on_member_join() / on_member_leave() meta-agent updates its group state on_join() / on_leave() agent updates its own state So the flow becomes:

agent wants to join
    ↓
Policy checks (user defined gate)
    ↓
on_join() → agent updates itself
on_member_join() → meta-agent updates group state

The user has full control at every step without us hardcoding any behavior. Does this align with what you had in mind, or is there a case this doesn't cover?

hey @tpike3
And I would like to know you point of view on the bidirectional approach I sent earlier