Avoiding God Agents: An Empirical Solution to Architecting Standalone Multi-Agent Systems with Multi-Aspect Agents

1. Introduction

In the rapidly evolving landscape of artificial intelligence and distributed computing, multi-agent systems (MASs) [3] have emerged as a cornerstone for addressing complex, dynamic problems that require coordinated intelligence across multiple entities [4,17]. These systems are increasingly deployed in domains such as simulation environments [5], real-time rendering for virtual realities, and interactive applications like robotics [6].

As the basic entity of MAS, one agent can accumulate a large number of responsibilities nowadays, which is embodied as hundreds of data items, functional interfaces and tools in one class, result in an agent becoming “a big ball of mud”, i.e., a god class [17,19], or so-called god agent [32] in the context of MAS. One of the reasons for this emergency is that the scale and complexity of business logic is increasingly growing as AI and other information technologies develop [30]. This requires agents to handle multi-aspect details that are both independent and interconnected, such as state management, decision-making and environmental interactions, etc.

The second reason is that interaction scenarios of agents become more complex. As nowadays mainstream software architectural imperatives, web-based or further cloud-based applications [8] can make agents face various external entities with different interplaying rules. Besides, as AI takes more traditional occupancies from human labors, agents shall embrace more real and random-arising scenarios [30]. They are supposed to internalize rich inter-domain knowledge to handle that. Parallel to this trend, another prevailing trend, i.e., personalization of computing resources in contemporary information technology development [9] (this trend stems mainly from specific needs for network-free environments, or people’s concerns about large commercial companies monopolizing computing resources, charging ruthlessly and collecting personal information [10]), requires computing to shift from monolithic and centralized models to distributed and user-centric paradigms. Agents tend to be god agents which contain sufficient computational resources to sustain themselves, e.g., individual needs through on-device AI [7], and hyper-personalized interfaces [9].

Thirdly, autonomy of agents is usually emphasized in related contributions [24,31]. To run themselves relatively independently in the varying environments, agents ought to possess multi-aspect infrastructure or other similar facilities, i.e., all necessary sensors to collect enough data, all necessary tools to analyze data for decision-making and all necessary interfaces to interact with outsides. Such self-containness almost means god agents in essence, especially during current time of AI flourishing.

Another non-trivial reason for emerging god agents can be observed if real time computing—very common in MAS— is involved. For example, the demands for real-time interaction and rendering in MAS necessitate pre-caching vast amounts of data in varied formats—such as spatial maps, path landmarks, historical states, or predictive models—prior to actual interactive runtime. However, it intensifies agent modeling complexity by adding even more attributes for cache management, data synchronization, and rendering optimizations, thus expanding the method count and amplifying maintenance burdens [22,23]. This caching approach typically transforms agents into data-heavy entities, complicating their design in standalone systems [24].

The proliferation of god agents leads to significant challenges in development, management and maintenance of MAS, violating principles like single responsibility and increasing the risk of bugs, poor scalability, and code bloat [20,21]. This issue is particularly prominent in large-scale simulations, since computing resources are quite limited even in contemporary environments, which exacerbates architectural complexity and hindering modularity [21]. An example of god agent is shown in Figure 1.

However, most of existing contributions hardly take this issue seriously at code level. Although software engineering principles such as modularity and separation of concerns are well established, our empirical study of representative MAS, agent platforms or frameworks (termed generally as MAS in the following text, because they are almost the same in relate to agents) shows that agent implementations in current frameworks frequently evolve into large orchestration/function hubs with increased size and complexity. This observation motivates the need for an architectural organization that systematically enforces functional decomposition instead of relying solely on developer discipline.

In very a few literatures, there is indeed a potential solution to alleviating this problem. Take AutoGen [33] as an example, it is able to distribute responsibilities in one god agent to multiple collaborating agents. Under some conditions, the number of these agents can be tens [34]. Though this practice eliminates the cost of maintaining a god agent, it brings about additional payload of planning, coordinating and executing tasks. It is notable that the solution is proposed to improve task-solving and reasoning capability of MAS from a perspective of AI, rather than reduce architectural complexity from the perspective of software engineering. To summarize, it is heavy-weighted and resource-intensive, and is not supposed to solve the problem actually and essentially (see Section 2.3 for details).

To handle god agents, this paper make the following contributions.

• It proposes an architectural pattern for implementing agents and MASs that systematically separates functional concerns into independently managed aspect entities while preserving the logical identity of agents. That is, (i) by emphasizing modularity and separation of concerns to enable seamless performance, the solution aims to achieve lower development, maintenance, and management costs. (ii) It requires no AI intervention during design time and runtime. That implies no computing resources and efforts being devoted into task decomposition, reassignment and multi-agent collaboration. (iii) Integrity of agents are preserved semantically and logically. The problem is solved at a relatively low level of abstraction without redistributing responsibilities of agents and changing relationship among agents, which reduce the cost of understanding and refactoring legacy systems.
• A software metrics-based comparative study is conduct in this paper, in which the proposed approach is compared with 17 representative MASs quantitatively. The result proves it to achieve better modularity, maintainability and overall architectural quality.

Notably, this work does not propose new software engineering principles. Instead, it investigates how well-established software design principles can be systematically incorporated into the implementation architecture of MASs. While principles such as separation of concerns and composition are widely accepted, existing MAS frameworks generally leave their application to developers, resulting in significant variations in agent implementations and, in many cases, the emergence of god-agent-like structures. The proposed architecture aims to make such decomposition an explicit architectural construct rather than an implementation convention.

This paper is structured as follows. This section introduces the issue of god agents and the contributions of this paper. Section 2 briefly reviews the works related to god classes/agents. Then the approach is described and implemented in Section 3 and Section 4. To evaluate it, a comparative study is conducted in Section 5. Section 6 describes threats to validity. In Section 7, this paper is concluded.

2. State of the Art

The architectural trajectory of multi-agent systems has consistently mirrored the broader tensions in software engineering between centralized capability and decentralized maintainability. Like a lingering ghost, “God Class” or “God Object” initially identified as a pathology in object-oriented design where a single entity centralizes excessive state and behavior, has found its equivalent in the “God Agent” or “Monolithic Agent” anti-pattern [32]. Historical research from the early 1990s through the modern LLM-driven era of 2026 reveals a persistent effort to decompose these monoliths into specialized, collaborative entities.

2.1. God Class Chronology

As a well-known anti-pattern in object-oriented systems, god classes originate from early work on design flaws [13,40] and are addressed primitively in Martin Fowler’s seminal book “Refactoring: Improving the Design of Existing Code (1999)” [26] (termed as “Blob”). The author refers it to a class that centralizes excessive responsibilities, leading to low cohesion and high coupling. Extract class refactoring is recommended as the primary technique to handle it. This involves identifying cohesive groups of fields and methods within the bloated class and moving them into new, focused classes. The original class then delegates to these new classes, often acting as a facade [35]. Mediator or Observer/Event Bus patterns can be used for decoupling interactions. These manual refactoring steps are supported by incremental strategies such as “Sprout Class” and “Wrap Method” from Michael Feathers’ Working Effectively with Legacy Code (2004) [36], which are particularly useful when dealing with untestable god classes.

As for decomposition of god classes, grouping methods and attributes by functionality is very common in refactoring practice. Theoretically, other architectural strategies such as layered decomposition, micro-services / service decomposition and domain-driven design can also break monolithic god classes into independent services by enforcing responsibility boundaries. Whereas, recent works (2019-2026) emphasize cohesion-driven decomposition, where methods are grouped based on structural and semantic similarity (e.g., LDA, embeddings), like the approaches put forward in [41,42]. Considering physical proximity and semantic locality, [44] (2024) split classes with structural adjacency, which is based on an observation that adjacent software entities often share strong semantic relationships.

Identification of candidate god classes is also concerned by academic and industrial communities. Traditionally, metric-based detection and correction is often emphasized, i.e., high lines of code, high WMC (Weighted Methods per Class) and low cohesion is regarded as features of potential god classes [43]. Recent contributions (2022–2025) have also focused on automated detection and recommendation of god class refactoring. Studies like [37] (2022) employ static analysis metrics (e.g., Tight Class Cohesion, TCC) combined with machine learning and neural source code embeddings for more accurate identification. A 2024 systematic review [38] by Kalhor et al. analyzed refactoring opportunities through anti-pattern detection, highlighting that tools and heuristics continue to evolve, with increasing emphasis on context-aware grouping of responsibilities for safer extraction. Other work [39] (2020) proposes context-based grouping algorithms to recommend which parts of a god class should be extracted together, improving the semantic quality of the resulting classes. [45] (2025) indicates that transformer models (e.g., CodeT5) can recommend refactoring actions with high accuracy.

2.2. God Agent Chronology

In the context of MAS, god agents manifest as a single processing unit that attempts to internalize all domain knowledge, tool interfaces, and decision-making logic, resulting in systems that are brittle, opaque, and resistant to modification [32]. The resolution of agent monoliths has evolved through several distinct phases: from internal behavioral clustering to organizational modeling, and finally to the micro-agent collectives of the late 2020s.

In the early works on MAS development, the adoption of agent-oriented software engineering (AOSE) seeks to treat agents as active objects, yet the tendency toward centralization persisted [46]. The methods to handle god classes mentioned in Section 2.1 are naturally utilized to deal with god agents.

Busetta et al. (1999) introduced the concept of capabilities as a fundamental unit of modularity within the Belief-Desire-Intention (BDI) architecture [47]. This mechanism provides a means to cluster beliefs, events, and plans that together implement a specific functional behavior, effectively creating a “mini-agent” within a larger agent structure [48]. It also allows the reuse of behavioral modules across different agents, thereby preventing the main agent loop from becoming a monolith of specialized logic [49].

The Gaia methodology, proposed by Wooldridge, Jennings, and Kinny (2000), shifts the focus from the internal architecture of agents to the societal structure of MAS [50]. Gaia treats a MAS as a computational organization where each agent plays one or more specific “Roles”. This methodology mandates the horizontal distribution of intelligence as uniformly as possible [32]. By conceptualizing roles as atomic constructs that cannot be further subdivided, Gaia forces developers to decompose complex system behaviors into manageable units before mapping them to agent types during the design phase [51].

Prometheus (2002) utilizes “Functionality Descriptors” to group related goals and actions into coherent chunks of behavior [52]. The methodology assesses groupings through Data Coupling Diagrams, where functionalities with low coupling are maintained as separate agent types.

Tropos (2002/2004) adopts the i* framework to model domain stakeholders as “Actors” with specific strategic interests or goals [53]. It employs Boolean decomposition (AND/OR) to break root goals into subgoals, which are then delegated to system-to-be actors. This goal-delegation process ensures that no single actor (agent) is overburdened with the entire system’s objective, providing a clear path from early requirements to code [54].

The BRAIN (Behavioral Roles for Agent INteractions) framework, developed by Cabri et al. (2003), explicitly addresses the decoupling of agent logic from interaction logic [55]. It proposes a three-level model—application, role, and environment—where coordination issues are embedded in the roles rather than the agents themselves. Using interaction infrastructures like RoleX, Java-based agents can modify their bytecode at runtime to assume roles, allowing an agent to evolve its behavior without increasing its core complexity.

R-CAST (Collaborative Agents for Simulating Teamwork), proposed by Yen and Fan (2006), uses computational representations of Recognition-Primed Decision (RPD) models to manage complexity in decision-making teams [56]. The architecture is component-based and reconfigurable, allowing for the creation of specialized “Decision Maker Agents” (DMA) and “Supporter Agents” [57]. By modeling the information requirements as “Relevant Cues” and “Expectancies,” R-CAST agents can effectively share subsets of the total decision space, reducing the cognitive load on any individual participant [58].

The Agents and Artifacts (A&A) meta-model, realized through frameworks like CArtAgO (Common Artifact Infrastructure for Agents Open source, 2011), introduced a fundamental shift by treating the environment as a first-class, programmable entity [59]. Agents focus solely on proactive goal-achievement, interacting with artifacts via simple operations and perceiving changes through signals, thereby maintaining a lean internal state regardless of system-wide complexity [49].

The emergence of Generative AI and LLM-based agents has reintroduced the god class problem in the form of the “God Prompt” or “God Agent” anti-pattern. By 2026, the industry has largely converged on the conclusion that the single-agent monolith is non-viable for production environments due to systemic failures in long-horizon tasks [60]. A god agent typically attempts to load 20+ tool descriptions, consuming 3,000–5,000 tokens before processing a single user request, which dilutes attention and leads to “tool confusion” [60].

By applying micro-services principles to AI agents, god agents problem can be solved partly [46]. The “Supervisor” or “Orchestrator-Worker” pattern decomposes a monolithic agent into a fleet of “Experts”. M-ASK (Multi-Agent Search and Knowledge) explicitly decouples agentic search into “Search Behavior Agents” (planning and tool use) and “Knowledge Management Agents” (state stabilization and filtering) [61]. Micro-Agent Collective Architecture (MACA) organizes large populations of lightweight, often stateless agents that coordinate through decentralized message brokers like Kafka [62].

Ideally, standardized protocols (Model Context Protocol, MCP [63] and Agent-to-Agent, A2A [64]) are expected to transition MAS from a collection of one-off integrations to a composed, governed platform. This evolution ensures that even as the scale of tasks increases, the complexity remains bounded within specialized, testable, and auditable units, through systemic, protocol-driven decentralization.

2.3 Challenges and Limitations

From structural knowledge distribution to modern LLM-based agent orchestration, a crucial observation can be obtained from the above mentioned chronological evolution of strategies used to avoid or eliminate god agents. That is, solving the god agent/class problem is fundamentally about redistributing responsibilities. Though modern research extends this with automation and AI, but the core principle remains unchanged. High cohesion and low coupling [14] is still the most reliable foundation for eliminating god agents.

However, generally, some problems found during remediating god classes still remain unsolved until this days, e.g., disagreements on what exactly constitutes a god class [65], what defines over-decomposition that may increase structural complexity and undermine performance. Besides these open problems, empirical studies show that while god class refactoring generally improves maintainability, careless application can sometimes introduce new issues, e.g., overall coupling increases if dependencies are not carefully managed, and misuse of patterns may still lead to god classes [66].

Moreover, there are few MAS-related works focusing on the issue by now. For instances, Microsoft put forward a reference architecture for MAS, which addresses AI, agent orchestration, knowledge base, data persistence comprehensively [12]. [16] focuses on predictive capabilities of winter road maintenance based on an evolvable MAS. The similar contributions can be found in [1,2,15]. It is note that none of them care about the risk.

From a theoretical viewpoint, most of MAS related contributions keen on borrowing terms and concepts from psychology, sociology, and biomimetics to enhance the simulation of real systems in the physical world, e.g., “roles” in Gaia [51], “goal” in Tropos [53], “belief” “desire” “intention” in Jadex [47]. The mechanisms based on the conception like “role-playing” [68] “goal delegation” [53] “decision refinement” [57] can hardly give any help to de-monolithization from an engineering perspective. After all, they are not built for that purpose.

From a practical viewpoint, breaking down a candidate god agent into a group of collaborative agents seems the only potential means to handle the situation. As implied by MCP [63] and AutoGen [33], with the assistance of LLMs which can “figure things out” from natural language, abovementioned decomposition and cooperation among agents become “easy” to some extent. Actually, developers often discard established architectural discipline, e.g., expecting a single prompt with 500+ lines of instructions to reliably manage complex workflows [60]. Moreover, de-monolithization often introduces new categories of failure during decomposition of god classes / long tasks. For example, the collaborative agents may agree on a wrong conclusion if the first few agents commit to it [60]. As the number of agents grows, the system must handle immense flows of internal communication. Production telemetry shows that coordination latency increases non-linearly with agent count, with each handoff adding overhead for serialization and state synchronization [69]. Empirical evidence from Liu et al. (2023) shows that LLM accuracy at retrieving information from the middle of a context window can drop to 55% during the agent reasoning [70]. Latency can accumulate significantly during handoffs (production telemetry shows coordination latency increasing from 200ms with 5 agents to 2 seconds with 50 agents [60]). Agents lose the guiding context of the original objective if the sub-tasks carried on by them are too atomic or states are not shared among agents [67] (under such condition, tasks are accomplished perfectly but the result is irrelevant to the overall goal). Consequently, the approach of breaking a god agent into multi-agent orchestration is basically regarded to be error-prone, resource-consuming and heavy-weighted, not suitable for tackling the problem.

From an industrial viewpoint, source code of many MASs, such as Jason, SPADE, MASON, Mesa, GAMA Platform, MetaGPT, CrewAI, ignores possible code bloat when describing agent. Many of them merely depict an agent/role as a class, and provide no structural facilities to decompose overwhelmingly long business logic. They just leave the problems to developers who use them, leading to, in many cases, the emergence of god-agent-like structures. What makes it worse is that, in some MASs that are more industrialized like Red Alert and Spring RTS Engine, agents (units) are basically god agents/classes for themselves. It can be observed that many above academic achievements have not been applied on real software products.

3. Approach

3.1 General Description

In this paper, a MAS $\mathrm{S}\mathrm{y}\mathrm{s}$ is assumed as an enumerable set of agents ${\mathrm{a}\mathrm{g}}_{\mathrm{i}}$, i.e., $\mathrm{S}\mathrm{y}\mathrm{s}=\left\{{\mathrm{a}\mathrm{g}}_{\mathrm{i}}|\mathrm{i}=\mathrm{1,2},3,\dots ,\mathrm{n}\right\}$. An agent ${\mathrm{a}\mathrm{g}}_{\mathrm{i}}$ is defined as an enumerable set of members ${\mathrm{h}}_{\mathrm{i},\mathrm{r}}$, i.e., ${\mathrm{a}\mathrm{g}}_{\mathrm{i}}=\left\{{\mathrm{h}}_{\mathrm{i},\mathrm{r}}|\mathrm{r}=\mathrm{1,2},3,\dots ,\mathrm{m}\right\}.$ Define predicate $\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}\mathrm{o}\mathrm{f}\left(\mathrm{s}\right)$ to get cardinal of a set. Define Boolean function $\mathrm{e}\mathrm{q}({\mathrm{h}}_{\mathrm{a}},{\mathrm{h}}_{\mathrm{b}})$, $\mathrm{e}\mathrm{q}\left({\mathrm{h}}_{\mathrm{a}},{\mathrm{h}}_{\mathrm{b}}\right)=\mathrm{t}\mathrm{r}\mathrm{u}\mathrm{e}$ if ${\mathrm{h}}_{\mathrm{a}},{\mathrm{h}}_{\mathrm{b}}$ is the identical member.

Supposing two sets of members ${\mathrm{H}}_{\mathrm{a}}$ and ${\mathrm{H}}_{\mathrm{b}}$, ${\mathrm{H}}_{\mathrm{a}}={\mathrm{H}}_{\mathrm{b}}$ if $\forall \mathrm{h}\in {\mathrm{H}}_{\mathrm{a}},\exists {\mathrm{h}}^{\mathrm{\text{'}}}\in {\mathrm{H}}_{\mathrm{b}},\mathrm{e}\mathrm{q}\left(\mathrm{h},{\mathrm{h}}^{\mathrm{\text{'}}}\right)=\mathrm{t}\mathrm{r}\mathrm{u}\mathrm{e}$ and vice versa. Then we say ${\mathrm{H}}_{\mathrm{a}}$ and ${\mathrm{H}}_{\mathrm{b}}$ is of the same type. Define predicate $\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left(\mathrm{a}\mathrm{g}\right)$, which obtains type of a member set. We have ${\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{a}}={\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{b}}$ for the above situation, in which ${\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{a}}={\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{H}}_{\mathrm{a}}\right),\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{b}}=\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{H}}_{\mathrm{b}}\right)$.

Define predicate $\mathrm{a}\mathrm{s}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{o}\mathrm{f}\left(\mathrm{a}\mathrm{g}\right)$, which obtains aspects of an agent, $\left\{{\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}|\mathrm{j}=\mathrm{1,2},3,\dots ,{\mathrm{c}}_{\mathrm{i}}\right\}=\mathrm{a}\mathrm{s}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{i}}\right)$. An aspect ${\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}$ is a subset of an agent ${\mathrm{a}\mathrm{g}}_{\mathrm{i}}$, i.e., ${\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}\subseteq {\mathrm{a}\mathrm{g}}_{\mathrm{i}}$. Aspects of an agent ${\mathrm{a}\mathrm{g}}_{\mathrm{i}}$ are orthogonal, i.e., ${\bigcup }_{\mathrm{j}=1}^{{\mathrm{c}}_{\mathrm{i}}}{\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}=\mathrm{\varnothing },{\bigcap }_{\mathrm{j}=1}^{{\mathrm{c}}_{\mathrm{i}}}{\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}={\mathrm{a}\mathrm{g}}_{\mathrm{i}}$. Generally, $\forall {\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{a}},{\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{b}}\in \mathrm{a}\mathrm{s}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{i}}\right),\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{a}}\right)\ne \mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{b}}\right)$, if $\mathrm{a}\ne \mathrm{b}$.

Then we can define an enumerable set ${\mathrm{T}}_{\mathrm{a}\mathrm{g}}=\left\{{\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{k}}|{\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{k}}=\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{i}}\right),\mathrm{i}=\mathrm{1,2},3,\dots ,\mathrm{n}\right\}$. Let $\mathrm{t}=\mathrm{c}\mathrm{a}\mathrm{r}\mathrm{d}\mathrm{o}\mathrm{f}\left({\mathrm{T}}_{\mathrm{a}\mathrm{g}}\right)$, then $\mathrm{t}\le \mathrm{n}$, and $\forall {\mathrm{a}\mathrm{g}}_{\mathrm{i}}\in \mathrm{S}\mathrm{y}\mathrm{s},\exists {\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{k}}\in {\mathrm{T}}_{\mathrm{a}\mathrm{g}},{\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{k}}=\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{i}}\right)$. It is notable that for two agents ${\mathrm{a}\mathrm{g}}_{\mathrm{a}}$ and ${\mathrm{a}\mathrm{g}}_{\mathrm{b}}$, $\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{a}}\right)=\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{b}}\right)$, if $\forall {\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{a},\mathrm{j}}\in \mathrm{a}\mathrm{s}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{a}}\right),\exists {\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{b},\mathrm{p}}\in \mathrm{a}\mathrm{s}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{b}}\right),\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{a},\mathrm{j}}\right)=\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{b},\mathrm{p}}\right)$ and vice versa.

We can also define an enumerable set ${\mathrm{T}}_{\mathrm{a}\mathrm{s}\mathrm{p}}=\left\{{\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{k}}|{\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{k}}=\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}\right),{\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}\in \mathrm{a}\mathrm{s}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{i}}\right),\mathrm{i}=\mathrm{1,2},3,\dots ,\mathrm{n}\right\}$, which is a collection of all aspects in all agents in $\mathrm{S}\mathrm{y}\mathrm{s}$.

For a type ${\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{k}}\in {\mathrm{T}}_{\mathrm{a}\mathrm{s}\mathrm{p}}$, define a set ${\mathrm{P}\mathrm{o}\mathrm{o}\mathrm{l}}_{\mathrm{k}}=\left\{{\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}|\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}\right)={\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{k}},{\mathrm{a}\mathrm{s}\mathrm{p}}_{\mathrm{i},\mathrm{j}}\in \mathrm{a}\mathrm{s}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{o}\mathrm{f}\left({\mathrm{a}\mathrm{g}}_{\mathrm{i}}\right),\mathrm{i}\in \{\mathrm{1,2},3,\dots ,\mathrm{n}\}\right\}$, which is a collection of all aspects of the type ${\mathrm{t}\mathrm{y}\mathrm{p}\mathrm{e}}_{\mathrm{k}}$, which are contained in any (not necessarily all) of agents in $\mathrm{S}\mathrm{y}\mathrm{s}$.

It is obvious that if there is only one type of agents in $\mathrm{S}\mathrm{y}\mathrm{s}$, the types of aspects of any two agents are the same, as depicted in Theorem 0.

Theorem 0: $\forall {ag}_i\in Sys$, $T_{asp}=\left\{{type}_k|{type}_k=typeof\left({asp}_{i,j}\right),{asp}_{i,j}\in aspectof\left({ag}_i\right)\right\}$, if$cardof\left(T_{ag}\right)=1$.

Some basic functions of Sys are defined as follows

3.2. Reference Architecture

As indicated in above formalization, an aspect of the agent is usually related to one part of concerns, e.g., business logic, internal state management, interaction with outsides, which is relatively focused and semantically independent. That is, there is no overlap between any two of aspect entities of one agent.

From object-oriented view, an agent is associated with multiply aspect entities. An aspect entity is a first-class runtime architectural element that reifies one or more aspects which are semantically related to each other. Unlike functional domains [26], which partition system functionality serving as design-time logical decomposition, an aspect entity has an independent lifecycle, awareness of its own affiliation during runtime, and is dynamically managed by Scions (see Figure 3 below), collectively implementing a single agent while preserving it as the primary semantic unit exposed to the rest of the system. Notably, each aspect entity is unique as in relate to its agent. There are no same aspect entities in one agent, i.e., they are of different types, as indicated in Section 3.1.

In Figure 2, a reference model of MAS is given. For example, there are three types of agents, i.e., Agent A, Agent B, Agent C. A type of agent means distinct aggregation of aspect entities, which represents different responsibilities. Each type of aspect entities (e.g., Aspect Pool I) is associated with an aspect pool, which manages and maintains instances of the former. All types of agents are pooled in a singleton of agent pool. Agent types usually provide a framework for organizing and referring to their aspect entities, instead of executing business logic, which is the job of the corresponding aspect entities.

Figure 3 show the reference model at component level. A MAS is supposed to consists of one Rootstock and N Scions. As the lowest layer in the architectural hierarchy, rootstock is utilized to run the entire system and serve as infrastructure to support Scions planted on it. It contains the main program entry, facade, numerous Scion Interfaces, agent bus, agent pool and root loop.

Facade serves as interface tackling all interactions between MAS and human users or other systems. It can be built upon script interpreters, in order to have sufficient flexibility to satisfy various requests from outside.

Agent bus is a facility used to establish the inter-communication of aspect entities by providing quick indexing and searching functionality. Each aspect entity can query and retrieve the associated agent from agent bus to directly interact with other aspect entities, as depicted in agent retrieval of Section 3.1. Agent bus can also request agent pool to add or remove agents and the corresponding aspect pools to add or remove aspect entities, in order to synchronize the lifecycles of an agent and its aspect entities (i.e., agent addition and removal in Section 3.1).

As the driver of the whole system, root loop is the main loop of the whole system, responsible for constantly handling input from facade, polling each agent (as well as their aspect entities) to push forward its tasks (e.g., by invoking their callback functions through Scion interface), and thus push the entire system to step in.

Scions are literally plug-ins that implement pre-designed interfaces provided in Rootstock. In the context, each agent in the system refers to numerous aspect entities. Each aspect entity is settled in one Scion. Each Scion should manage corresponding aspect entities in pools or other similar counterpart. It means that Scion is able to add, remove, index and modify aspect entities in an efficient way through its pools. When an agent is added or removed from the system, its Aspect Entities are added into or removed from Scions synchronically, as depicted in agent addition and removal of Section 3.1.

Figure 2. Reference Model of MAS.

Figure 2. Reference Model of MAS.

Figure 3. Reference Component Model of MAS. Notably, such connection among Scions is not necessarily designed this way. See “Scion Connection” in the next section for detailed explanation.

Figure 3. Reference Component Model of MAS. Notably, such connection among Scions is not necessarily designed this way. See “Scion Connection” in the next section for detailed explanation.

3.3. Remarks

Core Concepts. First of all, it is emphasized that the reference models above are just meant to convey an idea, i.e., distributing responsibilities of a god agent to a pile of “pieces” that can be managed separately. Strictly speaking, these aspect entities are still the original “god” agent as a whole at semantic level. But this approach satisfies the principle of separation of concerns at code level, efficiently reducing complexity of MAS and decreasing the cost of development and maintenance.

Agent Decomposition. In the context of the reference models, developers can decompose a god agent via utilizing any of traditional or modern AI-assisted refactoring methods [25], as listed in Section 2.1. It is recommended to break down a monolith into 3-5 aspect entities. Too many aspect entities can make queries on agents and interactions among aspect entities more burdensome, which could undermine the performance, especially in real-time circumstances. Too few aspect entities may mean that the decomposition does not achieve the expected effect, i.e., some of aspect entities may still be god classes.

Aspect Implementation. Additionally, what should be notable is that an aspect entity is not necessarily implemented as an OO class. Numerous aspect entities in a single agent are not necessarily homogeneous, either. An aspect entity can be implemented in any form, i.e., one or more interconnected classes, one or more interlinked code blocks, or even one or more subsystems, as long as that form can appropriately represents the corresponding aspects of an individual agent while preserving its identity.

Scion Connection. There is also no rigorous specification for assembly of Scions. In detail, how a Scion reify aspect pool and its containing aspect entities is up to requirements and/or designer’s preferences, as long as that implementation can satisfy needs when agents are running.

Interface of Scions is designed according to the requirements that MAS must satisfies and how Scions connect each other. How Scions connect each other partly depend upon relationship between agents and aspect entities. Take an example of that shown in Figure 3. Aspect Entity I is only associated with Agent A, and therefore their instances can be settled in one Scion (Scion I), as shown in Figure 3. Aspect Entity II is both required by Agent A and Agent B. So it is natural to use an independent Scion (Scion II) to sustain its instances. All Scions that describe agent classes are planted on Rootstock, which collects and enumerates agent instances to facilitate interaction among them. To summarize, Scions that sustain aspect entities “shared” by different types of agents (e.g., Scion II) should be depended by Scions that specify those types of agents (e.g., Scion I, Scion III, Scion IV). Meanwhile, the interfaces for different Scions are not necessarily within a consist form, unlike WebSocket [27]. Through appropriate interface design, Scions can be placed on the rootstock in parallel or in series, or in a hybrid way (as shown in Figure 3).

Comparison with Micro-service Architecture. Someone may think the reference model is kind of similar to micro-service architecture [46]. Unlike architectural styles such as micro-services or service-oriented architectures, the proposed architecture does not partition the software system into independently deployable services; instead, it partitions the functionality of a single agent into independently managed runtime entities while preserving the agent as the semantic abstraction exposed to the rest of the system. Neither aspect entities, agents nor Scions can be regarded as independently deployable services. They do not provide independently deployable services either. They have states and limited lifecycles, while services typically persist for an extended period during system operation. Aspect entities and agents have states and limited lifecycles, while services are typically stateless and persist for an extended period during system operation. Scions are used mainly to manage aspect entities, rather than to provide services that can be consumed by other components.

Extension. Theoretically, concepts from existing contributions, e.g., belief [47], goal [53], can be reified on the basis of the reference model of MAS without any conflicts, because the proposed approach stands at a relatively low abstract level. This paper concerns more about the issue originated from software engineering than how to mimic real social-like beings.

Theorem 0 MAS. At the last but not the least, a special case should be discussed. According to Theorem 0, if agents in a MAS are of one type, it implies that all of them are homogeneous, i.e., they have the same collection (types) of aspect entities. The whole architecture of such MAS is shown in Figure 4.

In the context, each agent in the system refers to N aspect entities. Each aspect entity is settled in one Scion. For one agent i, its aspect entity AE_x,i are maintained in Scion x, x=1,2,…,N. All AE_x,i are linked to agent i through agent bus. This assumption can extensively simplify system design and agent management. Therefore, it is suggested not to design heterogeneous agents in a MAS if possible.

4. Implementation

Actually, the above architecture is abstracted from the real time strategy (RTS) game engine GUSU (euphony of Chinese word 谷诩) by stripping away a huge amount of technical details. GUSU is built from very scratch in C++ by myself without any third part components except for Windows API and LUA interceptor, in order to minimize copyright disputes. It serves as foundation for my commercial RTS game which is still under development. Architecture of GUSU is supposed to effectively organize and distribute information about agents to avoid excessive complexity. This section is only about the overall architecture of GUSU. More technical details about GUSU can be found in supplement materials.

As a Theorem 0 MAS, an agent in GUSU can be functionally considered and designed in three groups of aspects, i.e., collision detection and path planning, advanced game logic and AI, rendering and interaction. These aspects are related to each other but embody different attributes and behaviors in pro-active or other similar way. There are so many attributes in one single agent that hundreds of them can be identified in a total, like the case shown in Figure 1.

As for the implementation, for instance, the aspect entity of rendering in an agent in GUSU is implemented as a composite of 5+ classes, i.e., Rotatable, Moveable, Selectable, Animatable, Soundable etc., respectively handling visual feedback as the agent rotating, moving, being selecting by human users, performing animation and making sounds when above happens.

GUSU has three Scions named Collision Detection & Path Planning Layer, AI & Game Logic Layer and Media & Input Layer, which are planted on a command-line based Rootstock called Premier Plus, as shown in Figure 5.

Collision Detection & Path Planning Layer is responsible for navigating agents after assigning destinations (or moving missions), as well as checking collisions while thousands of agents moving in a plane. These are the most fundamental capabilities of RTS game engine. Meanwhile, this Scion manages one aspect entity of each agent (shown in Figure 5), named Bound Volume (bounding volume, see Appendix Figure B.2 for details), which is also the term from game design area [28] used to represent the regular graphics bounding the agent.

AI & Game Logic Layer describes agents’ advanced behaviors (e.g., patrol, transform, etc.), mechanism of agent interaction (e.g., two hostile agents will attack each other when they enter each other’s range until one of them leaves or is destroyed), as well as tactical AI defining agent’s spontaneous behaviors (e.g., an agent sets the direction to plan the escape route, when it is attacked and cannot fight back) and strategic AI indicating one party of agents’ coordination to achieve a certain goal (e.g., a group of agents cooperate to eliminate hostile agents in a certain area to seize resources). This Scion also manages one Aspect Entity of each agent, named Element, including 75+ attributes and related methods to support aforementioned behaviors.

Media & Input Layer describes HCI of GUSU, or exactly the interaction between human users (players and developers) and the system. It defines GUI to give real time visual and acoustic feedback to users after the latter operate. Each agent has pre-designed image, animation and sound resources to exhibit itself. The corresponding Aspect Entity named Actor is managed by this Scion, which plan all agent renderings and environment (terrains) renderings.

As Rootstock, Premier Plus drives the system like a car engine. To achieve this, Root Loop named Loop Driver is embedded in it. Actually, this module has two loops in a series, i.e., message process loop which is very common in Windows applications, along with agent polling which processes each active agent’s status and decides its next move. During the loop, it can invoke game logic API and rendering API respectively offered by AI & Game Logic Layer and Rendering Layer. Premier Plus is also empowered with multi-level instruction system to assign missions to agents and obtain their status, on the basis of Windows Shell API and LUA interpreter.

As for agent bus, it is taken over by Collision Detection & Path Planning Layer. This Scion maintains a pool for agents and provide quick search service to other Scions to facilitate data exchange among aspect entities of one agent (e.g., Element of one agent needs to be aware of its own location of Bound Volume when it is assigned a mission of attacking enemies). Premier Plus can also receive commands or LUA scripts from developers through Command Line Console, as shown in Figure 6.

Premier Plus and its three Scions are virtually connected in the hybrid way mentioned in Section 3.3. That is, Collision Detection & Path Planning Layer is planted in Premier Plus, while AI & Game Logic Layer and Media & Input Layer are connected with Collision Detection & Path Planning Layer. All such connection is embodied essentially through publish-subscribe design pattern [29]. For instance, Premier Plus defines numerous callback functions which are supposed to be invoked in agent polling and to be implemented in Collision Detection & Path Planning Layer. Such interface design ensures that the entire system has a certain degree of scalability.

Two suites are designed for real-time rendering. One is build-in GDI (Graphics Design Interface) Render Engine used as default “Scion” in Collision Detection & Path Planning Layer if the Scion for rendering is not assigned (that is the case that developers may want a clear view on the entire system to facilitate debugging). Another is Media & Input Layer mentioned above. The two can replace each other if needed. The snapshot of GDI suite are shown in Figure 6 (i.e., the window below the command line console). The snapshot of Media & Input Layer is shown in Figure 7.

5. Evaluation

5.1. Experiment Settings

To demonstrate the novelty of the proposed approach, GUSU is compared with 17 representative open source MASs from four categories: (1) traditional MAS frameworks and agent-based modeling/simulation platforms, (2) RTS game engine/AI systems, (3) multi-agent reinforcement learning (MARL) frameworks, and (4) LLM-based multi-agent systems. These systems cover a broad spectrum ranging from academic research prototypes to industrial frameworks, from traditional MAS technologies to emerging LLM-based agent systems, from theoretical platforms to practical applications, from small scale (20K LOC) to large scale (400K LOC). The diversity of the selected systems is intended to minimizes evaluation bias by ensuring both the fairness and comprehensiveness of the evaluation. Table 1 lists all MASs.

To further minimize evaluation bias arising from differences in project objectives, implementation styles and application domains, and to faithfully capture the architectural characteristics related to the god agent problem, the evaluation was conducted directly on the source code of each system rather than on the architectural descriptions or claims presented in their documentation or promotional materials. For each project, only the implementation written in its primary programming language was analyzed. Source code associated with user documentation, test cases, internal development tools, examples, benchmarks, third-party libraries and external dependencies was excluded to ensure that the analysis focused solely on the core architecture (i.e., agent implementation) of each MAS.

To quantitatively evaluate and compare the software architecture of the selected MASs, 12 software metrics are adopted and grouped into four categories: coupling (afferent coupling (Ca) [11], efferent coupling (Ce) [11] and instability (I) [11]), cohesion (lack of cohesion of methods v3 (LCOM3) [71], tight class cohesion (TCC) [72] and loose class cohesion (LCC) [72]), complexity (cyclomatic complexity (CC) [73] and depth of inheritance tree (DIT) [74]), and size (class length (CLOC), number of attributes/fields (NOF), number of methods (NOM), and method/function length (MLOC)). To provide a comprehensive evaluation, these metrics are collected at two levels. The first level, overall evaluation, characterizes the overall architectural properties of each MAS by analyzing all classes in the project. The second level, agent evaluation, focuses specifically on the classes that directly represent agents (as mentioned in Table 1 “Agent Implementation”), allowing a quantitative comparison of agent design characteristics, particularly those related to the god agent problem. All measurements are conducted using tools like CppDepend or Python scripts. Data collection and visualization is performed using Matlab. For specific experimental procedures, please refer to the supplementary materials.

5.2. Overall Evaluation

Figure 8 presents a quantitative comparison of 12 software architecture metrics for 18 representative MASs. Each bar corresponds to the average value of a metric over all classes in a system, and the highlighted bar represents GUSU.

The results show that GUSU consistently adopts a finer-grained architectural design than most existing MASs. In particular, it achieves one of the smallest average class sizes, the shortest average method length, and a shallow inheritance hierarchy while maintaining competitive cohesion and moderate coupling. These observations suggest that GUSU effectively improves modularity and maintainability without introducing excessive structural complexity.

To more clearly demonstrate the distinction between GUSU and other MAS, Principal Component Analysis (PCA) [75] is conducted on above data. In detail, for a specific metric ${\mathrm{m}}_{\mathrm{i},\mathrm{j}}(\mathrm{i}=\mathrm{1,2},\dots ,12,\mathrm{j}=\mathrm{1,2},\dots ,18)$ of all classes in one of 18 MASs, min-max normalization is used to eliminate the influence of dimensions and orders of magnitude. Since the objective of this study is to compare architectural characteristics across different multi-agent systems, min–max normalization was performed using the global minimum and maximum values (${\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}}$ and ${\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{a}\mathrm{x}}$) of each metric calculated from all classes of all evaluated MASs. Metrics which are negative indicators (lower values indicate better software quality, e.g., CC and CLOC) are inversely transformed so that larger normalized values consistently represent better architectural quality. In this context, all of the metrics are seen as negative indicators except TCC and LCC. This global normalization preserves inter-system differences and ensures that all MASs are projected into a common feature space before principal component analysis.

$${\mathrm{m}}_{\mathrm{i},\mathrm{j}}=\left\{\begin{array}{c}{\displaystyle \frac{{\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{v}\mathrm{g}}-{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}}}{{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{a}\mathrm{x}}-{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}}}},{\mathrm{m}}_{\mathrm{i},\mathrm{j}}\mathrm{i}\mathrm{s}\mathrm{p}\mathrm{o}\mathrm{s}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{v}\mathrm{e}\mathrm{i}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{t}\mathrm{o}\mathrm{r}\\ {\displaystyle \frac{{{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{a}\mathrm{x}}-\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{v}\mathrm{g}}}{{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{a}\mathrm{x}}-{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}}}},{\mathrm{m}}_{\mathrm{i},\mathrm{j}}\mathrm{i}\mathrm{s}\mathrm{n}\mathrm{e}\mathrm{g}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{v}\mathrm{e}\mathrm{i}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{t}\mathrm{o}\mathrm{r}\end{array}\right.$$

In which ${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{v}\mathrm{g}}$ means average value of i-th metric of j-th MAS. Then we can have a 12×18 matrix for PCA. The result is listed in Table 2.

Figure 9 presents the PCA biplot of the evaluated MASs using the first two principal components, which together explain approximately 78.96% of the total variance. Red points denote the evaluated MASs, the green star represents GUSU, and blue vectors indicate the loadings of the software metrics.

PC1 reflects the trade-off between class cohesion and implementation complexity. Systems with higher PC1 scores tend to exhibit stronger cohesion, whereas lower PC1 scores are generally associated with larger and more complex class implementations. PC2 mainly captures differences in inheritance structure and cohesion-related characteristics.

The loading vectors reveal that LCC and TCC are strongly aligned with the positive direction of PC1, indicating that the first principal component is primarily associated with class cohesion. In contrast, DIT, CC, NOM, CLOC, and MLOC are mainly oriented toward the negative direction of PC1 or the positive direction of PC2, suggesting that these metrics characterize larger and more structurally complex implementations. LCOM is primarily associated with the negative direction of PC2, whereas Instability contributes mainly to the lower-right quadrant.

Compared with other MASs that are widely scattered across the principal component space, GUSU is the second closest system to the origin (inferior to Camel-AI), but slightly toward the negative direction of PC1. Since the origin represents the centroid of the transformed feature space, this result suggests that GUSU maintains a well-balanced architectural profile without exhibiting extreme characteristics in coupling, cohesion, complexity, inheritance, or implementation size. Rather than optimizing a single software quality attribute at the expense of others, GUSU achieves a relatively balanced trade-off among multiple architectural dimensions.

5.3. Agent Evaluation

For agent evaluation, the i-th metric of agent classes in j-th MAS ${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}$ is taken to compare. If there is only one class representing agent, e.g., the case of CrewAI, it is put into the ring. If there are multiple classes involved, e.g., separate classes for different scenarios in MASON, the inheritance hierarchy of AutoGen, or the aspect entities of GUSU, the weighted sum of the measures of those is taken (see Agent Identification in Section 6.1 for details). ${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}$ is computed as follows.

$${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}={\displaystyle \sum _{\mathrm{k}=1}^{\mathrm{N}}}{\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{k}}{\mathrm{c}}_{\mathrm{j},\mathrm{k}}/{\displaystyle \sum _{\mathrm{k}=1}^{\mathrm{N}}}{\mathrm{c}}_{\mathrm{j},\mathrm{k}}$$

In which ${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{k}}$ denotes i-th metric of k-th of N agent classes in j-th MAS, and ${\mathrm{c}}_{\mathrm{j},\mathrm{k}}$ represents CLOC of k-th of N agent classes in j-th MAS. If there is no explicit implementation for agents, the substitutes are leveraged.

To guarantee a fair comparison, min-max normalization is used. ${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}\mathrm{\text{'}}=({\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}-{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}})/({\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{a}\mathrm{x}}-{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}})$, in which ${\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}}$ and ${\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{a}\mathrm{x}}$ denotes minimum and maximum of i-th metric across all classes in all MASs. Then we have Figure 10 as a result.

Figure 10 presents the min-max normalized software metrics of agent implementations across the evaluated MASs. The highlighted marker indicates the position of GUSU within the normalized range of each metric. GUSU is located near the lower end of the distributions for CLOC, MLOC, DIT and CC, indicating a considerably lighter agent implementation than most existing systems. Meanwhile, its cohesion-related metrics remain within the competitive range, suggesting that reducing agent size does not compromise internal cohesion.

To further minimize the effect of programming languages and system scale, Z-score is leveraged. Supposing ${\mathrm{E}}_{\mathrm{i},\mathrm{j}}$ and ${\mathsf{\sigma }}_{\mathrm{i},\mathrm{j}}$ are expectation and standard deviation of i-th metric of all classes in j-th MAS. ${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}$ is normalized with the formula ${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}\mathrm{\text{'}}=({\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}-{\mathrm{E}}_{\mathrm{i},\mathrm{j}})/{\mathsf{\sigma }}_{\mathrm{i},\mathrm{j}}$. Then we have Figure 11 as a result.

Figure 11 illustrates the standardized Z-scores of the same metrics. Unlike min-max normalization, Z-score standardization emphasizes how far GUSU deviates from the average of the evaluated systems. Most structural metrics of GUSU lie within one standard deviation of the mean, while CLOC, MLOC, LCOM3 and CC exhibit noticeably low Z-scores, confirming that these characteristics are significantly lower than the average. In contrast, cohesion and coupling metrics remain close to the population mean, indicating that the lightweight agent design is achieved without introducing abnormal structural properties.

Like above, before PCA is conducted, for a specific metric ${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}\mathrm{\text{'}}(\mathrm{i}=\mathrm{1,2},\dots ,12,\mathrm{j}=\mathrm{1,2},\dots ,18)$ of agent class(es) in one of 18 MASs, min-max normalization is used for the same purpose as above.

$${\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}\mathrm{\text{'}}=\left\{\begin{array}{c}{\displaystyle \frac{{\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}-{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}}}{{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{a}\mathrm{x}}-{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}}}},{\mathrm{m}}_{\mathrm{i},\mathrm{j}}\mathrm{i}\mathrm{s}\mathrm{p}\mathrm{o}\mathrm{s}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{v}\mathrm{e}\mathrm{i}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{t}\mathrm{o}\mathrm{r}\\ {\displaystyle \frac{{{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{a}\mathrm{x}}-\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}}{{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{a}\mathrm{x}}-{\mathrm{m}}_{\mathrm{i},\mathrm{m}\mathrm{i}\mathrm{n}}}},{\mathrm{m}}_{\mathrm{i},\mathrm{j}}\mathrm{i}\mathrm{s}\mathrm{n}\mathrm{e}\mathrm{g}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{v}\mathrm{e}\mathrm{i}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{t}\mathrm{o}\mathrm{r}\end{array}\right.$$

Then we can have a matrix ${\left\{{\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}^{\mathrm{\text{'}}}\right\}}_{18\times 12}$ for PCA. The result is listed in Table 3.

Figure 12 presents the PCA biplots of the evaluated MASs based on the software metrics of their agent classes after min–max normalization, where The first three principal components account for approximately 77.96% of the total variance, indicating that the two projected spaces preserve most of the architectural information.

In both subfigures, PC1 is primarily associated with CLOC, CC, NOM and Ce. The positive direction of PC1 corresponds to agent implementations that are smaller, less complex, and less coupled, representing a lightweight structural design. That is why PC1 can be interpreted as the Agent Size and Structural Complexity dimension.

In Figure 12(a), PC2 is mainly characterized by the combined contributions of the cohesion-related metrics (TCC and LCC) together with DIT, indicating differences in the structural organization of agent implementations.

As shown in Figure 12(b), PC3 is primarily influenced by Instability, with LCOM3 and DIT contributing in the opposite direction. Higher PC3 scores correspond to agent implementations with stronger architectural stability and better internal cohesion.

GUSU is located on the positive side of PC1 while remaining close to the origin along both PC2 and PC3. This distribution indicates that the agent classes of GUSU exhibit one of the most lightweight structural designs among the evaluated MASs, characterized by relatively small class size, low implementation complexity, and weak external coupling. Meanwhile, its near-central position on PC2 and PC3 suggests that the proposed architecture maintains balanced inheritance, cohesion, and stability characteristics without relying on extreme design choices.

To further provide an comperhensive assessment, the matrix ${\left\{{\mathrm{m}}_{\mathrm{i},\mathrm{j},\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{t}}^{\mathrm{\text{'}}}\right\}}_{18\times 12}$ were also evaluated using the Entropy Weight–TOPSIS method [76]. Since the normalized software metrics are all positive indicator, the maximum of each column is regarded as Positive Ideal Solution (PIS), and the minimum as Negative Ideal Solution (NIS). Entropy Weight–TOPSIS ranks candidate MASs according to their relative closeness to the PIS and remoteness from the NIS, while the entropy weighting scheme objectively determines the importance of each software metric based on its information entropy. In this way, Entropy Weight–TOPSIS directly evaluates the overall software quality by considering the information contribution of each metric. The resulting ranking places GUSU second among the 18 MASs (inferior to PettingZoo), further confirming the competitiveness of its agent design.

5.4. Discussion

To summerize, although the above analyses emphasize different aspects of the data, they reveal a consistent trend. GUSU achieves one of the smallest agent class sizes, the shortest average method length, the shallowest inheritance hierarchy, and relatively low cyclomatic complexity, while preserving cohesion and coupling comparable to those of other frameworks.

The system-level PCA indicates that the overall software architecture remains well balanced, whereas the agent-level PCA and Entropy Weight–TOPSIS demonstrate that its agent implementations rank among the best of the evaluated MASs. These results suggest that the proposed architecture distinguishes itself primarily through lightweight agent implementations while preserving a well-balanced software architecture.

6. Threats, Limitations and Future Work

6.1. Threats to Validity

Construct Validity. Actually, there is no consensus on the definition of god class in industry and academia. Research shows the thresholds that define a god class are context-dependent, and agreement among developers is often low [65]. It may be questionable about the issue in this paper.

Moreover, it seems that code quality may also have an impact. It is a very interesting observation that there are indeed a number of god classes (not necessarily god agents, but some of them are really large ones) in these open source MASs like Jade, according to PMD (https://pmd.github.io/) metrics report (see supplementary materials for details). Although it is a well-known agent platform, it is still hard to confirm the harmlessness these god classes have had on the system.

Internal Validity. Although these software metrics have been widely adopted to characterize software modularity, coupling, cohesion, and complexity, they cannot fully capture all aspects of software architecture quality, such as runtime adaptability, maintainability in practice, or developer productivity.

Different implementation languages, typically Java, Python and C++, may inherently influence several size- and inheritance-related metrics such as LOC, DIT. To reduce this effect, average class-level metrics together with Min-Max normalization and Z-score standardization were employed. The latter can mathematically reduce certain statistical and context-dependent biases, but they cannot completely eliminate the influence of programming languages.

Project size bias cannot be ignored either. Some MASs are far larger than other ones. Across different MAS, average class-level metrics do not capture values that differ drastically, which can be found in Figure 8. Literally, class-level metrics such as cohesion and coupling are relatively less affected by scale.

Different coding styles may bring about bias into the evaluation, especially for C++. GUSU adheres to a minimalist style and minimizes the use of class inheritance. However, other Java projects adhere to strictly object-oriented principles, embedding classes and objects into every detail of the design. This partly accounts for the significant differences in DIT.

External Validity. Only open source projects are involved in the evaluation, except GUSU. There are not many samples leaning towards commercial and industrial products, which may cause bias. After all, the code of most of commercial and industrial products is not available.

Conclusion Validity. Although the selected projects cover both traditional MAS frameworks and recent LLM-based agent frameworks, they may not represent all existing MASs. The sample size of 18 representative MASs may still remains small. The dataset could be expanded in the future to further validate the conclusions.

Agent Identification. The definition of agents is inconsistent at code level across different MAS paradigms. The identification of agent classes was performed according to the architectural roles expressed in the code of each MAS. Although manual verification was conducted, some subjective judgment may still exist for frameworks that do not explicitly define agent abstractions.

To avoid this, I try to ensure, as far as possible, consistent standards are applied on MAS-specific implementations during the identification. As mentioned in Table 1 and the paragraph after Figure 8, if an agent is represented as only one class without any inheritance and composite (e.g., Jade), that is the agent implementation. If a base class or interface serve as a framework of agent and its subclasses denotes the derivation (e.g., AutoGen), all of them count except for those fully abstract classes and interfaces. If an agent is represented as a group of classes (e.g., GUSU), the same applies. If agent is not explicitly implemented in the code (e.g., MetaGPT), I do use class(es) semantically related to agent as substitute(s). See supplementary materials for details.

6.2. Limitations

Debugging. Since the functionality of a single agent is distributed across multiple aspect entities and Scions, tracing the execution path and locating faults may become more difficult than in monolithic agent implementations. Aspect-aware debugging can be studied in future, instead of relying on experience of developers.

Consistency Maintenance. Because different aspect entities collaboratively represent the state of a single agent, maintaining state consistency among them becomes an important architectural concern, particularly in concurrent execution environments. Moreover, the lifecycle of an agent and its aspect entities must be synchronized. It is reasonable to establish a mechanism for transactional updates on state transferring.

Heterogeneous Interaction. Supporting heterogeneous aspect entities may requires standardized communication protocols and serialization mechanisms. But such idea typically leads to “heavy” infrastructure like WebSocket. Whether it is necessary should be give careful consideration.

Runtime Overhead. The proposed architecture introduces additional runtime overhead of searching, querying and communicating among different aspect entities, compared to building an individual agent as a whole. This issue will become more pronounced as the number of agents increases. The optimization techniques like batching or local cache may help.

Real-time and Distribution. The approach is not suitable for distributed applications that settle aspect entities in different nodes. System operation efficiency can be hindered by network latency of frequent searching and querying among different aspect entities. Real-time requirement and distribution may be two factors limiting the application of this approach, i.e., the two cannot be both satisfied at the same time.

God Class is still the Pain. Although the proposed architecture encourages fine-grained decomposition of agent responsibilities, it does not automatically prevent poor architectural decisions. Developers may still create overly large aspect entities or assign excessive responsibilities to individual aspect entities. Therefore, the effectiveness of the architecture also depends on appropriate architectural decomposition and development guidelines.

6.3. Future Work

Theoretically, although my approach is oriented to standalone settings for personalization of computing resources, it can be extended into more dynamic and decentralized circumstance without limitation on the context (e.g., BDI-like concepts or LLM solution), as long as it does not violate the aforementioned restrictions regarding the distribution.

Additionally, scalability of GUSU is reflected in two aspects, i.e., the number of agents and the number of aspect entities. GUSU allows for the arbitrary addition or removal of agents, supporting a maximum of over 2,000. GUSU currently supports simultaneous addition or removal of a specific aspect entity of all agents in it during design time by manipulating Scions. Dynamic scaling requires the coordination of corresponding mechanisms and algorithms, which can be a direction for future improvement.

7. Conclusions

This work addresses the god agent problem through architectural decomposition of agent implementations to improve maintainability and modularity while preserving the semantic integrity of individual agents, rather than through task decomposition or multi-agent orchestration, which commit a light-weighted and resource-free solution. Through the above evaluation, the approach is proved to exhibit the second most lightweight structural designs of agent implementation among the 18 reprehensive MASs, whereas suggesting a relatively balanced trade-off (rank second) among coupling, cohesion, complexity, inheritance and implementation size at the scale of the entire system. These results indicate that GUSU, as implementation of the approach, effectively prevents the concentration of excessive responsibilities within agent classes, thereby mitigating the god agent problem through a lightweight and fine-grained architectural design rather than by sacrificing modularity or maintainability.