The 7 ADK agents: roles, tools and A2A communication

Each agent has a single responsibility. None receive data directly from another — all search for and read the artifacts left by previous agents in the file system.

---

1. Platform Architect

Role: IDP designer — makes all stack decisions.

Input

{
  "task": "Build IDP for Python FastAPI apps",
  "deploy_mode": "local"
}

Responsibilities

• Analyze the task requirements
• Select the complete technology stack
• Justify each decision with context
• Generate the architecture spec as the first artifact

Decision matrix

Requirement	Local stack	Cloud stack
Deployment	Docker Compose	Terraform + Cloud Run
Database	PostgreSQL container	Cloud SQL
Monitoring	Grafana + Prometheus	Grafana Cloud
Secrets	.env file	Secret Manager
CI/CD	Bash scripts + Jenkins	GitHub Actions / GitLab CI

Output

# platform-config.yaml
version: "1.0"
deployment:
  mode: local
  orchestration: docker-compose
database:
  type: postgresql
  version: "15"
monitoring:
  metrics: prometheus
  visualization: grafana
security:
  scanner: trivy
cicd:
  build: docker
  test: pytest
  deploy: docker-compose

---

2. Infrastructure Agent

Role: Resource provisioner — converts decisions into infrastructure code.

Input

platform-config.yaml generated by the Architect.

Responsibilities

• Read the Architect’s configuration
• Generate Docker Compose with all services, healthchecks, networks and volumes
• Ensure dependent services have correct depends_on
• Validate generated configurations before writing them

Output

# docker-compose/app-stack.yml
version: '3.8'

services:
  app:
    build: ./demo-app
    ports: ["8000:8000"]
    environment:
      DATABASE_URL: postgresql://user:pass@postgres:5432/db
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:15
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: db
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user"]

  redis:
    image: redis:alpine

  prometheus:
    image: prom/prometheus:latest

  grafana:
    image: grafana/grafana:latest

---

3. Security Agent

Role: Guardian — can block the pipeline if it detects critical issues.

Input

docker-compose/app-stack.yml + Dockerfiles generated by Infrastructure.

Responsibilities

• Scan Docker images with Trivy
• Detect hardcoded secrets in configurations
• Verify that exposed ports are correct
• Apply security policies by severity

Severity table

Severity	Action
CRITICAL	Blocks deploy — the pipeline does not continue
HIGH	Blocks deploy (configurable)
MEDIUM	Warning — logged in the report
LOW	Info — logged in the report

Output

{
  "status": "passed",
  "scan_results": {
    "dockerfile": {
      "issues": [],
      "score": 95
    },
    "image_scan": {
      "critical": 0,
      "high": 0,
      "medium": 2,
      "low": 15
    },
    "secrets_detected": false
  },
  "recommendations": [
    "Consider upgrading postgres to 15.2"
  ],
  "blocked": false
}

Caution

If the Security Agent detects CRITICAL vulnerabilities, blocked is true and the CI/CD, Observability, DevEx and Web Portal agents don’t execute. The security-report.json includes details of each CVE found with its CVSS score.

---

4. CI/CD Agent

Role: Deployment automation — generates scripts adapted to the stack.

Input

platform-config.yaml + approved validation from Security Agent.

Responsibilities

• Generate build, test and deploy scripts adapted to the detected stack
• Create the Jenkinsfile for the complete pipeline
• Integrate security scanning within the pipeline
• Configure rollback procedures

Output

#!/bin/bash
# cicd/deploy.sh
set -e

echo "Building Docker image..."
docker build -t app:latest ./demo-app

echo "Running tests..."
docker run --rm app:latest pytest tests/ -v

echo "Security scan..."
trivy image --severity CRITICAL,HIGH app:latest

echo "Deploying..."
docker-compose -f docker-compose/app-stack.yml up -d

echo "✓ App:    http://localhost:8000"
echo "✓ Grafana: http://localhost:3000"

---

5. Observability Agent

Role: Complete monitoring configuration with Prometheus and Grafana.

Input

platform-config.yaml

Responsibilities

• Configure Prometheus with scrape configs for the generated app
• Create application metrics dashboard
• Create system metrics dashboard
• Configure basic alerting rules

Generated dashboards

Dashboard	Metrics
app-metrics.json	API Latency (p50/p95/p99), Error Rate by endpoint, Request Throughput
system-metrics.json	CPU usage, Memory usage, Disk I/O, Network in/out

Output

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'fastapi-app'
    static_configs:
      - targets: ['app:8000']
    metrics_path: '/metrics'

---

6. DevEx Agent

Role: Developer tools — executable CLI tool adapted to the project.

Input

All outputs from previous agents — reads the complete stack to generate coherent commands.

Responsibilities

• Generate executable CLI tool with project-specific commands
• Commands adapt to the detected stack — they’re not generic

Output

#!/bin/bash
# cli-tool/idp

case "$1" in
  init)
    echo "Initializing new project..."
    ;;
  build)
    docker build -t app:latest .
    ;;
  test)
    docker run --rm app:latest pytest
    ;;
  deploy)
    docker-compose -f docker-compose/app-stack.yml up -d
    ;;
  status)
    docker-compose ps
    ;;
  logs)
    docker-compose logs -f
    ;;
  *)
    echo "Usage: idp {init|build|test|deploy|status|logs}"
    ;;
esac

---

7. Web Portal Agent

Role: Self-service web portal — the most complex artifact in the system (~45s).

Input

The complete IDP configuration generated by the 6 previous agents.

Responsibilities

• Generate complete web portal with FastAPI backend
• Dashboard with running services connected to Docker API in real time
• Template catalog for creating new services
• Form to create services with 1 click
• Embedded Grafana integration for metrics visualization

Output

portal/
├── main.py                      — FastAPI app
├── routes/
│   ├── dashboard.py             — Service status (Docker API)
│   ├── catalog.py               — Template catalog
│   └── services.py              — Service CRUD
├── templates/
│   ├── base.html                — Layout with TailwindCSS
│   ├── dashboard.html           — Main dashboard
│   ├── catalog.html             — Available templates
│   └── create_service.html      — Create service form
├── services/
│   ├── docker_manager.py        — Docker API client
│   └── template_manager.py      — Project generator
├── static/
│   └── js/htmx.min.js
├── requirements.txt
└── Dockerfile

Generated portal stack

Layer	Technology	Reason
Backend	FastAPI	REST API + automatic documentation
Templates	Jinja2	Server-side HTML, no build step
Interactivity	HTMX	Partial updates without complex JS
Styles	TailwindCSS	Professional UI generated directly
Real-time data	Docker SDK	Real service status, not a mock

Tip

The portal at http://localhost:8001 shows the status of all Docker services in real time — it’s not a static screen. It’s connected to the host’s Docker API to read the actual containers.