# A2A Communicator

> Inter-group communication skill implementing the A2A (Agent-to-Agent) protocol for information exchange between Skill Cells.

- Skill: `scaleto/a2a-communicator` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add scaleto/a2a-communicator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/scaleto/a2a-communicator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: scaleto (https://skillmd.com/u/scaleto)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/scaleto/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

```yaml
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

```yaml
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.

```yaml
# 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"
```

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

```yaml
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

```yaml
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](../../00-master-architect/registry.yaml)

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