Skip to main content

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

{
  "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:
{
  "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)
PerspectivesLeader’s onlyEvery participant
Blind spotsLeader’s blind spots propagateCaught by other participants
Buy-inWorker follows ordersEach participant contributed
QualityOnly as good as leaderEmergent from disagreement
DecisionsTop-downConsensus or explicit dissent
For two-agent conversations, see Bidirectional Communication. For full any-to-any mesh without agenda structure, see N-to-N Topology. For agents that spawn their own sub-meetings, see Recursive Teams.