Manage — Inter-agent communication protocol for C-suite agent teams. Defines invocation syntax, loop prevention, isolation rules, and response formats. Use when C-suite agents need to query
Manage — Inter-agent communication protocol for C-suite agent teams. Defines invocation syntax, loop prevention, isolation rules, and response formats. Use when C-suite agents need to query
[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?]
[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 target
Confidence: medium
Caveat: Assumes 3-month ramp and no change in revenue trajectory.
[/RESPONSE]
Loop Prevention (Hard Rules)
These rules are enforced unconditionally. No exceptions.
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 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:
[ASSUMPTION: runway ~12 months based on typical Series A burn profile — not verified with CFO]
Conflict Resolution
When two invoked agents give conflicting answers:
Flag the conflict explicitly:
[CONFLICT: CFO projects 14-month runway; CRO expects pipeline to close 80% → implies 18+ months]
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:
[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.
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
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]
The loop doesn't end at delivery. After the founder responds:
FOUNDER FEEDBACK LOOP:
1. Founder approves → log decision (Layer 2), assign actions
2. Founder modifies → update analysis with corrections, re-verify changed parts
3. Founder rejects → log rejection with DO_NOT_RESURFACE, understand WHY
4. 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 ACT
1. [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 ITEMS
1. [Action] → [Owner] → [Deadline]
2. [Action] → [Owner] → [Deadline]
3. [Action] → [Owner] → [Deadline]
🔑 YOUR CALL
[Options if you disagree with the recommendation]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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
Why This Skill Exists
Manage — Inter-agent communication protocol for C-suite agent teams. Defines invocation syntax, loop prevention, isolation rules, and response formats.
When to Use
Use this skill when C-suite agents need to query
What If Fails
If this skill fails to produce the expected output: (1) verify input completeness, (2) retry with more specific context, (3) fall back to the parent workflow without this skill.
