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
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:
niia get-answer reads architect’s PTY
niia write sends it to security’s PTY: “Architect says: …”
niia write sends it to pragmatist’s PTY: “Architect says: …”
- 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) |
|---|
| 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 |
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.