Multi Agent Turn Arbiter

Name: Multi Agent Turn Arbiter
Rating: 3.5 (1 reviews)
Author: LivingGhost

By LivingGhost 👁 25 views ▲ 0 votes

OpenClaw plugin for serializing visible multi-agent turns in shared conversations

GitHub

Configuration Example

{
  "plugins": {
    "allow": ["multi-agent-turn-arbiter"],
    "entries": {
      "multi-agent-turn-arbiter": {
        "enabled": true,
        "config": {
          "leaseMs": 15000,
          "settleMs": 1500,
          "botReopenCooldownMs": 15000,
          "epochIdleMs": 3600000,
          "maxBotHops": 16,
          "maxPromptChars": 60000,
          "failOpen": true,
          "debug": false
        }
      }
    }
  }
}

README

# multi-agent-turn-arbiter

OpenClaw plugin for serializing visible multi-agent turns in a shared conversation.

## What it does

When multiple bot agents are present in the same chat, this plugin tries to keep the conversation visually sequential:

- one bot claims the current turn
- other bots yield instead of visibly replying at the same time
- chunked or split bot output is given a short settle window before the baton moves
- once a bot reply becomes visible, other eligible bots can react to that visible message in the next hop
- stale late-arriving bot messages are ignored as new roots when possible

The goal is practical coordination of visible output. It does not hard-cancel model generations that already started.

## How it works

The plugin keeps short-lived in-memory state per conversation:

- the latest visible message chain for the current epoch
- the current claim holder
- per-message decline state
- dedupe and stale-message guards

It uses OpenClaw hooks such as:

- `message_received`
- `before_prompt_build`
- `llm_input`
- `llm_output`
- `message_sending`
- `message_sent`
- `agent_end`

## Requirements

This plugin expects outbound hook metadata to include enough information to correlate sends back to the active conversation turn.

In practice, it works best with an OpenClaw build that exposes outbound hook metadata like:

- `conversationId`
- `threadId`
- `sessionKey`
- `agentId`

Without that metadata, loser/stale send suppression is less reliable.

## Installation

Place this directory under your OpenClaw extensions directory:

```text
.openclaw/extensions/multi-agent-turn-arbiter
```

Then allow and enable it in `openclaw.json`:

```json
{
  "plugins": {
    "allow": ["multi-agent-turn-arbiter"],
    "entries": {
      "multi-agent-turn-arbiter": {
        "enabled": true,
        "config": {
          "leaseMs": 15000,
          "settleMs": 1500,
          "botReopenCooldownMs": 15000,
          "epochIdleMs": 3600000,
          "maxBotHops": 16,
          "maxPromptChars": 60000,
          "failOpen": true,
          "debug": false
        }
      }
    }
  }
}
```

## Config

| Key | Meaning |
| --- | --- |
| `enabled` | Turns the plugin on or off. |
| `enabledChannels` | Optional allowlist of channel IDs. Empty means all channels. |
| `leaseMs` | How long a claim stays valid without activity. |
| `settleMs` | How long to wait for split/chunked visible output before finalizing a bot turn. |
| `botReopenCooldownMs` | Cooldown that suppresses stale bot-root reopen attempts after a new visible root appears. |
| `epochIdleMs` | Idle timeout for dropping old conversation epochs. |
| `maxBotHops` | Maximum number of bot-to-bot hops before the epoch closes. |
| `maxPromptChars` | Maximum characters of plugin-added visible transcript context before the epoch is closed. |
| `failOpen` | If true, prefer letting delivery continue on plugin errors instead of blocking output. |
| `debug` | Enables verbose plugin logging. |

## Limits

- It serializes visible output, not hidden generation.
- If a model run has already started, the plugin cannot guarantee hard cancellation.
- Continuing multi-hop bot dialogue depends on visible bot messages being re-observed as inbound events by the host channel integration.
- The plugin keeps only short-lived in-memory state. It is not a persistent transcript store.

## Repo layout

- `index.ts`: plugin implementation
- `openclaw.plugin.json`: plugin manifest and config schema
- `package.json`: package metadata

tools