El historial de `cabgo_my_mcp_usage` que genera el servidor de Cabgo registra dos dimensiones que la mayoría de los operadores nunca leen juntas. La primera es el contenido: qué herramienta usó el agente, con qué parámetros, con qué tenant y con qué resultado. La segunda es el canal de origen: desde qué cliente llegó esa llamada. Claude Desktop, el plugin de ChatGPT, el cliente web del MCP, un script que alguien del equipo configuró directamente contra la API. Cuando el agente lo usa una sola persona desde un solo cliente, esa segunda dimensión no tiene interés. Cuando hay tres personas del equipo accediendo desde clientes distintos, la distribución de canales revela algo que ninguna pantalla del dashboard muestra: cómo trabaja realmente cada miembro del equipo con la plataforma, y si el cliente que cada uno eligió está configurado para producir resultados consistentes.
La tesis de este artículo es que la distribución de canales no es un dato técnico de backend sin valor operativo — es un diagnóstico del estado real de adopción del agente en el equipo. Los equipos que usan tres canales distintos para las mismas tareas suelen tener errores silenciosos en alguno de ellos: llamadas que llegan sin tenantId explícito y usan el default del token sin aviso, sesiones que mezclan contexto de dos apps, prompts que funcionan en Claude Desktop pero producen resultados inconsistentes en ChatGPT porque las instrucciones del sistema no están sincronizadas entre clientes. Leer esa distribución una vez al mes toma menos de diez minutos con el agente y permite distinguir entre un equipo que accede desde múltiples canales de forma deliberada y uno que lo hace de forma descoordinada sin saberlo.
Qué registra el campo de canal en cabgo_my_mcp_usage
Cada llamada que llega al servidor MCP de Cabgo incluye un identificador de cliente en el encabezado de la petición. Ese identificador queda registrado en `cabgo_my_mcp_usage` junto con el tenantId, la herramienta invocada, el timestamp y el estado de la respuesta. El campo de canal — que en el registro aparece como `client_id` — toma valores como `claude_desktop`, `chatgpt_plugin`, `web_client` o el identificador personalizado que un script de automatización envía al autenticarse. En la vista de historial que devuelve el agente al pedir la auditoría de uso, ese campo está disponible en cada registro y se puede agrupar, filtrar y comparar con el resto de los campos de la llamada.
Lo que esto significa en la práctica es concreto: cuando el agente consulta la lista de conductores activos, el servidor sabe si esa petición llegó desde la sesión larga que el coordinador de turno tiene abierta en Claude Desktop, desde el plugin que el dueño del negocio usa en ChatGPT para revisar una métrica rápida desde el teléfono, o desde el script que el área de análisis tiene configurado para exportar el cierre de mes. El registro no evalúa si el canal es el correcto para la tarea — registra el canal y deja que la distribución mensual cuente la historia sobre cómo el equipo realmente accede a los datos de la operación.
Tres canales con tres patrones de uso distintos
En operaciones con más de un miembro del equipo accediendo al agente, la distribución de canales después de un mes de uso tiende a reflejar tres tipos de usuario con hábitos de acceso bien diferenciados. Conocerlos no es un ejercicio académico de segmentación — es la base para entender qué canal tiene qué nivel de configuración y dónde tiene más probabilidad de aparecer un error silencioso.
- **Claude Desktop como canal de sesión larga**: el usuario que abre el chat al inicio del turno y lo mantiene activo dos o tres horas acumulando contexto. Las llamadas desde este canal suelen tener el tenantId correcto porque el operador invirtió en configurar las instrucciones del sistema. Es el canal con menor tasa de errores silenciosos en operaciones que llevan más de dos meses con el agente activo.
- **ChatGPT como canal de consulta rápida**: llamadas más cortas, más frecuentes, con mayor variabilidad en la configuración entre usuarios. Es el canal que eligen los miembros del equipo que no configuraron el agente a fondo pero quieren un dato específico rápido. La comodidad de acceso es alta; la consistencia del contexto precargado varía por usuario y rara vez se verifica.
- **Cliente web o API directa como canal de automatización**: scripts y flujos programados que llaman al servidor en horarios fijos — el reporte nocturno, la exportación de métricas del cierre de mes, el webhook de picos de demanda. Estas llamadas casi siempre tienen el tenantId correcto porque está codificado en el script, pero rara vez aparecen en la revisión del operador porque se consideran automáticas y nadie las audita con regularidad.
Los tres patrones de distribución que aparecen después del primer mes
Después de un mes de operación con más de un usuario activo, la distribución de canales en el historial tiende a caer en uno de tres patrones. Los tres tienen implicaciones distintas para la calidad de los datos que el equipo está obteniendo del servidor — y para la cantidad de trabajo de sincronización que queda pendiente.
- **Alta concentración en un canal (70–90% desde Claude Desktop)**: indicador de un operador central que usa el agente de forma intensa y un equipo que todavía no ha adoptado el acceso por agente. Normal en los primeros tres a seis meses de uso. La oportunidad en este patrón es la extensión: cuando el equipo empieza a acceder también, el canal que ya funciona bien es el modelo de configuración a replicar en los clientes que se sumen.
- **Distribución dual (Claude Desktop y ChatGPT en proporciones similares)**: casi siempre indica dos usuarios activos con tipos de tarea distintos — el operador principal con sesiones largas en Desktop y un segundo miembro del equipo con consultas cortas en ChatGPT. El riesgo en este patrón es la asimetría de configuración: si el Desktop tiene el contexto correcto cargado y el ChatGPT no, la mitad de las llamadas llega al servidor sin el marco que produce datos consistentes.
- **Distribución fragmentada (tres o más canales con proporciones similares)**: la señal de que múltiples personas del equipo acceden sin una convención compartida de configuración. Es el patrón donde con más frecuencia aparecen los errores silenciosos de tenant y las inconsistencias de datos que después llegan a soporte como tickets de comportamiento inesperado que nadie puede replicar en el siguiente turno.
Fricción oculta: cuándo el canal sin contexto introduce errores que nadie conecta
El canal más propenso a errores silenciosos no es el que tiene menos uso — es el que tiene más variación en cómo distintos miembros del equipo lo configuraron. En la práctica, eso casi siempre es el plugin de ChatGPT. La razón es estructural: configurar las instrucciones del sistema en ChatGPT requiere una acción deliberada por usuario — entrar a la configuración del perfil, escribir el contexto de la operación, incluir el tenantId correspondiente al rol. Cuando distintos miembros del equipo tienen cuentas diferentes de ChatGPT, cada uno tiene sus propias instrucciones del sistema, o ninguna. No hay un mecanismo que propague la configuración de un perfil a otro.
El resultado más común en operaciones con tres o más personas usando el agente: el coordinador principal tiene el tenantId y los umbrales de la operación correctamente cargados en las instrucciones de su perfil; el segundo coordinador, que empezó a usar el plugin dos semanas después, nunca configuró las suyas. Las llamadas del segundo coordinador llegan al servidor sin tenantId explícito, el servidor usa el default del token de autenticación, y si ese default no corresponde al tenant con el que están trabajando en ese momento, los datos devueltos son de la app equivocada. El output tiene el formato correcto — una tabla limpia, números razonables — y nadie lo cuestiona hasta que una métrica no cuadra con lo que muestra la app. Para entonces, varias decisiones del turno ya se tomaron con datos del tenant incorrecto.
Cuándo estandarizar en un canal y cuándo estandarizar el contexto
La respuesta intuitiva al problema de distribución fragmentada es estandarizar en un solo canal. Eso funciona cuando todos los miembros del equipo tienen el mismo tipo de tarea con el agente. En una operación regional con un coordinador de turno, un supervisor y el dueño del negocio, los tres tienen necesidades distintas: el coordinador necesita sesiones largas con contexto acumulado; el supervisor necesita acceso rápido a métricas específicas desde donde esté; el dueño del negocio necesita el resumen diario sin fricción técnica. Obligarlos a los tres a usar el mismo cliente no resuelve el problema — desplaza la fricción al usuario cuyo flujo no encaja con el canal estándar.
La alternativa más efectiva no es la estandarización del canal sino la estandarización del contexto. Si todos los clientes activos en el equipo tienen cargadas las mismas instrucciones del sistema — el tenantId correcto para cada rol, los umbrales de la operación, el criterio de escalación — el canal específico deja de ser la variable que determina la consistencia. Las llamadas de cualquier canal llegan al servidor con el marco que produce datos correctos. La distribución de canales en el historial mensual se convierte entonces en el indicador de verificación: si el 85% o más de las llamadas llega con el tenantId correcto independientemente del canal, el contexto está bien replicado. Si hay un canal con más del 30% de llamadas resueltas por el default del token, alguien del equipo trabaja sin contexto precargado, y ese es el ajuste concreto — no el canal en sí.
La auditoría de canal: cómo leer la distribución en diez minutos
La lectura de la distribución de canales no requiere acceso directo al backend ni reportes especiales de la plataforma. El agente puede generar el análisis con una llamada al historial de `cabgo_my_mcp_usage` y un prompt bien estructurado. La primera vez que se corre este análisis, el objetivo es identificar tres cosas: qué canales están activos, cuál tiene la tasa más alta de llamadas sin tenantId explícito, y si esa tasa corresponde a un usuario específico o está distribuida entre varios. Con eso es suficiente para determinar si hay un ajuste de configuración pendiente o si la distribución actual es deliberada y consistente.
El análisis que devuelve ese prompt es directo de interpretar. Un canal con un 90% de llamadas con tenant explícito indica una configuración sólida en el cliente que lo usa. Un canal con un 40% de tenant explícito indica que quien lo usa trabaja sin contexto la mayoría del tiempo — no intencionalmente, sino porque las instrucciones del sistema nunca se completaron o quedaron desactualizadas cuando la operación cambió de tenant o de ciudad. El ajuste posterior es siempre el mismo: sincronizar el contexto del canal problemático con el que ya funciona bien en el canal principal. Ese trabajo toma entre cinco y quince minutos por cliente, dependiendo de cuántos campos de contexto haya que copiar de las instrucciones originales.
Hice el análisis de canales por primera vez después de cuatro meses con el agente activo. El resultado me sorprendió: el 38% de las llamadas venían desde el ChatGPT de mi coordinadora, sin las instrucciones del sistema que yo tenía configuradas en mi Claude Desktop. Ella no sabía que su acceso estaba sin contexto — solo notaba que a veces los datos no cuadraban con lo que veía en la app. Cuando lo revisamos juntos y sincronizamos su configuración, ese 38% de llamadas sin tenant desapareció en una semana.
La distribución de canales en `cabgo_my_mcp_usage` no es un dato técnico de backend — es el estado real de cómo el equipo accede al agente. Un equipo donde todos los clientes activos tienen el mismo contexto cargado produce resultados consistentes independientemente del canal que cada miembro prefiera. Un equipo donde la configuración se replicó solo en el cliente del operador principal tiene una fuente de errores silenciosos en los canales secundarios que nadie conecta con el canal hasta que aparece en la distribución mensual o en un ticket de soporte con síntomas que no se pueden replicar.
La acción concreta después de leer la distribución de canales no es cambiar qué cliente usa cada miembro del equipo — es verificar que las instrucciones del sistema están sincronizadas entre todos los clientes activos. Si el historial muestra un 30% de llamadas resueltas por el default del token desde el plugin de ChatGPT, ese porcentaje tiene una solución directa: abrir la configuración de perfil del usuario en ese cliente y agregar el contexto que ya funciona en el canal principal. No hay que migrar a nadie ni cambiar hábitos de acceso. Solo hay que asegurarse de que el canal que cada persona ya usa llegue al servidor con el mismo marco que produce datos correctos. La distribución del mes siguiente confirma si el ajuste funcionó.
