Por qué los roles importan dentro del squad
En un equipo humano de soporte bien gestionado, no todos hacen todo. Hay junior que atiende el tier 1; hay senior que resuelve casos complejos; hay team lead que hace coaching; hay QA que audita calidad. Cuando esa separación colapsa (todos hacen todo), la calidad baja, la carga se distribuye mal y los errores se multiplican.
Los squads IA tienen la misma lógica. El error frecuente es construir "un agente que hace todo" — responde, decide, ejecuta, audita, aprende. Parece simple; es inestable. La especialización por rol mejora precisión, permite observabilidad, facilita iteración, y hace el squad auditable.
Este artículo describe los cinco roles arquetípicos que aparecen en squads bien diseñados y cómo operarlos.
El rol 1: Operador (front-line)
Es el que habla con el cliente / usuario / sistema externo. Su job principal: entender intent, responder dentro de scope, y reconocer cuándo escalar.
Propiedades:
- Modelo adecuado a latencia (GPT-4o, Claude Haiku, Gemini Flash — según trade-off).
- Prompt optimizado para tono de marca.
- Acceso acotado a herramientas (tools): solo las necesarias para su función.
- Guardrails fuertes de input y output.
- Tiempo de respuesta target: < 2s para chat sincrónico.
Anti-pattern: darle al operador poder de ejecutar acciones irreversibles. Eso es rol de executor separado (siguiente).
KPIs del operador:
- Tiempo de primera respuesta.
- Tasa de escalación correcta (casos que debían escalar y lo hicieron).
- Tasa de respuesta aceptable sin corrección.
El rol 2: Executor
Cuando una acción tiene impacto real (actualizar CRM, ejecutar refund, modificar configuración, enviar email), no la hace el operador directo. La prepara el operador, la valida el executor, y recién entonces se ejecuta.
Propiedades:
- Modelo más determinístico (menor temperatura).
- Set de tools estructurado con input validation.
- Dry-run por default, activación explícita.
- Logging obsesivo de cada acción.
- Capaz de rechazar la acción propuesta si no cumple requisitos.
Por qué separar: el operador optimiza para conversación natural; el executor optimiza para no romper nada. Funciones distintas, perfiles distintos.
KPIs del executor:
- Error rate en ejecución.
- Acciones rechazadas que debían aceptarse (falsos rechazos).
- Acciones ejecutadas que debían rechazarse (daños reales).
El rol 3: Reviewer
Samplea output del operador y executor, compara con política y con historia, detecta deriva.
Propiedades:
- Puede ser otro LLM (cheaper, con prompt específico para review).
- Muestreo estadístico: 10-30% de interacciones, más alto si es squad nuevo.
- Evaluación contra criterios explícitos: precisión, tono, compliance, completitud.
- Output estructurado (score, flags, sugerencias).
Por qué no reviewer humano solo: volumen. Con 10.000 interacciones/día, humano sólo no llega. Reviewer IA hace primera pasada, humano profundiza muestra que el reviewer marca.
KPIs del reviewer:
- Concordancia con review humano (validar que el reviewer funciona).
- Cobertura de muestreo.
- Señal útil generada (tendencias detectadas que derivan en ajuste).
El rol 4: Auditor
Es un rol cross-squad con foco en compliance y riesgo. Más espaciado temporalmente que el reviewer (diario/semanal, no tiempo real).
Propiedades:
- Acceso a audit logs completos.
- Análisis de patrones: ¿hay bias? ¿deriva del modelo? ¿violación de política recurrente?
- Output: reporte periódico con flags.
- Integrado con obligaciones de compliance (ISO 27001, SOC 2, GDPR, regulación sectorial).
Humano en loop: el auditor IA prepara el paquete; responsable de compliance (humano) revisa y decide.
KPIs del auditor:
- Incidentes de compliance detectados proactivamente.
- Reportes entregados a tiempo.
- Findings accionables (vs ruido).
El rol 5: Supervisor humano
No es un agente IA; es la persona responsable del squad. Pero el rol está aquí porque sin él, el squad es huérfano.
Propiedades:
- Accountability operativa y política del squad.
- Tiempo dedicado: 20-50% según tamaño del squad.
- Autoridad para pausar, ajustar, expandir scope.
- Interface principal con otros equipos (producto, legal, compliance).
Tareas frecuentes del supervisor:
- Review de dashboard diario.
- Intervención en escalaciones complejas.
- Coaching de KB y prompts (qué sumar, qué quitar).
- Reporte semanal a dirección.
- Participación en roadmap de plataforma.
Cómo se orquestan los roles en una conversación real
Ejemplo: cliente escribe a soporte pidiendo cambio de plan.
- Operador recibe el mensaje, identifica intent ("cambio de plan"), hace preguntas clarificadoras (a qué plan, desde cuándo).
- Operador consulta al Executor con la acción propuesta: "cambiar cuenta X de plan A a plan B a partir del 1 de mayo".
- Executor valida: cliente tiene método de pago activo, no hay comprobante pendiente, plan B existe y disponible, precio calculado correctamente.
- Executor ejecuta vía API de billing, emite confirmación.
- Operador responde al cliente con confirmación y detalles.
- Reviewer (asíncrono) samplea esta conversación, evalúa que la respuesta fue precisa, tono adecuado, y sin oversharing de información.
- Auditor (asíncrono, semanal) analiza el lote: ¿hay patrón en cambios de plan que sugiere issue con comunicación de precios? ¿hay tiempo anormalmente alto?
- Supervisor humano ve en dashboard que todo se ejecutó bien; interviene si hay anomalía.
Este flujo tarda ~2-5 segundos para el cliente, pero tiene cuatro capas de verificación. Sin esa separación, un error del operador cambia el plan sin revisión.
Configuración en Fanfusion Hub
Cada rol se configura explícitamente:
squad: soporte-tier1
roles:
- name: operator
model: claude-3-5-sonnet
system_prompt: /prompts/support-operator.md
tools: [crm.read, product.read, ticket.create]
guardrails: [pii-filter, profanity-filter]
- name: executor
model: gpt-4o
system_prompt: /prompts/support-executor.md
tools: [crm.update, billing.change-plan, ticket.update]
guardrails: [action-validator]
approval_required: true # dry-run, supervisor confirma
- name: reviewer
model: claude-haiku # cheap
sampling_rate: 0.15
criteria: /criteria/support-review.md
output_schema: review-v1
- name: auditor
schedule: daily
scope: all-interactions
report_template: /templates/audit-daily.md
Esta especificación declarativa permite versionado, rollback, comparación A/B entre configuraciones.
Separación de permisos (RBAC interno al squad)
Cada rol tiene permisos mínimos:
- Operador: lectura amplia, ninguna escritura.
- Executor: escritura específica a su scope, nunca lectura adicional innecesaria.
- Reviewer: lectura de logs y outputs, ninguna acción.
- Auditor: lectura completa incluyendo audit logs, reports only.
- Supervisor humano: control completo incluyendo kill-switch.
Esto es el equivalente a separación de deberes en contabilidad. Si un rol compromete al otro, el daño queda acotado.
Errores comunes al diseñar roles
Error 1: collapsar operator y executor. "El mismo agente responde y ejecuta porque es más rápido". Sí, y cuando ejecuta mal no hay control.
Error 2: reviewer con los mismos criterios que el operador. Si usan el mismo modelo y prompt, el reviewer valida su propio error. Necesita criterios distintos.
Error 3: auditor sin autoridad. Produce reportes que nadie lee. Auditor debe tener línea directa al responsable de compliance.
Error 4: supervisor humano con 10 squads. Burn-out garantizado, review superficial. Máximo 3-4 squads estables por supervisor, 1-2 en fase inicial.
Error 5: no medir al reviewer. El reviewer también puede drift. Calibración periódica contra review humano es indispensable.
Evolución de roles con madurez del squad
Fase 1 (primer mes): supervisor humano revisa 100% de interacciones. Reviewer IA en paralelo para calibrar.
Fase 2 (meses 2-3): supervisor baja a 30-50% de muestreo. Reviewer sube a 20-30%. Se establece correlación entre ambos.
Fase 3 (meses 4-6): supervisor revisa 10-20% de muestreo más todas las escalaciones. Reviewer cubre 15-25%. Auditor arranca con cadencia semanal.
Fase 4 (mes 6+): régimen estable. Supervisor en dashboard, interviene en anomalías. Reviewer + auditor funcionan autónomos con reporte.
Cuándo NO separar roles
Casos donde collapsar roles es aceptable:
- Squad experimental de bajo volumen: < 100 interacciones/semana puede vivir con operador único + supervisor humano activo.
- Scope muy acotado sin ejecución: solo informativo, no cambia nada, solo responde FAQs públicas.
- Casos donde la separación genera más error que previene: si el handoff operator→executor tiene 30% de fallo, hay que repensar.
La guía: separar cuando el volumen justifica, o cuando el riesgo de una acción justifica control extra. No separar por principio filosófico sino por necesidad operativa.
Implementación técnica de los roles
La separación de roles no es solo organizacional — es arquitectónica. Cada rol puede ser un modelo IA distinto con prompt, temperatura, y permisos específicos:
Operador. Modelo rápido, bien calibrado para el dominio (ej. Claude Haiku, GPT-4o-mini). Temperatura 0.3-0.5 (consistencia alta, poca creatividad). Permisos: lectura de KB, escritura a canales del cliente, ejecución de acciones low-impact. Prompt enfocado en task-specific: "respondé consultas de soporte..."
Reviewer. Modelo más exhaustivo (ej. Claude Sonnet, GPT-4o). Temperatura 0 (determinístico). Permisos: lectura completa, escritura de reviews, bloqueo de outputs del operador. Prompt orientado a quality check: "evaluá si esta respuesta cumple política X, Y, Z..."
Auditor. Modelo de razonamiento (ej. Claude Opus, GPT-5). Temperatura 0. Permisos: lectura solamente + emisión de reports. Prompt diseñado para pattern detection: "analizá las últimas 1000 interacciones y detectá drift..."
Orquestador. Coordinador que invoca roles. Puede ser rule-based (más predecible) o agente meta. Maneja flujo: operador produce → reviewer aprueba/rechaza → si aprueba, se publica; si rechaza, loop o escala.
Separar modelos permite optimizar costo: el operador hace volumen barato, el reviewer es más caro pero selectivo, el auditor solo corre periódicamente.
Roles humanos alrededor del squad
Los roles IA tienen contrapartes humanas:
Owner humano del squad. Dueño operativo. Ejecuta review semanal, aprueba cambios policy, decide escalaciones de segundo nivel. Tiene contexto de negocio que el IA no tiene.
Architect técnico del squad. Del lado proveedor. Mantiene la arquitectura, ajusta prompts, optimiza costos, escala infra. No decide policy.
SME (subject matter expert). Experto del dominio (ej. abogado para squad legal, médico para squad salud). Consultorio ocasional. Revisa cambios mayores de KB o policy.
QA humano. Revisa un sample de respuestas del operador que el reviewer IA aprobó. Busca casos que el reviewer IA dejó pasar. Es safety net sobre el reviewer.
Compliance humano. Solo para dominios regulados. Revisa audit logs periódicamente, firma reports regulatorios, responde a preguntas de auditoría externa.
La lista parece larga pero no todas son full-time. Un owner puede cubrir 5-10 squads. Un compliance officer puede cubrir la org entera. La proporción humano:squad cambia con la escala.
Cómo crece el equipo humano con la madurez
Semana 1-4 (piloto). Un squad, un humano multi-rol (owner + architect + QA). Contract intenso.
Mes 2-6 (estabilización). Separación comienza. Un owner dedicado del lado cliente; un architect del lado proveedor; QA ocasional.
Mes 6-12 (escala inicial). 3-5 squads corriendo. Un cluster owner consolida visión. QA y compliance se profesionalizan.
Año 2+ (escala madura). Docenas de squads. Organización especializada: cluster owners, platform team, QA team, compliance team. El trabajo diario es casi el mismo; lo que cambió es la división del trabajo.
Planificar este crecimiento desde arranque evita caos cuando llega.
Preguntas frecuentes
¿Todos los squads necesitan los cinco roles?
No. Squads de solo lectura (FAQs públicas) pueden vivir con operator + reviewer. Squads con ejecución necesitan executor. Squads en sector regulado necesitan auditor fuerte.
¿El reviewer puede ser humano en vez de IA?
Sí, en bajo volumen. Para alto volumen es logístico: humano revisa muestra de lo que el reviewer IA marca como anómalo, más su propio muestreo aleatorio.
¿Cuánto cuesta agregar un rol nuevo al squad?
Marginal. Reviewer IA cuesta fraccional del costo del operador (modelo más barato + sampling). Auditor asíncrono es batch, aún más barato. Executor específico mejora control sin gran costo adicional.
¿Cómo se coordina el paso operator → executor?
Mediante contrato estructurado (JSON schema). Operator propone acción; executor valida schema + reglas de negocio; ejecuta o rechaza con razón.
¿El reviewer puede corregir al operator en tiempo real?
Patrón avanzado: reviewer inline que evalúa antes de enviar al cliente, bloquea si score bajo, devuelve al operator para segunda pasada. Agrega latencia (100-400ms) pero aumenta calidad. Solo cuando el caso lo justifica.
¿Qué pasa si el reviewer no detecta un error grave?
Se detecta post-hoc por supervisor humano o por auditor. Se documenta como case study, se agrega criterio al reviewer. Los sistemas mejoran con errores documentados, no con errores ocultos.
¿Fanfusion Hub incluye estos roles out-of-the-box?
Sí. Templates para squads comunes (soporte, ventas, back-office) traen los roles configurados. Más detalle en /products/fanfusion-hub.
Si tu squad actual es "un agente hace todo" y sentís que la calidad no escala, empezá con un diagnóstico de 10 minutos — proponemos la separación de roles que tu squad necesita. Más profundidad: Team-as-a-Service, Escalar squads sin perder control, Squad de soporte end-to-end, plataforma en /platform.