Por qué "Team-as-a-Service" y no "un bot"
La industria pasó tres años vendiendo "asistentes virtuales" como si fueran una pieza de software más. Eso funcionó para demos, no para operación real. Un agente en producción no es una feature: es un miembro del equipo que tiene acceso a sistemas, toma decisiones, y puede hacer daño. Tratarlo como tal cambia el diseño.
Team-as-a-Service significa que entregamos un squad con estructura de equipo real: una misión clara, un scope escrito, canales asignados, KPIs, límites de acción, y un protocolo de escalación a humanos. Si tu "bot" no tiene esos cinco elementos, no es un agente en producción — es un experimento con consecuencias.
La diferencia operativa se siente en la primera crisis. Un bot se "rompe" y genera tickets con soporte del vendor. Un squad se desvía y el ritual semanal lo atrapa antes de que el problema salga del sandbox. Un bot lo opera el área de IT que no tiene contexto de negocio. Un squad se opera con un owner de negocio que reconoce una mala respuesta cuando la ve.
Los cinco elementos no-negociables de un squad
- Misión escrita en una frase, no una lista de features. Ejemplo: "Resolver solicitudes de primer nivel en WhatsApp y Messenger en menos de 2 minutos, escalando a humanos cuando haya duda."
- Canales explícitos, con una política por canal. WhatsApp no es Instagram. Email no es webchat. Las reglas de tono, disclosure y tiempos cambian.
- KPIs medibles contra baseline: tiempo de primera respuesta, CSAT, tasa de escalación, tasa de contención. Si no hay número de partida, no hay cómo saber si el squad sirve.
- Límites de acción — qué puede hacer sin aprobación, qué requiere un humano, qué está explícitamente prohibido. Este es el nivel que separa un asistente juguete de un agente operativo.
- Ritual de revisión semanal: 30 minutos con el líder operativo para ver qué pasó, qué se escaló, qué mejoró, qué se rompió. Sin este ritual, los squads se desalinean en semanas.
Tres squads, tres misiones
En la práctica vemos tres arquetipos que cubren 80% de los casos:
Support Squad. Primera línea de atención. Resuelve FAQs, enruta, agenda, confirma pedidos. KPIs típicos: tiempo de primera respuesta, contención en tier 1, CSAT. Canales: WhatsApp, Messenger, webchat. El humano entra cuando hay una reclamación, una devolución compleja, o un tema regulado.
Sales Asistido Squad. No cierra ventas por su cuenta (regulado en la mayoría de industrias). Califica leads, responde preguntas técnicas, agenda demos, prepara el contexto para el vendedor humano. KPIs: tasa de calificación, meetings agendados, tiempo de respuesta inicial.
Content Factory Squad. Genera drafts, reformula mensajes, localiza campañas, prepara asset packs para revisión humana. Nunca publica sin aprobación. KPIs: throughput de drafts, tasa de aprobación en primer intento, tiempo-a-publicación.
Cada squad tiene una Knowledge Base propia, no compartida. Separar las KBs evita que un agente de soporte responda con material de ventas, o viceversa.
El modelo de aprobaciones: lo que separa un piloto viable de uno peligroso
La mayoría de los fallos públicos de agentes IA comparten el mismo patrón: el agente ejecutó algo que no debía, sin pasar por un humano. Una aerolínea comprometió políticas de reembolso. Un concesionario ofreció un auto por un dólar. Un asistente médico recomendó dosis mal.
El patrón correcto es binario:
- Acción reversible y de bajo impacto → el agente la ejecuta directo y la loguea.
- Acción irreversible o de alto impacto → va a una cola de aprobación humana. El agente prepara el contexto, el humano aprueba o rechaza con un clic.
Este segundo tipo es lo que en el control plane llamamos "approval queue". Aprobar desde WhatsApp o desde el dashboard es equivalente, pero cada acción queda firmada al humano que aprobó. Sin esto no hay auditoría, y sin auditoría no hay industria regulada que acepte el piloto.
Cómo documentar el scope sin asfixiar al agente
Un error común es sobre-especificar: definir 300 reglas para un squad de soporte, que el agente no puede seguir coherentemente y que el equipo tampoco mantiene. El otro error es sub-especificar: "responder amable" no es una política, es una expectativa.
El balance que funciona en producción:
- Una hoja de misión (máximo 10 líneas).
- Un playbook por canal con 3-5 reglas duras (tono, firma, disclosure, escalación).
- Una KB curada — no todo el Notion de la empresa, sólo lo que el agente necesita citar.
- Una lista de "acciones prohibidas" escrita en negativo. Más útil que una lista positiva.
- Un árbol de escalación — qué hace el agente antes de escalar, y a quién escala.
Si ese paquete no cabe en una página, es probable que el scope del squad esté demasiado amplio y convenga dividirlo en dos.
Medir valor sin engañarse
"El squad responde el 78% de las consultas" no es un KPI de valor. Es un KPI de cobertura. El valor se mide en cambios que el negocio nota:
- Tiempo de primera respuesta: ¿bajó de X a Y?
- CSAT: ¿subió, bajó, o se mantuvo?
- Costo por ticket resuelto: ¿mejoró contra baseline humana?
- Tickets escalados incorrectamente: ¿cuántos, y por qué?
La métrica anti-vanidad que más usamos: "¿cuántos minutos-humano ahorró el squad esta semana, sin degradar CSAT?". Si CSAT cae, los minutos ahorrados son deuda, no valor.
Qué pasa cuando un squad falla
Los squads fallan. Es parte del modelo. Lo que importa es cuánto tarda en detectarse y cuánto daño hace antes de detenerse.
Tres niveles de respuesta que todo squad debe tener:
- Soft fail: el agente responde mal pero sin consecuencias. Se detecta en review semanal, se ajusta KB o playbook.
- Hard fail: el agente escala algo que no debía o toma una acción incorrecta. Se detecta en minutos vía alertas de audit log. Se corrige y se re-entrena.
- Incidente: el agente hace algo que afecta a clientes reales o compromete datos. Se activa el kill-switch, se pausa el squad en 30 segundos, se abre post-mortem.
La diferencia entre un vendor serio y uno de demo: el vendor serio tiene el nivel 3 diseñado desde el día uno. El de demo descubre que lo necesita después del primer incidente.
Roles y firmas dentro del squad
Un squad no es un único "agente monolítico". Internamente hay roles que se pueden separar según el caso:
- Operador: el que habla con el cliente o produce el output principal.
- Reviewer: revisa las respuestas del operador, las puntúa, las mejora. Puede ser otro agente o un humano según criticidad.
- Auditor: muestra, no ejecuta. Toma samples de la operación y los revisa contra política — detecta drift antes de que se vuelva incidente.
- Owner humano: el dueño del squad del lado del cliente. Tiene la responsabilidad final, aprueba cambios de policy, corre el review semanal.
- Architect humano (del lado del vendor): mantiene la arquitectura del squad, ajusta guardrails, propone cambios estructurales.
Separar roles evita el anti-patrón de "un solo modelo gigante intentando hacerlo todo". También permite aplicar modelos distintos a cada rol (el operador puede ser un modelo rápido y barato; el reviewer uno más caro y exhaustivo).
Cómo se escala de un squad a una flota
La pregunta no es "¿cuántos squads puedo correr?". Es "¿cómo me aseguro de que el squad número 7 herede los aprendizajes del número 1 sin replicar sus errores?".
Patrones que funcionan:
- Control plane único. Todos los squads comparten plataforma, audit log, permisos, kill-switch. No hay squads "rebeldes" operando por fuera.
- Knowledge Bases separadas por misión, con base común. Policies de marca, tono y compliance son compartidas. KB específica por squad (soporte ≠ ventas ≠ onboarding).
- Supervisor de cluster. Cuando hay 4+ squads operando, alguien — humano o meta-agente — mira el sistema en conjunto. Detecta inconsistencias cross-squad, aprueba cambios estructurales.
- Cadencia de review por capa. Squad operativo: semanal. Cluster: quincenal. Plataforma completa: mensual. Sin esto, los reviews individuales pierden sentido cuando hay interacciones entre squads.
Escalar no es "dejar que más agentes corran". Es "mantener un sistema coherente cuando más piezas interactúan entre sí". Es trabajo de sistemas, no de features.
Anti-patrones que vemos en el mercado
Anti-patrón 1: el squad omnisciente. Un solo squad que "hace todo": soporte, ventas, cobros, onboarding. Imposible de escribirle una misión en una frase. Imposible de medir. Termina en drift estructural.
Anti-patrón 2: el dashboard como gobernanza. Un panel bonito que nadie mira. Sin ritual humano que consuma los datos, el dashboard es decoración. Gobernanza = ritual + métrica + owner.
Anti-patrón 3: el piloto eterno. Squads que operan 6 meses "en piloto" sin criterios de promoción a producción. Se vuelven zona gris sin SLA ni responsabilidad clara.
Anti-patrón 4: el vendor que opera ciego. El vendor corre el squad pero el cliente no tiene visibilidad del audit log, ni de los errores, ni de las mejoras propuestas. Riesgo de reputación asimétrico.
Anti-patrón 5: "entrénalo y olvídalo". Creer que un squad se configura una vez y corre para siempre. En realidad la operación cambia mensualmente — KB nueva, políticas nuevas, productos nuevos. Sin mantenimiento, el squad degrada.
Preguntas frecuentes
¿Cuántos squads puedo correr en paralelo?
Depende del plan. El modelo que recomendamos es empezar con un squad, validar que pasa criterios de aceptación, y entonces abrir el segundo. Tres squads simultáneos al día uno es una receta para diluir atención del equipo interno.
¿Quién entrena al squad: ustedes o mi equipo?
Ambos. Nosotros aportamos el playbook inicial, los guardrails y el scaffolding. Tu equipo aporta el conocimiento de dominio, las excepciones reales y la revisión semanal. Un squad sin participación de tu equipo va a degradar en semanas.
¿Puedo tener agentes con acciones que no requieran aprobación?
Sí, siempre que la acción sea reversible y de bajo impacto (por ejemplo: enviar un mensaje de confirmación, mover un ticket de estado). Todo lo irreversible — pagos, reembolsos, promesas legales — pasa por cola de aprobación obligatoria.
¿Qué pasa si un agente se sale del scope?
Dos capas de protección: la primera es un classifier que detecta intentos de salirse del scope y responde con un mensaje de "escalo a un humano". La segunda es el audit log, que permite detectar patrones sospechosos post-hoc y ajustar la política.
¿Puedo cambiar el scope del squad después del piloto?
Sí, y es lo esperado. El scope inicial está diseñado para aprender rápido, no para ser definitivo. Después del mes 1 reajustamos KPIs, playbooks y KB en base a lo que vimos en operación real.
¿Mis datos se usan para entrenar modelos globales?
No. Cada tenant tiene su KB aislada con RLS y los datos no salen de tu proyecto. Si quisieras entrenar un modelo propio sobre tus datos, se hace en un proyecto separado con contrato explícito.
¿Cuánto tarda en estar listo un squad?
Entre 5 y 10 días hábiles desde el diagnóstico. Depende principalmente de dónde vive la KB, cuántos canales se activan y si hay integraciones con sistemas internos.
¿Qué pasa si cambio de proveedor? ¿Me llevo el squad?
Te llevás la KB, las policies documentadas, los audit logs y las configuraciones declarativas. El modelo subyacente no es portable por licenciamiento, pero reconstruir el squad sobre otra plataforma con esos insumos es cuestión de días.
¿Cómo se factura un squad?
Por capacidad (mensajes/mes, interacciones/mes) más un fee fijo de plataforma. No hay sorpresas por "tokens consumidos" — eso lo absorbemos del lado vendor con modelos adecuados al caso.
¿Puedo tener un squad operando en múltiples idiomas?
Sí. Un squad puede atender español, portugués e inglés con un solo modelo y un playbook multilingüe. Si el volumen en un idioma es alto, conviene tener playbook dedicado por idioma para afinar tono.
Si estás evaluando armar tu primer squad, empezá con un diagnóstico de 10 minutos. Salís con una recomendación de squad, KPIs realistas y una estimación de cuándo puede estar en producción. Más profundidad: Team-as-a-Service: squads por función, Roles dentro de un squad IA, Escalar squads: patrones que funcionan, Squad de soporte WhatsApp + CRM + FAQs, control plane y postura de seguridad.