Multi-Agent Collaboration: Harnessing the Power of Intelligent LLM Agents

In plain words

Today's large language models are good at answering one prompt at a time, but they work alone and cannot easily hand work to each other or look things up in outside sources. This paper argues for a team setup instead: several language model "agents", each with its own job, that pass messages, call tools and check each other's work.

The paper describes this as a shared workspace where the agents and their tools are nodes that talk over connections. Each agent has a model, a role, a memory of what it knows and is doing, and a few permissions, such as whether it may create new agents or stop others. A helper "oracle" agent has no memory and only judges the input it is given, and a "supervisor" can stop an agent that is stuck in a loop. The paper uses this picture to look at two existing autonomous agent projects and to sketch a courtroom and a software team. It presents no measurements, so it is a design guide, not a benchmark.

TL;DR

• A conceptual framework, not an empirical study: it defines agents, plugins, messages and permissions as a graph §2 §3.
• Agents can create other agents and halt them; a stateless oracle agent and a supervisor agent give feedback and stop loops §3.2 §3.4 §3.5.
• Applied, by description only, to Auto-GPT, BabyAGI and Gorilla, and to courtroom and software-development scenarios §4.
• The paper reports no experiments, no hyperparameters and no numeric results.
• Relevant if you want a vocabulary or checklist for designing an agent team; not relevant if you need measured performance.

Problem

The paper says a single language model working alone cannot divide work, consult other agents or use outside knowledge, which limits it on complex tasks §1. It also names failure modes of existing autonomous agents: getting stuck in loops, security risks when file and code actions run without human approval, unbounded growth in the number of agents, coordination conflicts, and hard-to-define evaluation metrics §4.1.2 §5.1 §5.2 §5.3.

The paper assumes the system is designed by a person who fixes the agents, the plugins and the permissions up front, and that agents may then adapt within that design §3.2 §3.6.

Method

The paper treats the whole system as a black box that takes an initial prompt and returns a final output §1. It is written as a graph model:

1. Graph. The environment is a graph G(V, E). V holds the agents and the plugins; E holds the channels between agents and plugins, and between agents §2 §2.3.
2. Agent. Each agent i is a tuple A_i = (L_i, R_i, S_i, C_i, H_i) §2.1:
   • L_i: the language model and its configuration, including temperature. The paper says the model may be chosen per task, for example GPT-4 for deep reasoning and GPT-3.5-turbo for faster execution §2.1.
   • R_i: the agent's role, meaning its responsibilities and duties §2.1.
   • S_i: the state, meaning its knowledge base and its "thoughts", which are its current focus or plan and are updated after each operation §2.1.
   • C_i: a boolean, true if the agent may create new agents §2.1 §3.2.
   • H_i: the set of agents this agent may halt §2.1 §3.5.
3. Plugin. Each plugin j is a tuple P_j = (F_j, C_j, U_j) §2.2:
   • F_j: the functions agents can call, such as file, database or API access.
   • C_j: configuration fixed at initialisation, such as API keys or thresholds.
   • U_j: usage constraints, such as limits on compute, input types or output.
4. Message. A message from agent A_i to A_j is a tuple m = (S_m, A_m, D_m): content, action (task assignment, report, request or other) and metadata such as timestamp, sender, receiver and context §2.3. The paper also describes a plugin used as a shared store or a many-to-many message board §2.3.
5. Dynamic creation. A creator agent with C_i true may create a new agent, give it a role, and grant it properties and connections that are a subset of its own. It also connects the new agent back to itself and may set its first goal §3.2.
6. Feedback. Inter-agent feedback is agents critiquing each other, including role-play prompting in the style of CAMEL's "inception prompting" §3.3. Self-feedback is a pair of connected agents, one that critiques and one that refines, which removes the need for a human to ask for refinement §3.3.
7. Oracle agent. A stateless, memory-less agent that answers only from its current input. Other agents use it for feedback before they continue §3.4.
8. Halting and supervision. Any agent may be granted the right to halt others; a creator uses it on the agents it created §3.5. A "Supervisor Agent" watches another agent's progress and task list, detects loops or drift, and sends a halt command §3.5.
9. Autonomous design. An LLM agent may be the system designer, choosing roles, connections and permissions from the goals and constraints, or review and refine a design a human wrote §3.6.

Pseudocode of the data model, derived from the text. The paper contains no algorithm; this only restates the tuples above.

# Agent and plugin records  [§2.1] [§2.2]
# Derived from the tuple definitions; the paper gives no algorithm.
# (no tensor shapes: the paper has no numeric model)

def make_agent(model, role, state, may_create, may_halt):
    # L: model type and config, e.g. temperature  [§2.1]
    # R: responsibilities  [§2.1]
    # S: knowledge and thoughts  [§2.1]
    # C: may create agents  [§2.1]
    # H: agents this one may halt  [§2.1]
    return (model, role, state, may_create, may_halt)

def make_plugin(functions, config, constraints):
    # F: callable functions  [§2.2]
    # C: init-time configuration  [§2.2]
    # U: usage constraints  [§2.2]
    return (functions, config, constraints)

def make_message(content, action, metadata):
    # m = (S_m, A_m, D_m)  [§2.3]
    return (content, action, metadata)

Hyperparameters

The paper has no experiments, so no training or inference settings are given.

Results

Not applicable. The paper reports no quantitative results and no experiments. Its use cases are qualitative descriptions of existing systems and of design sketches §4. The abstract's claims about "efficiency and effectiveness" are not backed by measurements in the text [abstract] §6.

Paper vs code

No official code. The paper links the Auto-GPT and BabyAGI repositories as footnotes §4 but they are third-party projects that the paper analyses, not code written by the authors. Searched the GitHub API for "talebirad", "nadiri multi-agent" and "intelligent generative agents multi-agent"; no result clearly belonged to the authors. Nothing was cloned and no code fields are set.

Pitfalls

• No evaluation. The abstract says the framework works "more efficiently and effectively" [abstract]. The body contains no experiment and no metric, so treat every benefit claim as a hypothesis §4 §6.
• Descriptions of other systems are the paper's own reading. The Auto-GPT and BabyAGI mappings rely on those projects' public behaviour as the authors read it §4.1.1 §4.2.1. The paper states nothing about their code.
• Ambiguous creation rule. C_i is described as a permission §2.1 and the creator "assigns" a subset of its own properties §3.2. It is not stated whether the created agent may itself create agents, or whether there is a depth limit.
• Halting authority is not defined as a protocol. The message format is defined §2.3, but how a halt message is authenticated, what the halted agent does next, and whether it can be overridden are left open. The paper says only that the agent may go idle or run a default action, depending on the design §3.5.
• Graph edges. Edges are defined only between agents and plugins, and between agents §2 §2.3. Plugin-to-plugin connections are not defined, although a plugin is a graph node §2.
• Oracle agent semantics. It is described as "stateless and memory-less" §3.4, yet a Supervisor is said to review "recent activities" §3.5. The paper does not say how the supervisor gets that history without giving the oracle state.
• Security is named, not solved. The paper proposes a stateless oracle to screen sensitive actions §4.1.2 but does not say how the screening decision is made or tested.
• Resource management and conflict checks are unspecified. The mechanisms to limit agent creation and to detect overlapping roles are described in words only, with no metric or threshold §5.1.
• Scope of the scenarios. The courtroom design says outcomes "should be interpreted with caution" and that the framework "cannot fully replicate" human judgement §4.4.1. The software-team case is an enumerated role list, not a tested workflow §4.4.2.
• Gorilla comparison. The paper says its own model "offers a more generalized and robust framework" than Gorilla §4.3.2. It is not stated how this was measured, and none is reported.

Lineage

• Builds on: GPT models as language components §1; role-playing multi-agent work in CAMEL, arXiv:2303.17760, and its inception prompting §3.3; the generative-agents sandbox, arXiv:2304.03442 §1; iterative self-feedback in Self-Refine, arXiv:2303.17651 §3.3; agent-based courtroom modelling, arXiv:2301.05327 §4.4.1; API-calling with retrieval in Gorilla, arXiv:2305.15334 §4.3.
• Compared against: Auto-GPT and BabyAGI, described and mapped qualitatively §4.1 §4.2; Gorilla's reported improvement over GPT-4 at writing API calls, cited as the paper's own description §4.3.2.
• Superseded by: not stated in this card's sources.