A2A 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

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