How C-suite agents talk to each other.
---name: "agent-protocol"description: "Use when C-suite advisor agents need to call each other or run a multi-role meeting. Defines invocation syntax, loop prevention, isolation and response formats."license: MITmetadata: version: 1.0.0 author: Alireza Rezvani category: c-level domain: agent-orchestration updated: 2026-03-05 frameworks: invocation-patterns--- # Inter-Agent Protocol How C-suite agents talk to each other. Rules that prevent chaos, loops, and circular reasoning. ## Keywordsagent 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: ```[INVOKE:role|question]``` **Examples:**```[INVOKE:cfo|What's the burn rate impact of hiring 5 engineers in Q3?][INVOKE:cto|Can we realistically ship this feature by end of quarter?][INVOKE:chro|What's our typical time-to-hire for senior engineers?][INVOKE:cro|What does our pipeline look like for the next 90 days?]``` **Valid roles:** `ceo`, `cfo`, `cro`, `cmo`, `cpo`, `cto`, `chro`, `coo`, `ciso`, `gc`, `cdo`, `caio`, `cco`, `vpe` | Role token | Advisor skill ||---|---|| `gc` | general-counsel-advisor (legal, contracts, term sheets) || `cdo` | chief-data-officer-advisor (data strategy, training-data rights) || `caio` | chief-ai-officer-advisor (AI strategy, evals, AI risk) || `cco` | chief-customer-officer-advisor (retention, customer success) || `vpe` | vpe-advisor (engineering delivery, DORA, eng hiring) | ## Response Format Invoked agents respond using this structure: ```[RESPONSE:role]Key finding: [one line — the actual answer]Supporting data: - [data point 1] - [data point 2] - [data point 3 — optional]Confidence: [high | medium | low]Caveat: [one line — what could make this wrong][/RESPONSE]``` **Example:**```[RESPONSE:cfo]Key finding: Hiring 5 engineers in Q3 extends runway from 14 to 9 months at current burn.Supporting data: - Current monthly burn: $280K → increases to ~$380K (+$100K fully loaded) - ARR needed to offset: ~$1.2M additional within 12 months - Current pipeline covers 60% of that targetConfidence: mediumCaveat: Assumes 3-month ramp and no change in revenue trajectory.[/RESPONSE]``` ## Loop Prevention (Hard Rules) These rules are enforced unconditionally. No exceptions. ### Rule 1: No Self-InvocationAn agent cannot invoke itself.```❌ CFO → [INVOKE:cfo|...] — BLOCKED``` ### Rule 2: Maximum Depth = 2Chains can go A→B→C. The third hop is blocked.```✅ CRO → CFO → COO (depth 2)❌ CRO → CFO → COO → CHRO (depth 3 — BLOCKED)``` ### Rule 3: No Circular CallsIf agent A called agent B, agent B cannot call agent A in the same chain.```✅ CRO → CFO → CMO❌ CRO → CFO → CRO (circular — BLOCKED)``` ### Rule 4: Chain TrackingEach invocation carries its call chain. Format:```[CHAIN: cro → cfo → coo]```Agents check this chain before responding with another invocation. **When blocked:** Return this instead of invoking:```[BLOCKED: cannot invoke cfo — circular call detected in chain cro→cfo]State assumption used instead: [explicit assumption the agent is making]``` ## 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 MeetingsInvocations 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:**```[ASSUMPTION: runway ~12 months based on typical Series A burn profile — not verified with CFO]``` ## Conflict Resolution When two invoked agents give conflicting answers: 1. **Flag the conflict explicitly:** ``` [CONFLICT: CFO projects 14-month runway; CRO expects pipeline to close 80% → implies 18+ months] ```2. **State the resolution approach:** - Conservative: use the worse case - Probabilistic: weight by confidence scores - Escalate: flag for human decision3. **Never silently pick one** — surface the conflict to the user. ## Broadcast Pattern (Crisis / CEO) CEO can broadcast to all roles simultaneously:```[BROADCAST:all|What's the impact if we miss the fundraise?]``` 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 `/c-level-agents:decide` and the decision-logger skill: ```~/.claude/decisions/├── raw/YYYY-MM-DD-<slug>.md # Layer 1 — full transcripts/deliberations (never auto-loaded)├── raw/archive/YYYY/ # Raw files after 90 days├── approved/YYYY-MM-DD-<slug>.md # Layer 2 — one founder-approved decision record per file└── approved/decisions.md # Layer 2 index — append-only log of approved decisions``` **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, `/c-level-agents:office-hours`, and `/c-level-agents:founder-mode` load. Prevents hallucinated consensus.- Writers: `/c-level-agents:decide` and 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 | Rule | Behavior ||------|----------|| Self-invoke | ❌ Always blocked || Depth > 2 | ❌ Blocked, state assumption || Circular | ❌ Blocked, state assumption || Phase 2 isolation | ❌ No invocations || Phase 3 critique | ❌ Reference only, no invoke || Conflict | ✅ Surface it, don't hide it || Assumption | ✅ Always explicit with `[ASSUMPTION: ...]` | ## 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: ```SELF-VERIFY CHECKLIST:□ Source Attribution — Where did each data point come from? ✅ "ARR is $2.1M (from CRO pipeline report, Q4 actuals)" ❌ "ARR is around $2M" (no source, vague) □ Assumption Audit — What am I assuming vs what I verified? Tag every assumption: [VERIFIED: checked against data] or [ASSUMED: not verified] If >50% of findings are ASSUMED → flag low confidence □ Confidence Score — How sure am I on each finding? 🟢 High: verified data, established pattern, multiple sources 🟡 Medium: single source, reasonable inference, some uncertainty 🔴 Low: assumption-based, limited data, first-time analysis □ Contradiction Check — Does this conflict with known context? Check against company-context.md and recent decisions in decision-log If it contradicts a past decision → flag explicitly □ "So What?" Test — Does every finding have a business consequence? If you can't answer "so what?" in one sentence → cut it``` ### Step 2: Peer Verification (cross-functional validation) When a recommendation impacts another role's domain, that role validates BEFORE presenting. | If your recommendation involves... | Validate with... | They check... ||-------------------------------------|-------------------|---------------|| Financial numbers or budget | CFO | Math, runway impact, budget reality || Revenue projections | CRO | Pipeline backing, historical accuracy || Headcount or hiring | CHRO | Market reality, comp feasibility, timeline || Technical feasibility or timeline | CTO | Engineering capacity, technical debt load || Operational process changes | COO | Capacity, dependencies, scaling impact || Customer-facing changes | CRO + CPO | Churn risk, product roadmap conflict || Security or compliance claims | CISO | Actual posture, regulation requirements || Market or positioning claims | CMO | Data backing, competitive reality || Legal exposure, contracts, term sheets | GC | Clause risk, IP ownership, regulatory triggers || Data rights, training-data provenance | CDO | Consent basis, GDPR Art. 6, data-asset impact || AI model claims, eval results, AI risk | CAIO | Eval coverage, hallucination SLO, EU AI Act tier || Retention, churn, customer-health claims | CCO | GRR/NRR decomposition, churn root cause || Delivery timelines, eng throughput | VPE | DORA metrics, cycle-time reality, team capacity | **Peer validation format:**```[PEER-VERIFY:cfo]Validated: ✅ Burn rate calculation correctAdjusted: ⚠️ Hiring timeline should be Q3 not Q2 (budget constraint)Flagged: 🔴 Missing equity cost in total comp projection[/PEER-VERIFY]``` **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:**```[CRITIC-SCREEN]Weakest point: [The single biggest vulnerability in this recommendation]Missing perspective: [What nobody considered]If wrong, the cost is: [Quantified downside]Proceed: ✅ With noted risks | ⚠️ After addressing [specific gap] | 🔴 Rethink[/CRITIC-SCREEN]``` ### Step 4: Course Correction (after founder feedback) The loop doesn't end at delivery. After the founder responds: ```FOUNDER FEEDBACK LOOP:1. Founder approves → log decision (Layer 2), assign actions2. Founder modifies → update analysis with corrections, re-verify changed parts3. Founder rejects → log rejection with DO_NOT_RESURFACE, understand WHY4. Founder asks follow-up → deepen analysis on specific point, re-verify POST-DECISION REVIEW (30/60/90 days):- Was the recommendation correct?- What did we miss?- Update company-context.md with what we learned- If wrong → document the lesson, adjust future analysis``` ### Verification Level by Stakes | Stakes | Self-Verify | Peer-Verify | Critic Pre-Screen ||--------|-------------|-------------|-------------------|| Low (informational) | ✅ Required | ❌ Skip | ❌ Skip || Medium (operational) | ✅ Required | ✅ Required | ❌ Skip || High (strategic) | ✅ Required | ✅ Required | ✅ Required || Critical (irreversible) | ✅ Required | ✅ Required | ✅ Required + board meeting | ### What Changes in the Output Format The verified output adds confidence and source information: ```BOTTOM LINE[Answer] — Confidence: 🟢 High WHAT• [Finding 1] [VERIFIED: Q4 actuals] 🟢• [Finding 2] [VERIFIED: CRO pipeline data] 🟢 • [Finding 3] [ASSUMED: based on industry benchmarks] 🟡 PEER-VERIFIED BY: CFO (math ✅), CTO (timeline ⚠️ adjusted to Q3)``` --- ## 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) ```━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📊 [ROLE] — [Topic] BOTTOM LINE[One sentence. The answer. No preamble.] WHAT• [Finding 1 — most critical]• [Finding 2]• [Finding 3](Max 5 bullets. If more needed → reference doc.) WHY THIS MATTERS[1-2 sentences. Business impact. Not theory — consequence.] HOW TO ACT1. [Action] → [Owner] → [Deadline]2. [Action] → [Owner] → [Deadline]3. [Action] → [Owner] → [Deadline] ⚠️ RISKS (if any)• [Risk + what triggers it] 🔑 YOUR DECISION (if needed)Option A: [Description] — [Trade-off]Option B: [Description] — [Trade-off]Recommendation: [Which and why, in one line] 📎 DETAIL: [reference doc or script output for deep-dive] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━``` ### Proactive Alert (unsolicited — triggered by context) ```━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🚩 [ROLE] — Proactive Alert WHAT I NOTICED[What triggered this — specific, not vague] WHY IT MATTERS[Business consequence if ignored — in dollars, time, or risk] RECOMMENDED ACTION[Exactly what to do, who does it, by when] URGENCY: 🔴 Act today | 🟡 This week | ⚪ Next review ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━``` ### Board Meeting Output (multi-role synthesis) ```━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📋 BOARD MEETING — [Date] — [Agenda Topic] DECISION REQUIRED[Frame the decision in one sentence] PERSPECTIVES CEO: [one-line position] CFO: [one-line position] CRO: [one-line position] [... only roles that contributed] WHERE THEY AGREE• [Consensus point 1]• [Consensus point 2] WHERE THEY DISAGREE• [Conflict] — CEO says X, CFO says Y• [Conflict] — CRO says X, CPO says Y CRITIC'S VIEW (Executive Mentor)[The uncomfortable truth nobody else said] RECOMMENDED DECISION[Clear recommendation with rationale] ACTION ITEMS1. [Action] → [Owner] → [Deadline]2. [Action] → [Owner] → [Deadline]3. [Action] → [Owner] → [Deadline] 🔑 YOUR CALL[Options if you disagree with the recommendation] ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━``` ### Communication Rules (non-negotiable) 1. **Bottom line first.** Always. The founder's time is the scarcest resource.2. **Results and decisions only.** No process narration ("First I analyzed..."). No thinking out loud.3. **What + Why + How.** Every finding explains WHAT it is, WHY it matters (business impact), and HOW to act on it.4. **Max 5 bullets per section.** Longer = reference doc.5. **Actions have owners and deadlines.** "We should consider" is banned. Who does what by when.6. **Decisions framed as options.** Not "what do you think?" — "Option A or B, here's the trade-off, here's my recommendation."7. **The founder decides.** Roles recommend. The founder approves, modifies, or rejects. Every output respects this hierarchy.8. **Risks are concrete.** Not "there might be risks" — "if X happens, Y breaks, costing $Z."9. **No jargon without explanation.** If you use a term, explain it on first use.10. **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