> ## Documentation Index
> Fetch the complete documentation index at: https://docs.monolex.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Meeting Protocol: Multi-Agent Conference

> Real-time multi-agent meetings — not sequential pipeline, but live conference where every participant hears every voice.

# Meeting Protocol

Pipeline is sequential. Dialogue is two-way. Meeting is **everyone at once**.

## Beyond Pipeline

```
Pipeline:    A → B → C → D         (assembly line)
Dialogue:    A ↔ B                  (conversation)
Meeting:     A ↔ B ↔ C ↔ D         (conference)
             everyone hears everyone
```

In a meeting, all agents are alive simultaneously. When one speaks, all others hear it. Any agent can respond to any other. The orchestrator manages turn order, not information flow.

## How It Works

```
┌────────────┐    ┌────────────┐    ┌────────────┐
│ PTY: Opus  │    │ PTY: Codex │    │ PTY: Gemini│
│ "architect"│    │ "security" │    │ "pragmatist│
└──────┬─────┘    └──────┬─────┘    └──────┬─────┘
       │                 │                  │
       └────────┬────────┴──────────┬───────┘
                │                   │
         ┌──────┴───────────────────┴──────┐
         │  Orchestrator (niia)            │
         │  - reads each agent's response  │
         │  - broadcasts to all others     │
         │  - manages agenda + turns       │
         └─────────────────────────────────┘
```

When the architect speaks:

1. `niia get-answer` reads architect's PTY
2. `niia write` sends it to security's PTY: "Architect says: ..."
3. `niia write` sends it to pragmatist's PTY: "Architect says: ..."
4. Both respond. Orchestrator collects and broadcasts again.

## Meeting Spec

```json theme={null}
{
  "connector": "2.0",
  "name": "architecture-meeting",
  "type": "meeting",

  "participants": [
    {
      "id": "architect",
      "model": "opus",
      "role": "Software architect. You design systems for scale. Argue for clean separation of concerns."
    },
    {
      "id": "security",
      "model": "codex",
      "role": "Security engineer. Every design decision is an attack surface. Find the risks others miss."
    },
    {
      "id": "pragmatist",
      "model": "gemini",
      "role": "Engineering pragmatist. Push back on over-engineering. Advocate for shipping."
    }
  ],

  "agenda": [
    {
      "topic": "Should we migrate auth to microservices?",
      "opener": "architect",
      "rounds": 3
    },
    {
      "topic": "How do we handle the database migration?",
      "opener": "security",
      "rounds": 2
    },
    {
      "topic": "Timeline, risks, and ship date?",
      "opener": "pragmatist",
      "rounds": 2
    }
  ],

  "rules": {
    "broadcast": true,
    "each_sees_all": true,
    "minutes": true
  }
}
```

## Meeting Flow

```
AGENDA ITEM 1: "Should we migrate auth to microservices?"

  Architect (Opus):
    "Microservices give us independent scaling of the auth layer.
     Token validation can scale separately from session management."

  → broadcast to Security + Pragmatist

  Security (Codex):
    "Microservices mean more network boundaries = more attack surface.
     Service-to-service auth adds complexity. mTLS? JWT forwarding?"

  → broadcast to Architect + Pragmatist

  Pragmatist (Gemini):
    "We have 3 engineers and a 6-week deadline.
     Microservices migration is a 3-month project.
     Can we just add a reverse proxy and call it done?"

  → broadcast to Architect + Security

  [Round 2: each responds to what they heard]
  [Round 3: final positions]

  Minutes: auto-generated summary → scratchpad/minutes/item-1.md

AGENDA ITEM 2: ...
```

## Meeting Output

```
scratchpad/
├── minutes/
│   ├── item-1-auth-microservices.md    ← full transcript + decisions
│   ├── item-2-database-migration.md
│   └── item-3-timeline-risks.md
├── decisions.md                        ← agreed action items
└── dissent.md                          ← unresolved disagreements
```

Every meeting produces structured artifacts. The next pipeline can read these.

## Meeting → Implementation Pipeline

A meeting can feed directly into a build pipeline:

```json theme={null}
{
  "connector": "2.0",
  "name": "design-then-build",

  "pipeline": {
    "phases": [
      {
        "name": "design-review",
        "type": "meeting",
        "participants": [
          { "model": "opus",   "role": "architect" },
          { "model": "codex",  "role": "security" },
          { "model": "gemini", "role": "pragmatist" }
        ],
        "agenda": [
          { "topic": "Design the auth refactor", "rounds": 3 }
        ]
      },
      { "name": "implement", "model": "opus",   "prompt": "Read decisions.md. Implement exactly what was agreed." },
      { "name": "verify",    "model": "codex",  "prompt": "Verify security concerns from dissent.md are addressed." },
      { "name": "ship",      "model": "sonnet", "prompt": "Run tests, create PR." }
    ],
    "scratchpad": true
  }
}
```

Three AI models debate the design. Then build exactly what they agreed on. Security concerns from the meeting are explicitly verified.

## Why Meetings > Delegation

|              | Delegation (leader→worker)     | Meeting (peers)               |
| ------------ | ------------------------------ | ----------------------------- |
| Perspectives | Leader's only                  | Every participant             |
| Blind spots  | Leader's blind spots propagate | Caught by other participants  |
| Buy-in       | Worker follows orders          | Each participant contributed  |
| Quality      | Only as good as leader         | Emergent from disagreement    |
| Decisions    | Top-down                       | Consensus or explicit dissent |

## Related

For two-agent conversations, see [Bidirectional Communication](/openclis/specs/connector-json/bidirectional). For full any-to-any mesh without agenda structure, see [N-to-N Topology](/openclis/specs/connector-json/n2n-topology). For agents that spawn their own sub-meetings, see [Recursive Teams](/openclis/specs/connector-json/recursive-teams).