Los operadores que tienen taxi y delivery activos en Cabgo suelen llegar a la misma conclusión después de las primeras semanas con el agente: necesitan dos instancias separadas, una por cada app. La lógica parece sólida — son dos negocios con conductores distintos, tarifas distintas y, en muchos casos, zonas que no se superponen. El problema es que esa lógica produce un sistema innecesariamente complicado: dos clientes de chat, dos tokens, dos bibliotecas de prompts que mantener en paralelo. La tesis de este artículo es que un solo agente con un solo skill instalado puede gestionar ambas verticales desde la misma conversación, y que la única variable que cambia entre una tarea de taxi y una de delivery es el tenantId que aparece en el prompt.
Este artículo es para el operador que ya tiene el skill de Cabgo instalado y ha activado una segunda vertical en la plataforma. Cubrimos cómo el servidor MCP resuelve el tenant en cada llamada, cuál es el error más común en operaciones multi-vertical, cómo estructurar los prompts para que el agente sepa en todo momento con qué app está trabajando, y un patrón que muy pocos operadores han explorado: las consultas paralelas que producen un resumen comparativo de ambas verticales en una sola respuesta del agente.
Cómo el servidor MCP decide a qué tenant le habla el agente
El skill de Cabgo define una jerarquía de tres capas para resolver el tenant en cada llamada. La primera es el tenantId explícito en el prompt: si el operador escribe «para la app de delivery, lista los conductores disponibles», el agente extrae ese contexto y lo pasa directamente en la llamada al servidor. La segunda es el tenantId precargado en las instrucciones del sistema del cliente de chat — en Claude Desktop o en las instrucciones de perfil de ChatGPT, el operador puede incluir «mi tenant de taxi es [id]» como contexto fijo que el agente usa cuando el prompt no especifica nada diferente. La tercera es el tenant vinculado al token de autenticación: si ninguna de las dos capas anteriores especifica un tenant, el servidor usa el asociado al token, que en la mayoría de las instalaciones es el primer tenant que el operador activó.
El peligro de la tercera capa — el default silencioso del token — es que se activa sin señal visible. En una operación de una sola vertical eso no importa porque siempre hay un tenant correcto. En una operación bi-vertical, el default puede hacer que una consulta de delivery apunte al tenant de taxi sin que el agente lo indique: devuelve datos con el formato esperado, pero del negocio equivocado. Ese tipo de error es más difícil de detectar que uno explícito porque el output parece correcto en su forma. La auditoría semanal del historial de `cabgo_my_mcp_usage` es el único lugar donde ese patrón se hace visible: si el 90% de las llamadas de la semana fueron al tenant de taxi cuando el operador recuerda haber trabajado con delivery varios días, el desequilibrio señala el problema.
El error más común: cambiar de vertical sin cambiar de tenant
La mayoría de los problemas en operaciones multi-tenant no ocurren al inicio de la sesión — ocurren en el medio. El operador empieza el chat revisando la flota de taxi y después, en la misma conversación, pregunta sobre las zonas activas de delivery. Ese cambio de tema no actualiza automáticamente el tenantId que el agente usa en las llamadas siguientes: el agente mantiene el contexto del tenant anterior a menos que el nuevo prompt lo cambie de forma explícita. El resultado es que el operador pregunta por zonas de delivery y recibe las del tenant de taxi — datos con el mismo aspecto pero del negocio equivocado.
El error pasa desapercibido porque el agente no anuncia cuándo mantuvo el tenant de la llamada anterior en lugar de actualizar al nuevo. Puede suceder varias veces en una sesión larga antes de que el operador note una discrepancia — por ejemplo, que el número de conductores activos no cuadra con lo que ve en la app. Para entonces, varias decisiones del turno ya se tomaron con datos del tenant equivocado. La forma de cortar ese ciclo no es revisar cada respuesta del agente con desconfianza, sino instalar el hábito de nombrar el tenant al inicio de cada bloque de trabajo dentro de la conversación.
Estructurar los prompts para que el tenant no se pierda en el cambio de contexto
La solución no requiere configuración técnica adicional — requiere un hábito de prompt. El principio es simple: cada vez que cambias de vertical dentro de una conversación, el primer mensaje del nuevo bloque incluye el tenant. No como instrucción especial al agente, sino como contexto natural: en lugar de «¿cuántos conductores activos tiene delivery esta tarde?», escribes «Cambiando a delivery [tenant_id]: ¿cuántos conductores activos tiene esta tarde?». Dos palabras adicionales son suficientes para que el agente resuelva el tenant correcto en todas las llamadas de ese bloque. Hay cuatro convenciones que hacen que este hábito sea consistente sin agregar fricción al trabajo diario:
- Nombrar el tenant al inicio de cada bloque de trabajo, no solo al inicio de la sesión: una sesión de una hora puede tener tres bloques distintos — apertura de turno en taxi, revisión de zonas en delivery, cierre de turno en taxi — y cada uno requiere su propio anclaje de tenant para evitar herencia de contexto
- Incluir el tenantId en los prompts guardados de la biblioteca: si el operador tiene un prompt de resumen de turno, guardar una versión para taxi y otra para delivery con los tenantIds ya incluidos elimina la necesidad de recordar agregarlos al usar el template
- Usar el nombre de la app además del ID técnico cuando el contexto es nuevo: «Delivery [nombre_app] [tenant_id]» es más rápido de leer en medio de una conversación que solo el ID numérico, especialmente en operaciones con más de dos apps
- En el cierre de turno, especificar el tenant aunque sea el mismo que el default: un cierre que nombre explícitamente el tenant cierra el contexto de la sesión sin ambigüedad y facilita la lectura posterior del historial de `cabgo_my_mcp_usage`
Consultas paralelas: un reporte que cubre ambas verticales en una respuesta
El patrón más eficiente para el operador bi-vertical no es alternar entre tenants en la misma conversación, sino pedirle al agente que haga las dos consultas en paralelo y devuelva los resultados en formato comparativo. El servidor MCP de Cabgo acepta llamadas simultáneas a tenants distintos dentro del mismo contexto de conversación — el agente puede llamar a una herramienta de lectura dos veces en el mismo mensaje, una por tenant, y combinar los resultados en una tabla. Para que eso funcione, el prompt debe especificar ambos tenants y el formato de salida esperado en la misma solicitud: «Consulta el estado de flota de taxi [tenant_taxi] y delivery [tenant_delivery] en paralelo. Devuelve una tabla con columnas: vertical, conductores activos, viajes completados hoy, tasa de disponibilidad pico. Una fila por vertical.»
El límite de este patrón es el contexto acumulado de la sesión: si el chat lleva varias horas de trabajo con uno de los tenants, la consulta paralela puede producir un resultado sesgado hacia ese tenant porque tiene más historial en el contexto que el otro. Ese sesgo no aparece como error explícito — aparece como asimetría en los datos: las métricas del tenant dominante tienen más detalle que las del secundario. La auditoría semanal del historial de `cabgo_my_mcp_usage` lo detecta como una distribución de tenantIds desbalanceada en la semana, y es la señal para ajustar cuándo se lanza la consulta paralela o para dividirla en sesiones separadas cuando la diferencia de contexto entre tenants es grande.
Campañas por vertical con verificación cruzada
Una de las ventajas del agente único multi-tenant es que el contexto de una vertical puede informar decisiones de la otra. El caso más claro es el de las campañas de demanda: si el operador considera lanzar un bono de delivery para un fin de semana con evento en la ciudad, la disponibilidad histórica del taxi en ese mismo período es relevante. Si la flota de taxi estuvo al 65-70% de disponibilidad en los últimos tres fines de semana similares y hay conductores que operan en ambos servicios, activar un bono de delivery que mueva esos conductores puede crear un déficit de oferta en taxi que ninguna de las dos apps anticipa por separado. Con dos agentes distintos, esa verificación cruzada requiere consultas manuales a ambos clientes. Con un agente multi-tenant, el prompt puede pedirla explícitamente antes de proponer los parámetros del bono.
La forma de incluir esa verificación en el prompt de diseño de campaña es directa: «Antes de proponer los parámetros del bono de delivery, consulta la disponibilidad histórica de taxi [tenant_taxi] en los mismos horarios durante las últimas cuatro semanas. Si la disponibilidad bajó del 70% en alguno de esos períodos, ajusta el umbral del bono de delivery para no competir por conductores que ya estaban cubiertos por el servicio de taxi.» Esa instrucción condicional le da al agente el criterio para calibrar el incentivo entre ambas verticales en lugar de diseñarlo como si la otra app no existiera. No es una funcionalidad especial del servidor — es el resultado directo de tener los dos tenants disponibles en el mismo contexto de conversación.
Cuándo sí tiene sentido separar los agentes
La tesis del agente único tiene excepciones concretas. La primera es la escala de equipo: si el operador tiene dos coordinadores distintos — uno para taxi y otro para delivery — y cada uno usa el agente de forma independiente, tiene sentido darles tokens separados y agentes separados, no por razones técnicas sino de responsabilidad operativa. Mezclar las sesiones de dos coordinadores bajo el mismo tenant hace que el historial de `cabgo_my_mcp_usage` sea difícil de interpretar cuando hay que determinar quién ejecutó qué acción y cuándo. Dos agentes con tokens distintos producen historiales que atribuyen las acciones al coordinador correcto.
La segunda excepción es la geografía: si taxi y delivery operan en ciudades distintas y no comparten conductores ni zonas, el beneficio de las consultas cruzadas es bajo y el costo de especificar el tenant en cada prompt es constante. En ese caso, dos agentes con el contexto de ciudad fijo en sus instrucciones del sistema son más simples de operar que un agente multi-tenant que requiere especificación explícita en cada bloque de trabajo. La regla práctica: un agente por operador cuando los dos negocios comparten conductores o zonas; dos agentes cuando los roles humanos o las geografías son completamente distintos y el contexto cruzado no aporta valor real.
Llevaba dos meses con un chat para taxi y otro para delivery porque asumía que el agente se iba a confundir si mezclaba las dos apps en la misma conversación. Cuando entendí cómo funciona el tenantId, consolidé todo en una sola sesión fija en Claude Desktop. Lo único que cambié fue agregar el nombre de la app y el tenant al inicio de cada bloque de prompts. Ahora tardo menos tiempo revisando el estado de las dos verticales que lo que tardaba antes en cambiar entre ventanas.
El resumen diario multi-tenant: un prompt para dos negocios
El caso donde la gestión multi-tenant en el mismo agente más se justifica es el resumen diario. En lugar de revisar dos apps por separado cada mañana, el operador puede tener un solo prompt guardado que produce el estado de ambas verticales en una respuesta estructurada. El prompt tiene que hacer tres cosas: especificar ambos tenants, pedir las mismas métricas de cada uno para que la comparación sea directa, y pedir formato tabular en lugar de narrativo. Un ejemplo funcional: «Resumen del turno de hoy. Para taxi [tenant_taxi] y delivery [tenant_delivery]: conductores activos ahora, viajes completados en las últimas 12 horas, calificación promedio de la semana, y una línea de alerta si alguna métrica está fuera del rango de los últimos 7 días. Devuelve una tabla con las dos verticales en filas y las cuatro métricas en columnas.» Guardado como instrucción del sistema o en la biblioteca de prompts, ese template reemplaza la revisión manual de ambas apps cada mañana.
Gestionar dos verticales desde el mismo agente no es una optimización técnica — es la forma directa de aprovechar que el agente tiene acceso a ambos contextos al mismo tiempo. El tenantId en el prompt es el mecanismo de control, y el hábito de nombrarlo al inicio de cada bloque de trabajo es la única diferencia entre un agente que devuelve datos correctos y uno que los mezcla en silencio. Si tienes taxi y delivery activos y todavía usas dos chats por separado, la acción concreta esta semana es revisar los prompts guardados y agregar el tenant explícito en cada uno — dos o tres palabras por template es el costo de ese cambio. El historial de `cabgo_my_mcp_usage` te va a mostrar una distribución de tenantIds que refleja cómo usas realmente las dos apps, en lugar de una concentración en el default que indica que la especificación se perdió en algún punto de la sesión.
