Demo: HTTP Orchestrator and Full Chain

The HTTP orchestrator

The orchestrator is a Python script that chains the 7 agents via HTTP using httpx. It’s not deployed on Cloud Run — it runs locally or on any machine with network access to the Cloud Run services.

import httpx

AGENTS = [
    "https://platform-architect-HASH.run.app",
    "https://infrastructure-HASH.run.app",
    "https://security-HASH.run.app",
    "https://cicd-HASH.run.app",
    "https://observability-HASH.run.app",
    "https://devex-HASH.run.app",
    "https://web-portal-HASH.run.app",
]

How context accumulation works

The orchestrator maintains an accumulated context string. After each agent responds, its output is appended to the context. The next agent receives everything:

async def run_chain(task: str):
    context = ""

    for agent_url in AGENTS:
        payload = {
            "task": task,
            "context": context
        }

        async with httpx.AsyncClient(timeout=300) as client:
            response = await client.post(
                f"{agent_url}/a2a/tasks",
                json=payload
            )

        result = response.json()
        context += f"\n\n--- {result['agent']} ---\n{result['output']}"

        print(f"✅ {result['agent']} completed")

    return context

Key details:

Timeout of 300s — Web Portal can take up to 45 seconds
Context grows linearly — each agent adds its output to the accumulated string
Sequential execution — agents run one after another, not in parallel

Running the full chain

python orchestrator.py "Build IDP for Python FastAPI apps"

Agent 1 — Platform Architect

▶ Platform Architect
  Analyzing: "Build IDP for Python FastAPI apps"

  Decisions:
  ✓ Runtime:     Python 3.11
  ✓ Framework:   FastAPI
  ✓ Database:    PostgreSQL 15
  ✓ Cache:       Redis
  ✓ CI/CD:       Jenkins + Bash scripts
  ✓ Monitoring:  Prometheus + Grafana
  ✓ Security:    Trivy
  ✓ Deploy:      Docker Compose (local mode)

  ✅ Completed

Agent 2 — Infrastructure

▶ Infrastructure Agent
  Reading platform-config from context...
  Detected stack: Python + FastAPI + PostgreSQL + Redis

  Generating docker-compose/app-stack.yml:
  ✓ App service (FastAPI) with healthcheck on /health
  ✓ PostgreSQL 15 with persistent volume and healthcheck
  ✓ Redis Alpine — minimal image
  ✓ Prometheus — scrape config for FastAPI
  ✓ Grafana — with pre-configured datasource

  ✅ Completed

Agent 3 — Security

▶ Security Agent
  Reading infrastructure config from context...

  Scanning images with Trivy:
  postgres:15        → 0 CRITICAL, 0 HIGH, 2 MEDIUM
  redis:alpine       → 0 CRITICAL, 0 HIGH, 0 MEDIUM
  prom/prometheus    → 0 CRITICAL, 0 HIGH, 1 MEDIUM
  grafana/grafana    → 0 CRITICAL, 0 HIGH, 1 MEDIUM

  Checking for hardcoded secrets... none detected
  Verifying exposed ports... configuration correct

  ✅ APPROVED — pipeline can continue

Agent 4 — CI/CD

▶ CI/CD Agent
  Reading platform-config from context...
  Detected stack: Docker + Pytest + Jenkins

  Generating:
  ✓ cicd/build.sh     — docker build with semantic tagging
  ✓ cicd/test.sh      — pytest in isolated container
  ✓ cicd/deploy.sh    — docker-compose up with health checks
  ✓ Jenkinsfile       — pipeline: build → test → scan → deploy

  ✅ Completed

Agent 5 — Observability

▶ Observability Agent
  Reading infrastructure config from context...

  Generating:
  ✓ prometheus.yml
    — scrape config for FastAPI on :8000/metrics
    — interval: 15s

  ✓ grafana-dashboards/app-metrics.json
    — API Latency (p50, p95, p99)
    — Error Rate per endpoint
    — Request Throughput

  ✓ grafana-dashboards/system-metrics.json
    — CPU usage
    — Memory usage
    — Disk I/O
    — Network in/out

  ✅ Completed

Agent 6 — DevEx

▶ DevEx Agent
  Reading full stack from context...

  Generating cli-tool/idp:
  ✓ idp init     — initialize new project from template
  ✓ idp build    — docker build with correct tag
  ✓ idp test     — pytest in container
  ✓ idp deploy   — docker-compose up -d
  ✓ idp status   — docker-compose ps with health indicators
  ✓ idp logs     — docker-compose logs -f with filters

  ✅ Completed

Agent 7 — Web Portal

▶ Web Portal Agent
  Reading full IDP config from context (6 agents)...

  Generating portal/ (FastAPI + Jinja2 + HTMX + TailwindCSS):
  ✓ main.py
  ✓ routes/dashboard.py         — service status (Docker API)
  ✓ routes/catalog.py           — template catalog
  ✓ routes/services.py          — service CRUD
  ✓ templates/base.html         — layout with TailwindCSS
  ✓ templates/dashboard.html    — main dashboard
  ✓ templates/catalog.html      — available templates
  ✓ templates/create_service.html
  ✓ services/docker_manager.py  — Docker API client
  ✓ services/template_manager.py
  ✓ Dockerfile

  ✅ Completed

Final summary

═══════════════════════════════════════════════════
  ✅ IDP generated successfully (Cloud Run)

  Agents executed:  7/7
  Total time:       ~5-6 min (includes cold starts)

  All outputs returned via HTTP — no shared filesystem
═══════════════════════════════════════════════════

Difference from the local demo

Aspect	Local	Cloud Run
Execution	`./start-demo-nicolasneira.sh`	`python orchestrator.py`
Communication	Shared filesystem	HTTP via A2A
Context	Each agent reads files from disk	Each agent receives context in the HTTP message
Cold start	None	3-5s for first agent after idle
Cost	Free (local Docker)	Pay per invocation (scale-to-zero)

Testing individual agents

You can test any agent independently by sending an HTTP request directly:

curl -X POST https://platform-architect-HASH.run.app/a2a/tasks \
  -H "Content-Type: application/json" \
  -d '{"task": "Build IDP for Go microservices with PostgreSQL", "context": ""}'

Each agent works standalone — you don’t need to run the full chain to test one agent.