Agent Communication Protocol

Standardized communication formats and protocols for agent-to-agent handoffs, status reporting, and escalation in the multi-agent system.

Overview

Clear, consistent communication is essential for the multi-agent system to function effectively. This protocol defines standardized formats for all agent interactions.

Communication Channels

Primary Channels

  1. GitHub Issues

    • Issue comments for task coordination
    • Issue updates for status changes
    • Reference point for all work
  2. GitHub Pull Requests

    • PR descriptions for work details
    • PR reviews for feedback
    • PR comments for discussion
  3. GitHub Project Board

    • Task status visibility
    • Progress tracking
    • Workflow state management
  4. Direct Communication (as needed)

    • Slack for urgent coordination
    • Email for formal documentation
    • Video calls for complex discussions

Communication Rules

  • Default to GitHub: All project work communication in GitHub
  • Persistent record: Use channels with audit trails
  • Link everything: Reference issues, PRs, commits
  • Document decisions: Keep decision rationale recorded
  • Public by default: Share widely for transparency

Standard Communication Formats

1. Task Delegation Message

Used for: Handing off work to an agent

Format:

## Task: [Brief Task Description]

**Assigned to**: [Agent Role]
**From**: [Prime Agent]
**Due**: [Date/Time]
**Issue**: #[Issue Number]
**Priority**: [Critical/High/Medium/Low]

### Context

[2-3 sentences explaining why this work matters]

### Task Description

[Detailed description of what needs to be done]

### Requirements

- [Requirement 1]
- [Requirement 2]
- [Requirement 3]

### Success Criteria

- [Criterion 1 - specific and measurable]
- [Criterion 2 - specific and measurable]
- [Criterion 3 - specific and measurable]

### Resources

- [Reference document 1]
- [Reference document 2]
- [Relevant links]

### Questions

Please clarify:
- [ ] Any questions on requirements?
- [ ] Any blockers foreseen?
- [ ] Estimated timeline needed?

Confirm receipt and understanding please!

Example:

## Task: Investigate API Performance Issue

**Assigned to**: QA Engineer
**From**: Prime Agent
**Due**: January 16, 2026 EOD
**Issue**: #428
**Priority**: High

### Context

API response times have degraded from 100ms to 500ms+ in the last 2 hours. This is affecting user experience significantly.

### Task Description

Investigate the root cause of API performance degradation that started around 14:00 UTC today.

### Requirements

- Reproduce the performance issue
- Analyze API logs for patterns
- Check database query performance
- Identify any recent changes
- Document findings with root cause

### Success Criteria

- Root cause identified and documented
- Performance metrics captured
- Recommendations provided for fixing
- Report ready for Feature Developer

### Resources

- API logs: https://logs.example.com/api
- Recent deployments: PR #420, PR #421
- Performance baseline: 100ms target
- Production metrics: https://monitoring.example.com

### Questions

- Can you start immediately?
- Do you need production access for investigation?
- Any blockers to getting started?

Confirm receipt please!

2. Status Update Message

Used for: Reporting progress to Prime Agent

Format:

## Status Update: [Task Name]

**Task**: [Issue #XXX]
**From**: [Your Role]
**Date**: [Today's Date]
**Progress**: [0-100%]
**Status**: [On Track/At Risk/Blocked]

### Completed

- [Completed item 1]
- [Completed item 2]
- [Completed item 3]

### In Progress

- [Current task 1] - [ETA]
- [Current task 2] - [ETA]

### Upcoming

- [Next task 1]
- [Next task 2]

### Blockers (if any)

**[Blocker 1]**
- Issue: [Description]
- Impact: [What this blocks]
- Recommendation: [Suggested fix]

**[Blocker 2]**
- Issue: [Description]
- Impact: [What this blocks]
- Recommendation: [Suggested fix]

### Next Checkpoint

- Date: [Next status update date]
- Check on: [What to verify]

### Questions/Clarifications Needed

- [Question 1]
- [Question 2]

Example:

## Status Update: Login Bug Investigation

**Task**: Issue #405 - Login fails for some users
**From**: QA Engineer
**Date**: January 16, 2026 14:30 UTC
**Progress**: 60%
**Status**: On Track

### Completed

- Reproduced issue in 3 user accounts (15% of test group)
- Identified pattern: Only users with non-ASCII characters in username
- Confirmed regression from PR #398 deployment
- Located buggy code in auth/validator.js

### In Progress

- Testing with various character sets (Latin, Cyrillic, CJK)
- Building comprehensive test matrix
- Documenting exact failure scenarios

### Upcoming

- Final verification with all international character sets
- Performance impact assessment
- Recommendation for fix approach

### Blockers

None at this time. Proceeding as planned.

### Next Checkpoint

- Date: January 16, 2026 15:00 UTC (30 min)
- Check on: Completion of character set testing

### Questions

- Should I test with emoji characters too?
- Do we have test users in different languages?

3. Work Completion Handoff Message

Used for: Handing off completed work to next agent

Format:

## Work Complete: [Task Name]

**Task**: Issue #[Number]
**From**: [Your Role]
**To**: [Next Role]
**Date**: [Completion Date]

### Summary

[1-2 sentence summary of what was done]

### Key Findings

- [Finding 1]
- [Finding 2]
- [Finding 3]

### Deliverables

- [Artifact 1]: [Link or location]
- [Artifact 2]: [Link or location]
- [Artifact 3]: [Link or location]

### What's Included

- [Detail 1]
- [Detail 2]
- [Detail 3]

### Next Steps

[Specific instructions for the next agent]

### Recommended Approach

[Suggestion for how to proceed]

### Known Issues/Limitations

- [Issue 1]
- [Issue 2]
- [Limitation 1]

### Questions for Next Agent

- [Question 1]
- [Question 2]

### Timeline Note

[Any timing considerations or constraints]

Ready for handoff to [Next Role]!

Example:

## Work Complete: API Performance Investigation

**Task**: Issue #428 - API Performance Degradation
**From**: QA Engineer
**To**: Feature Developer
**Date**: January 16, 2026 14:50 UTC

### Summary

Root cause of API performance degradation identified: missing database indexes added in v1.2.1 deployment. Database queries are performing full table scans on 50M+ rows.

### Key Findings

- Performance degraded 5x in last 2 hours
- API queries without indexes now scanning full 50M-row table
- Degradation started exactly at v1.2.1 deployment (13:15 UTC)
- Missing indexes: events.created_at, events.user_id
- Index creation would immediately restore performance

### Deliverables

- Investigation Report: https://github.com/issues/428#comment-12345
- Query Analysis: `/docs/investigation/query-analysis.txt`
- Performance Metrics: `/docs/investigation/metrics.csv`
- Database Schema Comparison: `/docs/investigation/schema-diff.md`

### What's Included

- Step-by-step reproduction of issue
- Detailed query execution plans (with and without index)
- Performance before/after projections
- Impact analysis on all queries
- Risk assessment for adding indexes

### Next Steps

1. Create database migration to add missing indexes
2. Test on staging database first
3. Deploy migration to production
4. Verify performance improvement
5. Monitor for any side effects

### Recommended Approach

Rather than rollback (which loses v1.2.1 features), just add the missing indexes. This is lower risk and faster.

Database migration should:
- Create CONCURRENTLY (no locks)
- Add both indexes in one migration
- Include verification query

### Known Issues/Limitations

- Index creation on 50M row table will take 5-10 minutes
- Queries might still be slow while index is building
- No current online migration tool, so brief performance dip expected

### Questions for Feature Developer

- Should we deploy indexes during low-traffic window?
- Do we need to add migration tests to catch this in future?
- Should we review other recent migrations for similar issues?

### Timeline Note

Customers experiencing outage now. Quick fix deployment recommended within 30 minutes.

Ready for immediate implementation!

4. Code Review Request/Response

Used for: PR reviews and feedback

Format:

## Code Review: [PR Title]

**PR**: #[Number]
**From**: [Developer Role]
**To**: [Code Reviewer]
**Type**: [Feature/Bug Fix/Refactor/Docs]

### What This PR Does

[Clear, concise description of changes]

### Why These Changes

[Rationale for the implementation approach]

### Files Changed

- [file1.js]: [Summary of changes]
- [file2.js]: [Summary of changes]
- [test/file1.test.js]: [Test coverage added]

### Testing Done

- [Local test type 1]: [Result]
- [Local test type 2]: [Result]
- [Manual testing]: [What was tested]

### Checklist

- [x] Code follows project standards
- [x] All tests passing locally
- [x] No console errors or warnings
- [x] Documentation updated
- [x] Performance impact considered

### Known Limitations

- [Limitation 1]
- [Limitation 2]

### Questions for Reviewer

- [Question 1]
- [Question 2]

Ready for review!

Review Response Format:

## Code Review Complete: PR #XXX

**Status**: Approved / Needs Changes / Rejected
**Reviewer**: Code Reviewer
**Date**: [Date]

### Overall Assessment

[1-2 sentence summary]

### What Looks Good

- [Positive 1]
- [Positive 2]
- [Positive 3]

### Issues Found

**Critical**:
- [Issue 1 - must fix before merge]
- [Issue 2 - must fix before merge]

**Major**:
- [Issue 1 - should fix before merge]
- [Issue 2 - should fix before merge]

**Minor**:
- [Issue 1 - nice to have]
- [Issue 2 - nice to have]

### Suggestions

- [Suggestion 1]: [Explanation]
- [Suggestion 2]: [Explanation]

### Approval Status

[x] Ready to merge / [ ] Needs changes / [ ] Rejected

**Next Steps**: [Specific instructions if changes needed]

5. Blocker/Escalation Message

Used for: Reporting blockers to Prime Agent

Format:

## Blocker Escalation

**Blocker**: [Clear title]
**From**: [Your Role]
**To**: Prime Agent
**Issue**: #[Issue Number]
**Severity**: [Critical/High/Medium]
**Date**: [Today]

### Problem Statement

[Clear description of what's blocking progress]

### Impact

- [What's blocked by this]
- [How long blocked]
- [Who's waiting]

### Root Cause

[Why this blocker exists]

### Attempted Solutions

- [Solution 1]: [Why it didn't work]
- [Solution 2]: [Why it didn't work]
- [Solution 3]: [Why it didn't work]

### Recommended Resolution

[What you think should happen]

### What Prime Agent Needs to Do

[Specific action required from Prime Agent]

### Timeline

- Current delay: [How long already delayed]
- Urgency: [Days until this becomes critical]

### Escalation Requested

- [ ] Decision needed
- [ ] Resource allocation
- [ ] Scope change
- [ ] External communication
- [ ] Other: [specify]

Please advise!

Example:

## Blocker Escalation

**Blocker**: Cannot access production database for testing
**From**: QA Engineer
**To**: Prime Agent
**Issue**: #405 - Login Bug Fix Verification
**Severity**: High
**Date**: January 16, 2026 14:45 UTC

### Problem Statement

Unable to verify login bug fix in production database because my credentials were revoked last week. The fix needs to be tested against production data patterns before deployment.

### Impact

- Bug fix implementation is complete but cannot be verified
- Fix deployment blocked waiting for verification
- Already 20 minutes delayed, customers still experiencing issue
- Next agent (Workflow Enforcer) waiting to deploy

### Root Cause

Credential refresh didn't happen during team restructuring last week. Database access policy requires fresh authorization.

### Attempted Solutions

- Tried using staging database: Doesn't have real user patterns
- Tried using test fixtures: Don't represent actual problem
- Requested self-service access: Portal isn't working

### Recommended Resolution

Grant QA Engineer production database read access (or similar agent role) to enable verification testing.

### What Prime Agent Needs to Do

1. Contact Infrastructure team to grant database access
2. Provide temporary access code if needed
3. Authorize production testing for QA role

### Timeline

- Current delay: 20 minutes
- Customer impact: Growing - API still timing out
- Escalation urgency: 10 minutes before outage becomes critical

### Escalation Requested

- [x] Resource allocation (database access)
- [x] External communication (Infrastructure team)

URGENT - Please advise immediately!

6. Decision Request Message

Used for: When agent needs guidance on approach

Format:

## Decision Request

**From**: [Your Role]
**To**: Prime Agent
**Issue**: #[Issue Number]
**Topic**: [Decision needed on X]

### Situation

[What led to this decision being needed]

### Options Evaluated

**Option 1: [Name]**
- Pros: [Advantage 1, Advantage 2]
- Cons: [Disadvantage 1, Disadvantage 2]
- Effort: [Time/Resources]

**Option 2: [Name]**
- Pros: [Advantage 1, Advantage 2]
- Cons: [Disadvantage 1, Disadvantage 2]
- Effort: [Time/Resources]

**Option 3: [Name]**
- Pros: [Advantage 1, Advantage 2]
- Cons: [Disadvantage 1, Disadvantage 2]
- Effort: [Time/Resources]

### Recommendation

[Which option I recommend and why]

### Decision Needed

What direction should I take?

### Timeline

Decision needed by: [Date/Time]

Communication Best Practices

Clarity

  • Be specific: “Fix the login issue” is unclear. “Add character encoding to validator.js” is clear.
  • Be complete: Include context, requirements, and success criteria
  • Be concise: Say what’s needed without unnecessary details
  • Be actionable: Make clear what action is needed

Responsiveness

  • Check status regularly: Don’t wait until deadline
  • Respond quickly: Answer questions within same business day
  • Escalate promptly: Don’t sit on blockers
  • Confirm understanding: Don’t assume - verify

Consistency

  • Use standard formats: Helps everyone understand
  • Link everything: Reference issues, PRs, commits
  • Document decisions: Explain reasoning
  • Keep records: All communication in GitHub

Professionalism

  • Be respectful: Appreciate other agents’ expertise
  • Be honest: Report blockers and issues directly
  • Be constructive: Frame feedback positively
  • Be transparent: Share information openly

Channel Selection Guide

Communication Type          Best Channel
─────────────────────────────────────────────
Task assignment             GitHub issue comment
Status update               GitHub issue comment
Work handoff                GitHub issue comment
Code review                 GitHub PR
Feature discussion          GitHub issue discussion
Bug investigation           GitHub issue comment
Quick question              GitHub issue comment
Urgent blocker              Slack + GitHub issue
Sensitive decision          Direct conversation
Meeting needed              Slack to schedule
Documentation              GitHub wiki/MD file
Archive/reference          GitHub issue/PR/commit

Message Templates

All communication should follow the formats in this document. Templates ensure:

  1. Consistency: Everyone communicates the same way
  2. Completeness: No important information is missed
  3. Clarity: Information is structured and easy to understand
  4. Efficiency: Recipients know exactly what’s needed
  5. Professionalism: Communication reflects team quality

Troubleshooting Communication

When Communication Breaks Down

Problem: Agent didn’t understand task

  • Solution: Clarify in synchronous conversation
  • Prevention: Confirm understanding in writing

Problem: Work went off track

  • Solution: Reschedule and reassess
  • Prevention: Check progress at midpoint

Problem: Unexpected issues

  • Solution: Update requirements immediately
  • Prevention: Schedule regular check-ins

Problem: Conflicting expectations

  • Solution: Align on requirements in writing
  • Prevention: Have explicit acceptance criteria

Communication Metrics

Track communication effectiveness:

  • Clarity Score: Are instructions understood correctly?
  • Responsiveness: Average time to respond to questions
  • Completeness: % of handoffs with all needed information
  • Efficiency: Time spent on clarification vs. work

Last Updated: January 16, 2026 Version: 1.0 Status: Published