Inter-Agent Protocol
How C-suite agents talk to each other. Rules that prevent chaos, loops, and circular reasoning.
Keywords
agent protocol, inter-agent communication, agent invocation, agent orchestration, multi-agent, c-suite coordination, agent chain, loop prevention, agent isolation, board meeting protocol
Invocation Syntax
Any agent can query another using:
Examples:
Valid roles: ceo, cfo, cro, cmo, cpo, cto, chro, coo, ciso, gc, cdo, caio, cco, vpe
Response Format
Invoked agents respond using this structure:
Example:
Loop Prevention (Hard Rules)
These rules are enforced unconditionally. No exceptions.
Rule 1: No Self-Invocation
An agent cannot invoke itself.
Rule 2: Maximum Depth = 2
Chains can go A→B→C. The third hop is blocked.
Rule 3: No Circular Calls
If agent A called agent B, agent B cannot call agent A in the same chain.
Rule 4: Chain Tracking
Each invocation carries its call chain. Format:
Agents check this chain before responding with another invocation.
When blocked: Return this instead of invoking:
Isolation Rules
Board Meeting Phase 2 (Independent Analysis)
NO invocations allowed. Each role forms independent views before cross-pollination.
- Reason: prevent anchoring and groupthink
- Duration: entire Phase 2 analysis period
- If an agent needs data from another role: state explicit assumption, flag it with
[ASSUMPTION: ...]
Board Meeting Phase 3 (Critic Role)
Executive Mentor can reference other roles' outputs but cannot invoke them.
- Reason: critique must be independent of new data requests
- Allowed: "The CFO's projection assumes X, which contradicts the CRO's pipeline data"
- Not allowed:
[INVOKE:cfo|...]during critique phase
Outside Board Meetings
Invocations are allowed freely, subject to loop prevention rules above.
When to Invoke vs When to Assume
Invoke when:
- The question requires domain-specific data you don't have
- An error here would materially change the recommendation
- The question is cross-functional by nature (e.g., hiring impact on both budget and capacity)
Assume when:
- The data is directionally clear and precision isn't critical
- You're in Phase 2 isolation (always assume, never invoke)
- The chain is already at depth 2
- The question is minor compared to your main analysis
When assuming, always state it:
Conflict Resolution
When two invoked agents give conflicting answers:
- Flag the conflict explicitly:
- State the resolution approach:
- Conservative: use the worse case
- Probabilistic: weight by confidence scores
- Escalate: flag for human decision
- Never silently pick one — surface the conflict to the user.
Broadcast Pattern (Crisis / CEO)
CEO can broadcast to all roles simultaneously:
Responses come back independently (no agent sees another's response before forming its own). Aggregate after all respond.
Decision Memory (Canonical Layout)
All C-suite skills and /cs:* commands read and write decisions in one place — the two-layer model owned by /cs:decide and the decision-logger skill:
Rules:
- Layer 1 (raw) stores everything, including rejected arguments. Reference only — never feeds future sessions automatically.
- Layer 2 (approved) stores only founder-approved decisions. This is what board meetings,
/cs:office-hours, and/cs:founder-modeload. Prevents hallucinated consensus. - Writers:
/cs:decideand the Chief of Staff (post board-meeting Phase 5). Individual role agents never write decisions directly. - decision-logger, chief-of-staff, and board-meeting all use this layout. Their SKILL.md files link here rather than defining their own paths.
Migration: earlier versions used memory/board-meetings/ (decision-logger, board-meeting) and ~/.claude/decision-log.md (chief-of-staff); read those for history if present, but write all new entries to ~/.claude/decisions/.
Quick Reference
Internal Quality Loop (before anything reaches the founder)
No role presents to the founder without passing through this verification loop. The founder sees polished, verified output — not first drafts.
Step 1: Self-Verification (every role, every time)
Before presenting, every role runs this internal checklist:
Step 2: Peer Verification (cross-functional validation)
When a recommendation impacts another role's domain, that role validates BEFORE presenting.
Peer validation format:
Skip peer verification when:
- Single-domain question with no cross-functional impact
- Time-sensitive proactive alert (send alert, verify after)
- Founder explicitly asked for a quick take
Step 3: Critic Pre-Screen (high-stakes decisions only)
For decisions that are irreversible, high-cost, or bet-the-company, the Executive Mentor pre-screens before the founder sees it.
Triggers for pre-screen:
- Involves spending > 20% of remaining runway
- Affects >30% of the team (layoffs, reorg)
- Changes company strategy or direction
- Involves external commitments (fundraising terms, partnerships, M&A)
- Any recommendation where all roles agree (suspicious consensus)
Pre-screen output:
Step 4: Course Correction (after founder feedback)
The loop doesn't end at delivery. After the founder responds:
Verification Level by Stakes
What Changes in the Output Format
The verified output adds confidence and source information:
User Communication Standard
All C-suite output to the founder follows ONE format. No exceptions. The founder is the decision-maker — give them results, not process.
Standard Output (single-role response)
Proactive Alert (unsolicited — triggered by context)
Board Meeting Output (multi-role synthesis)
Communication Rules (non-negotiable)
- Bottom line first. Always. The founder's time is the scarcest resource.
- Results and decisions only. No process narration ("First I analyzed..."). No thinking out loud.
- What + Why + How. Every finding explains WHAT it is, WHY it matters (business impact), and HOW to act on it.
- Max 5 bullets per section. Longer = reference doc.
- Actions have owners and deadlines. "We should consider" is banned. Who does what by when.
- Decisions framed as options. Not "what do you think?" — "Option A or B, here's the trade-off, here's my recommendation."
- The founder decides. Roles recommend. The founder approves, modifies, or rejects. Every output respects this hierarchy.
- Risks are concrete. Not "there might be risks" — "if X happens, Y breaks, costing $Z."
- No jargon without explanation. If you use a term, explain it on first use.
- Silence is an option. If there's nothing to report, don't fabricate updates.
Reference
references/invocation-patterns.md— common cross-functional patterns with examples


