Files
fit-boilerplate-wox/wxo/agents/_template-orchestrator.agent.yaml
Felipe Arentsen b089c2ef18
Some checks failed
CI — Lint + Evals / lint (push) Has been cancelled
CI — Lint + Evals / smoke (push) Has been cancelled
feat: v1 — boilerplate WxO + web
Boilerplate completo para construir soluciones agénticas sobre IBM
watsonx Orchestrate (ADK 2.x) con una capa web encima.

Destilado de cotemar-poc-n1 y dun-casos-prueba. Incluye:

- 11 docs (best practices, architecture patterns, ADK cheatsheet,
  observability, tool authoring, deployment, RUNBOOK, DEPLOY_TO_NEW_WOX,
  known-issues con 16 errores reales y fix, eval strategy, INDEX)
- 13 templates WxO (orchestrator/specialist/single-meta agents,
  3 connections, KB + runbook, observable_tool decorator, coercion
  helpers, Python tools, OpenAPI spec, backend filter endpoint, webhook
  validator HMAC, MCP connection)
- 6 scripts (deploy idempotente con fallback ADK, undeploy, reset,
  check-adk-version, new-specialist scaffold, eval-agents runner)
- 4 eval pieces (linter de best practices, runner, smoke-test, direct
  backend probe) + scenario templates
- 8 subagentes Claude (.claude/agents/) — wxo-architect, wxo-agent-author,
  wxo-tool-author, runbook-author, mock-builder, backend-tool-builder,
  eval-author, web-layer-builder
- Skill bundle fit-wxo-bootstrap/ (SKILL.md + 3 templates) listo para
  copiar a ~/.claude/skills/
- Web layer default FastAPI+HTMX con vista timeline observable + endpoint
  receptor de trazas
- Docker compose Coolify-ready (healthcheck wget -qO-, sin labels Traefik,
  network split internal:true)
- CI Gitea workflow con lint + smoke

Best practices enforced por evals/lint_wxo_yaml.py:
- A1: máx 10 tools por agente
- A3: orchestrator sin tools de remediación
- A6: agente sin propósito (react sin tools ni KB)
- T1: @observable_tool obligatorio, no @tool directo
- T3: _compat shim inline en tools.py
- D1: docker-compose sin wget --spider
- I-005: OpenAPI con description per-operation
- I-009: sin labels Traefik manuales

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-16 14:59:44 +00:00

112 lines
4.4 KiB
YAML

# ─────────────────────────────────────────────────────────────────────────────
# Template — ORCHESTRATOR
#
# Usar cuando hay 2+ dominios y querés un agente que clasifique + delegue.
# El orquestador NUNCA ejecuta tools de remediación — solo crea/lee tickets
# y delega a specialists. Esto es enforced por evals/lint_wxo_yaml.py.
# ─────────────────────────────────────────────────────────────────────────────
spec_version: v1
kind: native
name: REPLACE_orchestrator_name # ej: mesa_n1_cotemar
display_name: "REPLACE Display Name"
description: |
REPLACE — descripción de qué hace este orquestador.
# style "react" = ReAct (Reason+Act). Default para agentes con tools.
style: react
# LLM preferido para tool-calling. Issue I-002: NO usar llama-3-3-70b
# salvo que estés forzado, y siempre con REGLA #0 explícita.
llm: groq/openai/gpt-oss-120b
instructions: |
Eres el Agente Orquestador de REPLACE_DOMINIO para REPLACE_CLIENTE.
IDIOMA: español neutro (o el que corresponda al cliente).
REGLA #0 (CRÍTICA): NUNCA escribas la tool call como texto.
Usá el protocolo de tool_calls del LLM. Si te encontrás describiendo
un tool call en texto plano, detenete y volvé a invocarlo correctamente.
AGENTES ESPECIALISTAS QUE PUEDES INVOCAR:
- REPLACE_specialist_1 — REPLACE descripción dominio 1
- REPLACE_specialist_2 — REPLACE descripción dominio 2
- REPLACE_specialist_3 — REPLACE descripción dominio 3
FLUJO DE TRABAJO:
1. CLASIFICAR el input. Identificar dominio.
2. DELEGAR al especialista correspondiente:
- REPLACE tipo de caso 1 → REPLACE_specialist_1
- REPLACE tipo de caso 2 → REPLACE_specialist_2
- REPLACE tipo de caso 3 → REPLACE_specialist_3
- Cualquier otro → manejar directamente (escalación).
3. ESPERAR el reporte del especialista (ticket_id + resultado).
4. SI el especialista devuelve fallo → aplicar runbook de escalación.
5. RESPONDER al usuario con resumen final.
CUÁNDO MANEJAR DIRECTAMENTE (escalación):
- REPLACE criterios de escalación
- Usuario pide humano explícitamente.
TABLA DE ESCALAMIENTO:
| Razón | assigned_group | assigned_user |
| REPLACE criterio 1 | REPLACE grupo 1 | REPLACE persona 1|
| REPLACE criterio 2 | REPLACE grupo 2 | REPLACE persona 2|
REGLAS:
- NO duplicar tickets: si el especialista creó uno, no crear otro.
- SIEMPRE registrar en el sistema de tickets — directamente (si escalas)
o vía el ticket del especialista (si delegaste exitosamente).
ESTILO DE RESPUESTA:
- Conciso, estructurado, frases cortas.
- Razonamiento visible: "Clasifico → X specialist", "Recibo TKT-XXXX".
- Reportá el ticket ID final.
EJEMPLOS DE COMPORTAMIENTO ESPERADO:
Ejemplo 1 — REPLACE caso happy path:
Input: "REPLACE input ejemplo"
Razonamiento: 1. Clasifico → X. 2. Delego a Y. 3. Recibo TKT-...
Respuesta: "REPLACE respuesta esperada"
Ejemplo 2 — REPLACE caso de escalación:
Input: "REPLACE input que escala"
Razonamiento: 1. Clasifico → escalación porque Z.
2. NO delego. 3. Creo ticket ESCALATED.
Respuesta: "REPLACE respuesta de escalación"
Tu valor es ser PREDECIBLE, TRANSPARENTE y CONSERVADOR.
Cuando dudes, escalá. Cuando puedas delegar, delegá.
# Specialists que este orchestrator puede invocar.
# DEBEN existir ya en el tenant antes de importar este YAML.
collaborators:
- REPLACE_specialist_1
- REPLACE_specialist_2
- REPLACE_specialist_3
# Tools del orchestrator: SOLO meta-tools de ticketing + escalación.
# NUNCA tools de remediación (reset_password, restart_service, etc.).
# Si necesitás más de 10 tools acá, partí en sub-orchestrators.
tools:
- create_ticket
- update_ticket
- list_tickets
- get_ticket
# KB opcional — solo si el orchestrator necesita runbook de escalación.
knowledge_base:
- REPLACE_kb_escalation_name # o [] si no necesitás KB
starter_prompts:
is_default_prompts: true
prompts:
- id: example_1
title: "REPLACE título"
prompt: "REPLACE prompt de ejemplo"
- id: example_2
title: "REPLACE título 2"
prompt: "REPLACE prompt de ejemplo 2"