DRAMA-Bot: Dynamic Multi-Agent Framework

• DRAMA-Bot is a dynamic, LLM-based multi-agent framework employing a two-plane design to adapt to agent dropout, new task arrivals, and environmental changes.
• It uses a unified resource model that treats agents and tasks as objects, enabling efficient scheduling and reassignment through flexible affinity-based allocation.
• Affinity-based scheduling via a Planner–Critic loop optimizes task assignments, resulting in up to 17.3% improvement in efficiency under dynamic scenarios compared to traditional methods.

DRAMA-Bot denotes a multi-agent bot framework instantiated from DRAMA, a Dynamic and Robust Allocation-based Multi-Agent System designed for changing environments. In this formulation, a population of autonomous LLM-based worker agents is coordinated by a global control plane that dynamically allocates and reallocates tasks as the environment and team composition change; agents and tasks are treated as resource objects, task assignment is affinity-based and loosely coupled, and unfinished work can be taken over when an agent becomes unavailable (Wang et al., 6 Aug 2025).

1. Problem formulation and design rationale

DRAMA-Bot addresses a limitation of classical and many LLM-based multi-agent systems: their architectures are static. In the formulation used by DRAMA, the agent set is

$\mathcal{A} = \{a_1, a_2, \ldots, a_N\},$

the task set is

$$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$

and each agent is modeled as

$a_i = \langle S_i, O_i, A_i, \pi_i \rangle,$

with local state space $S_i$, observation space $O_i$, action set $A_i$, and policy $\pi_i$. At time $t$, a task assignment function

$f_t : \mathcal{Q} \rightarrow \mathcal{A}$

maps each task to an agent. Static MAS effectively enforce

$f_t = f_0, \quad \forall t \in [1, T],$

which collapses dynamic allocation into a one-time assignment and makes adaptation to agent churn, task arrival, reprioritization, failures, and delays difficult (Wang et al., 6 Aug 2025).

The design goals of DRAMA-Bot follow directly from this critique. The system is intended to permit $$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$0 to change in response to events, support agents joining, leaving, or failing, preserve execution by reallocating unfinished work, and improve resource utilization through affinity-based allocation that considers capabilities, workload, and environment. The architecture is also explicitly modular: a control plane provides centralized planning and monitoring, while a worker plane contains heterogeneous autonomous agents that reason and execute locally. This separation is meant to preserve scalability while avoiding hard-wired agent–task bindings (Wang et al., 6 Aug 2025).

2. Two-plane architecture and unified resource model

The architectural core of DRAMA-Bot is a two-plane design. The control plane is the “global brain”: it monitors system state, performs high-level planning and task allocation, runs a Planner–Critic scheduling loop, and reacts to events such as agent dropout, new agent arrival, or anomalous progress. The worker plane is the “body”: a cluster of heterogeneous autonomous agents that interact with the environment, execute assigned tasks, communicate status, collaborate, and take over unfinished work when necessary (Wang et al., 6 Aug 2025).

Element	Definition	Primary function
Control plane	Global planning layer	Monitoring, scheduling, reassignment
Worker plane	Heterogeneous autonomous agents	Local reasoning, execution, collaboration
Resource objects	Unified abstraction for agents and tasks	Lifecycle management and allocation input

A distinctive modeling decision is the unified resource abstraction. DRAMA treats both agents and tasks as resource objects:

$$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$1

Each resource is represented by an attribute set

$$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$2

For agents, $$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$3 includes capabilities, tools, model type, current workload, active tasks, location or spatial context, and status. For tasks, it includes requirements, current status, progress, remaining subtasks, and priority or deadlines. Scheduling is then defined over a common attribute space:

$$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$4

This decouples task ownership from static role assignment and permits reassignment by updating attributes and the current mapping rather than changing architecture (Wang et al., 6 Aug 2025).

The implied lifecycles are also important. Agent states progress through Available, Busy, Unavailable, and Rejoin; task states progress through Created, Assigned, In-progress, Completed or Failed, and Reassigned when necessary. In a DRAMA-Bot deployment, each bot is therefore an agent resource object, each user request or subtask is a task resource object, and the control plane manages both through resource metadata rather than fixed bindings (Wang et al., 6 Aug 2025).

3. Affinity-based scheduling, monitoring, and reassignment

Task allocation is loosely coupled and affinity-based. Rather than permanently binding a task to a specific bot, DRAMA computes assignments at scheduling time using an affinity notion that reflects capability match, spatial proximity in embodied settings, current workload, and task urgency or complexity. The paper leaves the exact affinity function implicit, but formalizes it conceptually as

$$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$5

subject to capacity, capability, and status constraints. In practice, allocation is realized through LLM reasoning and heuristic scheduling rather than an explicit combinatorial solver (Wang et al., 6 Aug 2025).

The control plane implements this through a Planner–Critic loop:

$$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$6

The Planner proposes candidate assignments using current resource attributes and environment observations; the Critic evaluates these candidates against objectives and constraints, refining or rejecting them until a satisfactory assignment is found. Rescheduling is event-driven rather than continuously polled:

$$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$7

Triggering events include agent failure or dropout detected through missing heartbeats, new agent arrival, abnormal task progress, new task arrival, and changes in task requirements (Wang et al., 6 Aug 2025).

Monitoring is handled by a dedicated Monitor agent in the control plane. It receives periodic heartbeat messages indicating liveness and availability, aggregates richer information such as reported status, task progress, remaining steps, current location, completion status, and pending subtasks, and signals the Planner when anomalies or significant state changes occur. Because scheduling is coarse-grained, the control plane does not micromanage primitive actions; it assigns coarse tasks and lets local agents manage detailed execution. That choice is central to the system’s scalability claims (Wang et al., 6 Aug 2025).

4. Worker-plane cognition, memory, and takeover behavior

Each worker in DRAMA-Bot is an autonomous LLM-based agent with capabilities, tools, a model backbone, local environment state, and a current workload. Once a high-level task is assigned, the worker interprets it, checks capability and state, decomposes it into primitive steps, executes the plan, monitors outcomes, and revises the plan as needed. The paper describes this as local reasoning driven by textual instructions and environment feedback rather than by a specific symbolic planner or RL controller (Wang et al., 6 Aug 2025).

A central mechanism is hierarchical memory. Each worker maintains high-priority detailed memory for ongoing primary tasks and critical subtasks, summarized recent history for less critical but still relevant events, and pruned historical data for outdated information. In bot deployments, this translates naturally into a short-term prompt window for active state, long-term summarized memory per user or project, and explicit retention, summarization, and forgetting policies. The same section of the design also emphasizes anticipation of other agents’ actions, both to avoid conflicts over shared resources and to exploit opportunities for cooperation (Wang et al., 6 Aug 2025).

Task takeover is the most distinctive worker-plane behavior. If one agent leaves or cannot finish its job, the control plane marks its tasks as unassigned, the scheduler reallocates them to another agent with sufficient affinity, and the receiving worker reconstructs context from shared task descriptions and recorded progress before continuing from the partial state. This is the operational meaning of bot transfer in DRAMA-Bot: one bot can continue another’s unfinished conversation, workflow, or pipeline stage without restarting the task from scratch (Wang et al., 6 Aug 2025).

5. Experimental evaluation and robustness profile

DRAMA is evaluated on the Communicative Watch-And-Help benchmark built on VirtualHome-Social, with embodied household tasks involving multiple objects, spatial complexity, and cooperative agents. The experiments include static scenarios with 2, 3, or 4 agents and dynamic scenarios in which one of 3 agents is removed at a random step between 5 and 10 or an additional agent is added during the same interval. Baselines are CoELA, MCTS (MASTER-like), AgentVerse-Static, AgentVerse-Dynamic, and ProAgent; efficiency comparisons provide extra hints such as final target and current progress so that the focus remains on allocation efficiency (Wang et al., 6 Aug 2025).

Three metrics are used: Success Rate (SR), Average Steps (AS), and Total Steps (TS). SR measures the fraction of episodes in which all task requirements are satisfied within the time horizon. AS is the mean number of steps taken by the agent completing the final task, and TS is the sum of steps taken by all agents in an episode. In more complex or dynamic scenarios—specifically 4-agent settings and the addition or dropout conditions—DRAMA reports a 4.8–13.5% reduction in AS and a 4.6–17.3% reduction in TS versus the strongest baseline. In static and agent-addition scenarios, all compared frameworks succeed; in agent-dropout scenarios, only DRAMA succeeds, because the others cannot properly reassign incomplete tasks when an agent leaves (Wang et al., 6 Aug 2025).

The evaluation also includes a stability study over 100 runs on two dynamic tasks. DRAMA shows lower median AS and TS and tighter distributions than the baselines, which the paper interprets as more predictable efficiency under agent churn. A model-agnostic generalization study replaces worker backbones with GPT-4.1, Qwen-Max, DeepSeek-v3, and GPT-4o-mini. In both 3→2 and 3→4 scenarios, all achieve SR = 100%, with AS and TS in similar ranges, suggesting that the allocation logic is largely independent of the specific LLM chosen for a worker (Wang et al., 6 Aug 2025).

6. Adjacent specializations and open challenges

Several neighboring systems elaborate concrete specializations that a DRAMA-Bot can adopt. Open-Theatre provides an open-source toolkit for LLM-based interactive drama with a configurable multi-agent pipeline and a hierarchical retrieval-based memory system organized into Global, Event, Summary, and Archive stores; it compares One-for-All, Director–Actor, Hybrid, and Director–Global Actor architectures, and reports that memory consistently improves response plausibility and narrative coherence (Xu et al., 20 Sep 2025). “Towards Enhanced Immersion and Agency for LLM-based Interactive Drama” introduces Playwriting-guided Generation and Plot-based Reflection, formalizing online adaptation through

$$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$8

with reflection triggered every $$\mathcal{Q} = \{\mathtt{q}_1, \mathtt{q}_2, \ldots, \mathtt{q}_M\},$$9 moments to modify at most one incomplete plot or insert one new plot (Wu et al., 25 Feb 2025). HAMLET extends this direction to live embodied theatrics, combining offline blueprint generation, PAD-based actor control, interactable props, and narrator-mediated environment updates, while evaluating character performance, narrative quality, and interaction experience as whole-performance properties (Chen et al., 21 Jul 2025). BotDirector shows a physically embodied storytelling pipeline in which GPT-4 supports narrative co-creation, formal scripts are represented as records such as

$a_i = \langle S_i, O_i, A_i, \pi_i \rangle,$0

and execution is grounded through paired virtual and physical stages, AprilTags, and A* path planning (Sun et al., 2 Jun 2026).

Other systems contribute complementary control patterns. The “drama machine” separates Ego and Superego roles so that intersubjective dialogue and intra-subjective internal monologue proceed in parallel, producing more introspective and divergent character trajectories than single-agent baselines (Magee et al., 2024). DialogueScript uses personality-specific GPT-2 models coordinated by a dramatic network defined through centrality, loyalty, and reciprocity, and introduces NLI-Score as a dialogue consistency metric (Schmidtová et al., 2022). For authoring and revision, CO-OPERA organizes drama support into divergence–convergence cycles with tutors and functional agents across logline, character, plot, scene, and dialogue stages, while Dramaturge uses a hierarchical script-doctoring loop composed of Global Review, Scene-level Review, and Hierarchical Coordinated Revision, outperforming its baselines on both script-level and scene-level quality (Ma et al., 1 Jun 2025, Xie et al., 6 Oct 2025).

The DRAMA architecture itself also identifies two system-level limitations. First, the centralized control plane is a potential single point of failure and a scalability bottleneck. Second, affinity evaluation depends on LLM-based reasoning, which introduces latency and cost. A plausible implication is that future DRAMA-Bot systems will move toward distributed or hierarchical control, more efficient affinity scoring, and tighter integration of structured memory, environment models, and domain-specific planning loops already visible in adjacent narrative, embodied, and revision-oriented systems (Wang et al., 6 Aug 2025).