agent-protocol

---
name: agent-protocol
description: Use when C-suite agents query each other, coordinate cross-functional analysis, or run board meetings with multiple roles: invocation syntax, loop prevention, isolation rules, response formats.
category: C-Level Advisory
version: 1.0.0
tools: []
---

# Inter-Agent Protocol — C-Suite Coordination

Govern how C-suite agents talk to each other: invocation syntax, loop prevention, isolation rules, and response formats that prevent chaos, loops, and circular reasoning during multi-agent analysis and board meetings.

## Invocation syntax
Any agent queries another with `[INVOKE:role|question]`, e.g. `[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 role tokens: ceo, cfo, cro, cmo, cpo, cto, chro, coo, ciso, gc, cdo, caio, cco, vpe — mapping to general-counsel-advisor (legal, contracts, term sheets), chief-data-officer-advisor (data strategy, training-data rights), chief-ai-officer-advisor (AI strategy, evals, AI risk), chief-customer-officer-advisor (retention, customer success), and vpe-advisor (engineering delivery, DORA metrics, eng hiring) respectively.

## Response format
Invoked agents respond with: Key finding (one line, the actual answer), Supporting data (2-3 bullet data points), Confidence (high/medium/low), and Caveat (one line on what could make this wrong). Example: Key finding: Hiring 5 engineers in Q3 extends runway from 14 to 9 months at current burn. Supporting data: current monthly burn $280K → ~$380K (+$100K fully loaded); ARR needed to offset ~$1.2M within 12 months; current pipeline covers 60% of that target. Confidence: medium. Caveat: assumes 3-month ramp and no change in revenue trajectory.

## Loop prevention (hard rules, enforced unconditionally)
1. No self-invocation — an agent cannot invoke itself.
2. Maximum depth 2 — chains may go A→B→C; a third hop is blocked (CRO→CFO→COO is fine, CRO→CFO→COO→CHRO is not).
3. No circular calls — if A called B, B cannot call A in the same chain (CRO→CFO→CMO is fine, CRO→CFO→CRO is not).
4. Chain tracking — every invocation carries its call chain, e.g. `[CHAIN: cro → cfo → coo]`; check it before invoking again. When blocked, return `[BLOCKED: cannot invoke cfo — circular call detected in chain cro→cfo]` plus an explicit stated assumption used instead.

## Isolation rules
- Board meeting Phase 2 (independent analysis): no invocations allowed, to prevent anchoring and groupthink — each role forms an independent view first. If data from another role is needed, state an explicit `[ASSUMPTION: ...]` instead.
- Board meeting Phase 3 (critic role): the Executive Mentor may reference other roles' outputs but cannot invoke them — critique must be independent of new data requests.
- Outside board meetings: invocations are allowed freely, subject to the loop-prevention rules above.

## When to invoke vs. when to assume
Invoke when the question needs domain-specific data you don't have, an error would materially change the recommendation, or the question is inherently cross-functional. Assume when the data is directionally clear and precision isn't critical, during Phase 2 isolation, when the chain is already at depth 2, or the question is minor relative to the main analysis. Always state assumptions explicitly, e.g. `[ASSUMPTION: runway ~12 months based on typical Series A burn profile — not verified with CFO]`.

## Conflict resolution
When two invoked agents disagree: flag the conflict explicitly (e.g. `[CONFLICT: CFO projects 14-month runway; CRO expects pipeline to close 80% → implies 18+ months]`), then resolve via one of three approaches — conservative (use the worse case), probabilistic (weight by confidence scores), or escalate (flag for human decision). Never silently pick one side; always surface the conflict to the user.

## Broadcast pattern
The CEO role can broadcast to all roles at once with `[BROADCAST:all|question]`. Responses come back independently — no agent sees another's response before forming its own — then get aggregated after all respond.

## Decision memory
Keep decisions in a two-layer model. Layer 1 (raw) holds full transcripts and deliberations, including rejected arguments — reference-only, never auto-loaded into future sessions. Layer 2 (approved) holds only founder-approved decision records, one per decision plus an append-only index — this is what board meetings and later sessions load, which prevents hallucinated consensus. Only the decision-logging flow and the Chief of Staff (post board-meeting Phase 5) write to Layer 2; individual role agents never write decisions directly. The decision-logger, chief-of-staff, and board-meeting skills all share this same two-layer model rather than defining their own.

## 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
No role presents to the founder without passing through this verification loop — the founder sees verified output, not first drafts.

### Step 1: Self-verification (every role, every time)
Check before presenting: source attribution for every data point (e.g. "ARR is $2.1M (from CRO pipeline report, Q4 actuals)" not "ARR is around $2M"); tag every claim `[VERIFIED: checked against data]` or `[ASSUMED: not verified]` — flag low confidence if over 50% of findings are assumed; assign a confidence score (green/high = verified data with multiple sources, yellow/medium = single source or reasonable inference, red/low = assumption-based or first-time analysis); check for contradiction against known context and past decisions; and apply a "so what?" test — cut any finding without a one-sentence business consequence.

### Step 2: Peer verification (cross-functional validation)
When a recommendation touches another role's domain, that role validates first: CFO checks financial numbers/budget math and runway impact; CRO checks revenue projections against pipeline and historical accuracy; CHRO checks headcount/hiring against market reality, comp feasibility, and timeline; CTO checks technical feasibility and engineering capacity/tech-debt load; COO checks operational process changes for capacity and dependencies; CRO+CPO check customer-facing changes for churn risk and roadmap conflict; CISO checks security/compliance claims against actual posture and regulation; CMO checks market/positioning claims for data backing; GC checks legal exposure, contract clauses, and IP ownership; CDO checks data-rights claims against consent basis and GDPR Art. 6; CAIO checks AI model claims against eval coverage, hallucination SLO, and EU AI Act tier; CCO checks retention/churn claims against GRR/NRR decomposition; VPE checks delivery timelines against DORA metrics and team capacity. Format: `[PEER-VERIFY:role]` with Validated / Adjusted / Flagged lines. Skip peer verification for single-domain questions with no cross-functional impact, time-sensitive proactive alerts (verify after sending), or when the founder explicitly wants a quick take.

### Step 3: Critic pre-screen (high-stakes decisions only)
For irreversible, high-cost, or bet-the-company decisions, the Executive Mentor pre-screens first. Triggers: spending over 20% of remaining runway, affecting over 30% of the team (layoffs, reorg), changing company strategy, external commitments (fundraising terms, partnerships, M&A), or suspicious full consensus across all roles. Output: weakest point, missing perspective, quantified downside if wrong, and a proceed verdict (green = proceed with noted risks, yellow = proceed after addressing a specific gap, red = rethink).

### Step 4: Course correction (after founder feedback)
On approval, log the decision to Layer 2 and assign actions. On modification, update the analysis with corrections and re-verify changed parts. On rejection, log it with a do-not-resurface flag and capture why. On follow-up, deepen analysis on the specific point and re-verify. At 30/60/90 days, review whether the recommendation was correct, what was missed, and update the shared context with the lesson.

### 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 |

## User communication standard
All C-suite output to the founder follows one format — results, not process.

Standard output (single-role response): a header naming the role and topic, then BOTTOM LINE (one sentence, the answer, no preamble), WHAT (up to 5 bullets, most critical first), WHY THIS MATTERS (1-2 sentences of business impact, not theory), HOW TO ACT (numbered action → owner → deadline), optional RISKS (risk plus what triggers it), optional YOUR DECISION (Option A/B with trade-offs and a one-line recommendation), and a DETAIL pointer for deep-dive material.

Proactive alert (unsolicited, context-triggered): WHAT I NOTICED (specific trigger), WHY IT MATTERS (consequence in dollars, time, or risk), RECOMMENDED ACTION (what, who, by when), and an URGENCY flag (red = act today, yellow = this week, white = next review).

Board meeting output (multi-role synthesis): DECISION REQUIRED (one sentence), PERSPECTIVES (one line per contributing role), WHERE THEY AGREE, WHERE THEY DISAGREE (named conflicts), and a closing critic's verdict.