Should organizational rules be designed separately from agent roles?

Zambonelli, Jennings and Wooldridge's 2003 Gaia methodology argues that role models and interaction models — the abstractions "most approaches to MAS modeling" (including Gaia's own earlier 2000 version) treat as sufficient for designing a multiagent system — are not enough on their own. The paper adds two further abstractions as first-class parts of the design process: organizational rules, which capture "constraints that the actual organization, once defined, will have to respect," and organizational structures, the architectural topology (hierarchy, peer collective, market) that a role model only implies rather than states. The authors are explicit that "although role and interaction models can be useful to fully describe an existing organization, they are of limited value in building an organization."

Their reasoning is that certain constraints cannot be pinned to any single role without duplicating them everywhere. A rule like "all the different stages must maintain the same speed of flow of items" in a manufacturing pipeline, or "an agent should be prevented from playing both the role of author and reviewer of the same paper" in a conference-management system, "spread horizontally over all the roles" or "express relations and constraints between roles" — the same way, they write, that "social conventions and company directives horizontally influence our social life and our work, but cannot be associated with any specific actor." Organizational rules also do governance work in open systems: they let a designer decide "whether and when to allow new agents to enter the organization" and "which behaviours should be considered as a legitimate expression of self-interest, and which among them must be prevented." Organizational structure, meanwhile, is a distinct design choice rather than something a role model bakes in by default — a "master role"/"slave roles" model implicitly commits to a hierarchical topology, but the paper argues structure should be chosen explicitly from information gathered during analysis, not anticipated before that information exists.

This two-decades-old methodology for conventional software multiagent systems anticipates vocabulary that current agent-governance work reinvents independently. Why do agents fail at identity verification and authorization? addresses, for LLM agents, almost exactly the governance function Gaia assigned to organizational rules: deciding who may join a coordination structure and bounding what self-interested or unauthorized behavior is tolerated. How should humans and AI systems divide decision-making tasks? makes the same genre of move — treating agent deployment as organization design rather than agent-capability engineering — but works from task-type and learning-configuration typologies where Gaia works from roles, rules, and structure as separable abstractions; the two read as complementary vocabularies for the same underlying claim, that organizing multiple agents is a design problem distinct from designing any individual agent. Do single agents always hit organizational limits? reaches a structurally similar conclusion from the opposite direction: system-level intelligence needs its own abstractions because no amount of single-agent improvement substitutes for organizing the whole — Gaia's organizational-structure abstraction is an early, non-LLM instance of that same argument.

The excerpt is a software engineering methodology for predictable, reliable multiagent systems built for applications like manufacturing-line control and conference-paper management — it says nothing about LLM-based agents, natural-language role prompting, or emergent behavior, and the "self-interested agents" it worries about are an abstract design concern in open distributed systems, not empirically observed LLM behavior. What it establishes is narrower but still useful: in at least these two worked examples, treating rules and structure as implicit properties of a role model produced designs the authors judge more complex and more constraint-fragile than treating them as separate, explicit abstractions. Whether that same separation reduces complexity when the "roles" are filled by LLM agents rather than conventional software agents is a transfer this 2003 paper does not test.