a2a-communicator

name	A2A Communicator
description	Inter-group communication skill implementing the A2A (Agent-to-Agent) protocol for information exchange between Skill Cells.
metadata	{"model":"inherit","version":"1.0.0","type":"utility-communicator"}

🔗 A2A Communicator (Agent-to-Agent)

This skill implements the Agent-to-Agent (A2A) communication protocol to allow information exchange between different Skill Cells of the Conglomerate.

Purpose

The A2A Communicator is the "voice" of each group. When an Orchestrator needs information or services from another group, it uses this skill to send and receive messages in a standardized way.

When to Use This Skill

• When the Orchestrator needs information from another group
• To request artifacts generated by another Cell
• To coordinate tasks requiring inter-group collaboration
• To verify the status of tasks in other groups

When NOT to Use This Skill

• For communication within the same group (use direct delegation)
• For tasks an internal specialist can resolve
• When there are no dependencies on other groups

Communication Protocol

A2A Message Structure

message:
  trace_id: "uuid-v4"           # Unique ID for tracing
  hop_count: 0                  # Hop counter (max 5)
  source_group: "10-backend"    # Source group
  target_group: "20-frontend"   # Target group
  request_type: "query|task|artifact"
  payload:
    question: "What fields does the registration form require?"
    context: "Designing user table"
  priority: "low|medium|high"
  timeout_seconds: 30

Response Structure

response:
  trace_id: "uuid-v4"           # Same ID as request
  status: "success|error|timeout"
  source_group: "20-frontend"
  payload:
    answer: "Mandatory fields are: name, email, password"
    artifacts: []               # Paths to generated artifacts
  processing_time_ms: 150

Communication Flow

Step 1: Prepare Request

1. Identify target group
2. Formulate clear and specific question/task
3. Include minimum necessary context (not all context)
4. Generate unique trace_id

Step 2: Validate Hops

1. Verify current hop_count
2. If hop_count >= MAX_HOPS (5), abort with error
3. Increment hop_count by 1

Step 3: Send Message

1. Locate target group's Orchestrator
2. Transmit structured message
3. Set timeout

Step 4: Receive Response

1. Wait for response within timeout
2. Validate response structure
3. Extract relevant information
4. Return to requesting Orchestrator

Infinite Loop Prevention

[!CAUTION] Hop Limit (Max Hops): 5

Each message carries a hop_count counter. If it reaches 5, the request is automatically rejected to prevent infinite loops.

Cycle Detection

The system also detects cycles via trace_id:

• If a group receives a message with a trace_id it already processed
• The request is rejected with CYCLE_DETECTED error

Usage Examples

Example 1: Backend asks Frontend

Scenario: Backend Orchestrator is designing the database and needs to know required registration form fields.

# Request from Backend to Frontend
message:
  trace_id: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
  hop_count: 0
  source_group: "10-backend-group"
  target_group: "20-frontend-group"
  request_type: "query"
  payload:
    question: "What fields are mandatory in the registration form?"
    context: "Designing user table in PostgreSQL"
  priority: "high"

# Response from Frontend
response:
  trace_id: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
  status: "success"
  source_group: "20-frontend-group"
  payload:
    answer: |
      Mandatory fields:
      - name (string, max 100 chars)
      - email (string, valid)
      - password (string, min 8 chars)
      
      Optional fields:
      - phone (string, optional)
      - avatar_url (string, optional)

Example 2: Frontend requests endpoint from Backend

message:
  trace_id: "b2c3d4e5-f6a7-8901-bcde-f23456789012"
  hop_count: 1
  source_group: "20-frontend-group"
  target_group: "10-backend-group"
  request_type: "query"
  payload:
    question: "What is the endpoint to create a user?"
    context: "Implementing registration form"
  priority: "medium"

Example 3: DevOps requests requirements from Security

message:
  trace_id: "c3d4e5f6-a7b8-9012-cdef-345678901234"
  hop_count: 0
  source_group: "30-devops-group"
  target_group: "40-security-group"
  request_type: "task"
  payload:
    task: "Review Kubernetes configuration for compliance"
    artifacts:
      - "skills/30-devops-group/manifests/deployment.yaml"
  priority: "high"

Error Handling

Error Code	Description	Action
MAX_HOPS_EXCEEDED	5 hops limit exceeded	Abort and report to user
CYCLE_DETECTED	Communication cycle detected	Abort and report
GROUP_NOT_FOUND	Target group does not exist	Check registry.yaml
TIMEOUT	Response did not arrive in time	Retry or report
INVALID_MESSAGE	Malformed message	Fix and resend

Configuration

Communication configuration is found in:

• registry.yaml

communication:
  max_hops: 5
  timeout_seconds: 30
  retry_attempts: 3

Best Practices

1. Minimal Context: Send only necessary information, not all context
2. Specific Questions: Avoid vague or too general questions
3. Appropriate Priority: Use high only when critical
4. Reasonable Timeouts: Adjust based on request complexity
5. Error Handling: Always implement fallbacks for errors