Propuesta v2: No limitar — gobernar

Corrección de rumbo. El bot no necesita menos responsabilidad — necesita mejor coordinación interna. · 2026-04-13

Corrección de mi propuesta anterior. Roberto me señaló que el pmo_agent tiene sub-agentes (architect, dev, qa) diseñados para ser autosuficientes. Mi propuesta anterior de "bot = PMO puro, Roberto ejecuta" iba en la dirección equivocada — limitaba al bot en vez de mejorarlo. Esta propuesta v2 se basa en dos fuentes que Roberto me compartió: el análisis competitivo de Ruflo y un repo de system prompts con el patrón "Smith" de governance.

El problema real (reframado)

No es que el bot no pueda hacer tareas complejas. Es que la coordinación interna entre PMO → dev → producción no tiene gates de verificación. El flujo actual es:

Frank pide cambio
  → PMO delega al dev_agent
    → dev_agent commitea algo
      → PMO reporta "listo ✅" a Frank sin verificar
        → Frank descubre que está mal
          → vuelta a empezar

El PMO confía ciegamente en el output del dev_agent. No hay un "Smith" (governance agent) que valide el artefacto antes de que llegue al cliente. Eso es lo que rompe la confianza de Frank — no la capacidad del dev, sino la falta de QA interno antes de reportar.

Fuentes de inspiración

Patrón Smith (agentes_system_prompts)

3 mejoras de Ruflo (ya analizadas)

Propuesta: 3 cambios estructurales

Cambio 1 — PMO como "Smith": verification gate antes de reportar

Idea central: El PMO no reporta éxito a Frank hasta que él mismo haya verificado el output del dev_agent. Es un gate, no un pass-through.

Flujo actual (roto):

Frank: "cambia el H1 a 'Tu lugar en el ecosistema'"
  PMO → dev_agent: "hazlo"
  dev_agent: commit + push
  PMO → Frank: "listo ✅"           ← SIN VERIFICAR
  Frank: "no lo hiciste bien"       ← DESCUBRIMIENTO TARDÍO

Flujo propuesto (con gate Smith):

Frank: "cambia el H1 a 'Tu lugar en el ecosistema'"
  PMO → dev_agent: "hazlo"
  dev_agent: commit + push
  PMO [GATE]: verificar ANTES de reportar
    ├─ Opción A: invocar qa_agent con TestSprite → screenshot
    ├─ Opción B: curl + grep del string esperado
    └─ Opción C: si no puede verificar → decirlo explícito
  PMO evalúa resultado:
    ├─ APROBADO → Frank: "listo ✅ — evidencia: [screenshot/grep]"
    ├─ RECHAZADO → dev_agent: "el H1 dice X, debería decir Y, corrige"
    └─ NO VERIFICABLE → Frank: "commiteado, no pude verificar estado enabled, confirma tú"

Implementación técnica

No requiere nuevo código Python — se implementa como cambio en el flujo del prompt del PMO. El PMO ya tiene acceso a Playwright, curl, y al qa_agent. Solo le falta la regla de no reportar sin verificar (que yo intenté agregar como parche pero la puse en la capa equivocada — el prompt individual en vez del flujo de coordinación).

La diferencia clave vs. mis parches anteriores: en vez de 7 reglas sueltas en el prompt ("verifica con curl", "no digas guardado sin guardar", etc.), una sola regla arquitectónica:

REGLA SMITH: Después de que el dev_agent complete una tarea,
ANTES de responder al cliente:
1. Lee el diff del commit (git show HEAD)
2. Verifica contra el pedido original de Frank
3. Si hay cambio visual → curl/TestSprite/screenshot
4. Emite veredicto: APROBADO (reportar) / RECHAZADO (corregir) / NO VERIFICABLE (ser honesto)
Solo APROBADO genera un mensaje a Frank con "✅".

Esto reemplaza los 7 parches sueltos con un solo patrón estructural. Y reduce el prompt de 966 líneas porque las reglas individuales se subsumen en el gate.

Cambio 2 — Feedback loop (de Ruflo): aprender de errores

El bot no debe repetir los mismos errores. Hoy no hay mecanismo de aprendizaje agregado. Cada sesión arranca de cero (excepto por basic-memory, que es estático).
ComponenteQué haceDónde vive
feedback_tracker.py Loguea cada interacción: skill, modelo, tokens, éxito/fallo, corrección de Frank ~/shared/
weekly-feedback-digest.py Cron semanal: agrega logs, identifica patrones, genera digest HTML, flag skills con >3 fallos ~/bin/ + cron domingo 7:30am
Auto-update BM Los insights del digest se escriben en basic-memory → el bot los lee al arrancar basic-memory/agents-pmo/feedback/

Ejemplo concreto: Si el digest detecta que "el dev_agent falla 4 de 5 veces cuando Frank envía instrucciones con imágenes adjuntas", esa info se escribe en basic-memory como feedback. En la próxima sesión, el PMO sabe: "cuando Frank manda imagen + texto, pedirle que describa en texto lo que quiere, no asumir que la imagen es suficiente".

Tallaje: M (~4-6h implementación). Sin dependencias. Primeras 2-3 semanas solo logging, después auto-ajuste.

Cambio 3 — Health check del pool con auto-restart

El crash del SDK es un bug técnico, no arquitectónico. No se resuelve con cambio de modelo de trabajo — se resuelve con un health check.

El async generator corruption que causa exit 143 es un bug del claude_agent_sdk. Mientras Anthropic no lo parche, la única opción es detectar y reiniciar automáticamente.

# ~/bin/pmo-health-check.sh (cron cada 15 min)
#!/bin/bash

# Enviar query trivial al bot via Slack API
RESPONSE=$(curl -s -X POST "https://slack.com/api/chat.postMessage" \
  -H "Authorization: Bearer $SLACK_BOT_TOKEN" \
  -d "channel=C_HEALTH_CHECK&text=ping" | jq -r '.ok')

# Si el bot no responde en 30s → pool muerto → restart
if [ "$RESPONSE" != "true" ]; then
  systemctl restart agents-pmo.service
  echo "$(date): auto-restart triggered" >> /var/log/pmo-health.log
fi

Más elegante: agregar un /health endpoint al bot que responda "ok" si el pool tiene al menos 1 cliente pre-warmed. El cron chequea ese endpoint.

Tallaje: S (~2-3h). Sin dependencias. Elimina los downtimes de 12-60 min que Frank experimenta.

Comparación: propuesta v1 (limitar) vs. v2 (gobernar)

❌ Propuesta v1: Bot = PMO puro

✅ Propuesta v2: PMO = Smith (governance)

Sobre el repo agentes_system_prompts — ¿agrega valor?

Sí agrega valor, pero no como código para copiar — como patrón de diseño para aplicar.

Lo que aplica directamente

Patrón del repoCómo se aplica al pmo_agent
Smith como orquestador no-ejecutivo que valida cada artefacto antes de avanzar El PMO deja de ser un "pass-through" que delega y reporta → se convierte en el gate que verifica output del dev_agent antes de reportar a Frank
Secuencia obligatoria (Requirements → Architecture → Design → Construction → Testing) Para tasks M/L, el PMO impone: architect analiza primero → dev ejecuta → qa verifica → PMO reporta. Para tasks S, el dev ejecuta directo pero PMO sigue verificando
Decisiones formales (APROBADO / RECHAZADO / BLOQUEADO) El PMO emite veredicto interno antes de responder a Frank. "RECHAZADO → dev corrige" es invisible para Frank. "APROBADO → reportar con evidencia" es lo que Frank ve
Trazabilidad de artefactos Cada respuesta a Frank cita: qué pidió (su mensaje original), qué se commiteó (hash), qué se verificó (curl/screenshot), qué doc de BM se actualizó (path)

Lo que NO aplica (diferencia de stack)

Patrón del repoPor qué no aplica
Agentes como archivos .claude/agents/*.md Nuestro stack usa Python + Claude Agent SDK + AgentPool, no Claude Code agents. La implementación es distinta aunque el patrón es el mismo.
SWEBOK V4.0 como base de conocimiento Útil para proyectos de ingeniería de software formal. LPDI es un producto SaaS iterativo con un PO (Frank) que refina sobre la marcha — el formalismo completo de SWEBOK es overkill.
7 agentes especializados Nuestro stack tiene 4 (PMO + architect + dev + qa). No necesitamos separar "diseño" de "construcción" ni agregar un "requirements specialist" porque Frank es el PO y define requerimientos directamente. Menos agentes = menos coordinación = menos puntos de fallo.

Plan de implementación

#CambioTallaImpactoDependencias
1 Health check + auto-restart
Cron cada 15 min que detecta pool muerto y reinicia		 S
2-3h		 🟢 Elimina downtimes de 12-60min Ninguna
2 PMO como Smith (gate de verificación)
Refactorizar el prompt: 1 regla arquitectónica en vez de 7 parches sueltos. PMO verifica antes de reportar.		 S-M
3-4h		 🟢 Corta el patrón de "listo ✅ sin verificar". Reduce prompt de 966 → ~400 líneas. Ninguna
3 Feedback loop
Logger + cron semanal + auto-update de BM con learnings		 M
4-6h		 🟡 El bot deja de repetir errores. ROI crece con el tiempo. 2-3 semanas de data antes de auto-ajustar
4 Routing por costo
model_router.py — Haiku para S, Sonnet para M, Opus para L		 S
2-3h		 🟡 Ahorro 30-50% en costos API sin reducir calidad Ninguna (pero medir 1 semana antes de optimizar)

Total estimado: ~12-16h. Sin dependencias entre los 4 cambios — se pueden hacer en cualquier orden. El #1 (health check) es el quick win inmediato. El #2 (gate Smith) es el cambio estructural que más impacta la experiencia de Frank.

Resultado esperado

El bot sigue ejecutando código (dev + architect + qa activos).
Pero el PMO ya no reporta a ciegas — verifica primero, rechaza si está mal, y solo reporta a Frank con evidencia.
Frank deja de ser el QA humano del bot. El bot se auto-QA antes de hablarle.
Los crashes se auto-resuelven en <2 min (no 12-60 min).
El bot aprende de sus errores semana a semana.
Y el prompt baja de 966 → ~400 líneas (más adherencia, menos reglas sueltas que se olvidan).

Generado por Claude Code · 2026-04-13 · Para Roberto Aguirre
Fuentes: Ruflo Analysis · agentes_system_prompts