Cuando Cabgo publica una actualización del skill público del servidor MCP, los operadores que instalaron la versión original sin modificarla reciben las mejoras de forma directa: nuevas herramientas disponibles, instrucciones de sistema corregidas, patrones de uso optimizados. Los operadores que editaron el skill directamente para agregar sus convenciones internas — nombres de zonas, umbrales propios, flujos de escalación — enfrentan el mismo dilema con cada nueva versión: sobreescriben con la actualización y pierden sus adiciones, o se quedan con su versión y acumulan deuda de funcionalidad. Ese dilema tiene una solución que no requiere elegir entre los dos caminos — requiere separar las dos capas desde el principio.
Este artículo es para el operador que ya tiene el skill instalado y funcionando, ha empezado a agregar contexto específico de su operación y quiere una forma de mantener esas convenciones sin que cada actualización de la plataforma sea una decisión sobre qué perder. El patrón que se describe aquí — separar el skill base del contexto del operador en archivos distintos — no requiere conocimientos avanzados de desarrollo. Es una decisión de estructura que cualquiera que haya editado las instrucciones del sistema del agente una vez puede implementar en menos de una hora, y que convierte cada futura actualización del skill en una operación de diez minutos sin conflictos.
El skill público como base de configuración, no como destino final
El skill público que Cabgo publica contiene las definiciones de las herramientas del servidor MCP, un conjunto de instrucciones del sistema que orienta al agente sobre los patrones de uso esperados, y ejemplos de prompts para las tareas más comunes. Lo que el skill no puede incluir por diseño — porque es el mismo para todos los operadores — son las convenciones específicas de cada operación: el nombre que el equipo usa para la zona de alta demanda del aeropuerto, el umbral de disponibilidad que ese operador considera alerta en temporada baja, el criterio interno de cuándo escalar una incidencia al coordinador de turno en lugar del dueño del negocio. Esa segunda capa es la que convierte el skill genérico en una herramienta útil para esa operación específica, con esos conductores, en esas zonas, con esos criterios.
El problema aparece cuando esa segunda capa se agrega directamente dentro de los mismos archivos que definen la primera. Editar el archivo de instrucciones del sistema del skill para incluir las convenciones propias no es incorrecto técnicamente — el agente funciona y los resultados mejoran. El error es de arquitectura: cuando la plataforma publique una versión nueva del skill con instrucciones mejoradas o nuevas herramientas disponibles, el operador tendrá que decidir entre actualizar los archivos base y perder sus adiciones, o mantener su versión modificada y perderse las mejoras. Ambos costos son reales y recurrentes.
Dónde entra la personalización y por qué ese lugar crea fricción futura
La mayoría de los operadores que personalizan el skill lo hacen en uno o dos puntos: agregan líneas al archivo de instrucciones del sistema del skill instalado y, en algunos casos, ajustan parámetros de las definiciones de herramientas para reflejar los nombres o rangos de su operación específica. Los cambios son razonables y en la dirección correcta — el problema no es qué se agrega, sino en qué archivo. Los archivos base del skill son exactamente los que la plataforma actualizará cuando salga la siguiente versión.
El resultado práctico: la primera actualización relevante llega y el operador descubre que tiene un conflicto entre la versión que usa y la nueva. Si elige el camino más rápido y sobreescribe con la actualización, las convenciones internas desaparecen y hay que volver a agregarlas desde memoria. Si decide no actualizar para conservarlas, empieza a acumular distancia respecto a las mejoras de la plataforma — el agente opera con instrucciones que ya no reflejan las capacidades actuales del servidor. Los dos caminos tienen costo. La alternativa es no poner las convenciones en los archivos que la plataforma va a actualizar.
El patrón de capas: separar el skill base del contexto del operador
El patrón que elimina ese dilema es estructuralmente simple: los archivos del skill público no se modifican. Se instalan tal como los publica la plataforma y se actualizan directamente cuando sale una nueva versión. Las convenciones internas del operador viven en un archivo separado — llamémoslo `context_operador.md` o con cualquier nombre que prefiera el equipo — que se carga en las instrucciones del sistema del cliente de agente (Claude Desktop, ChatGPT, o el cliente que el equipo use) pero que no forma parte del directorio del skill en sí.
La separación tiene una implicación práctica importante en cómo se estructura la sección de instrucciones del sistema en el cliente. La primera parte referencia el skill público sin cambios — las instrucciones de herramientas y los patrones de uso del servidor tal como los publicó la plataforma. La segunda parte carga el archivo de convenciones del operador: los nombres de zona, los umbrales específicos, el criterio de escalación interno. Cuando la plataforma actualiza el skill, el operador actualiza la primera parte — o reinstala los archivos del skill en el directorio. La segunda parte no tiene conflictos porque nunca estuvo en los archivos que se actualizaron.
Qué convenciones vale la pena mantener en tu capa
No todo el conocimiento que el operador tiene sobre su operación necesita estar formalizado en el archivo de convenciones. La información que cambia en tiempo real — el estado de conductores activos ahora mismo, los picos del momento — el agente la obtiene directamente del servidor MCP en cada consulta. Lo que sí vale la pena codificar en la capa del operador es el contexto estructural: el que es estable entre turnos y que el agente necesita para interpretar correctamente los datos que recibe del servidor.
- **Nombres de zona y su correspondencia**: si el equipo llama «Zona Norte» a lo que el mapa registra como «sector 04», ese mapeo en las instrucciones evita ambigüedad en cada consulta — sin él el agente usa el identificador técnico del servidor y el equipo tiene que traducir mentalmente en cada respuesta
- **Umbrales de normalidad propios**: los rangos de disponibilidad, tasa de cancelación y tiempos de espera que son normales para esa operación específica, por horario y zona — los valores por defecto del skill son genéricos y no reflejan la realidad de cada mercado
- **Flujo de escalación interno**: quién recibe qué tipo de alerta, por qué canal y en qué horario — el skill no puede saber que el coordinador del turno de noche prefiere las alertas de surge por WhatsApp y que el dueño del negocio revisa el resumen en el dashboard solo al final del día
- **Convenciones de tenantId por contexto**: si la operación tiene dos tenants (taxi y delivery) y las tareas de cada tipo siempre usan el mismo, formalizarlo en la capa evita el error de mezclar tenants en consultas rápidas donde no se especifica de forma explícita
- **Resoluciones de incidencias recurrentes**: la solución que ya funcionó para los problemas que reaparecen — cuando el agente reconoce el patrón y ya tiene la resolución en contexto, la consulta termina en una respuesta directa, no en un diagnóstico desde cero
Cómo incorporar una actualización del skill sin afectar tu capa
Con el patrón de capas implementado, incorporar una actualización del skill público es una secuencia de tres pasos que toma menos de diez minutos. El primero es descargar o actualizar el directorio del skill desde el repositorio de la plataforma — si se usa git, un `git pull` en la carpeta del skill es suficiente. El segundo es revisar el changelog de la actualización para entender qué cambió: algunos updates añaden nuevas herramientas, otros ajustan los nombres de parámetros existentes o el formato de las respuestas. Si hay cambios de ese tipo, puede requerirse un ajuste menor en la capa del operador — no en el skill base. El tercero es verificar que las instrucciones del sistema en el cliente de agente siguen referenciando correctamente los archivos actualizados.
Si el operador nunca modificó los archivos base del skill, esos tres pasos son todo lo necesario. La capa del operador no tiene conflictos porque vive en un archivo distinto. Si los cambios en el skill implican ajustes en el contexto del operador — por ejemplo, una herramienta renombrada que el operador menciona por nombre en su archivo de convenciones — esos ajustes se hacen en el archivo del operador, no en los archivos del skill. El resultado: el agente tiene las mejoras de la plataforma y las convenciones internas del operador, sin interferencia entre las dos.
Verificar que la capa funciona después de aplicar una actualización
La verificación más directa después de una actualización es una consulta diagnóstica al agente antes de volver a usarlo en producción. Un prompt simple — «¿Qué zonas tienes definidas como de alta demanda para esta operación? ¿Cuál es el umbral de disponibilidad que consideras normal en esta ciudad?» — le pide al agente que devuelva lo que tiene en contexto activo en ese momento. Si la respuesta incluye los nombres y valores del archivo del operador, la actualización no los afectó. Si el agente devuelve valores genéricos o no reconoce los nombres internos, hay un problema en cómo se cargó el archivo de convenciones en las instrucciones del sistema del cliente.
Esa verificación toma dos minutos y tiene un valor desproporcionado: evita operar un turno con un agente que tiene las mejoras del skill pero perdió el contexto de la operación. El síntoma de ese estado no siempre es visible de inmediato — el agente responde preguntas, accede al servidor, produce outputs con el formato correcto — pero lo hace sin el marco que produce respuestas específicas para esa operación. Un agente sin convenciones cargadas es funcionalmente equivalente a uno recién instalado: correcto en la forma, pero genérico en el contenido. Para una operación que lleva meses refinando su capa de contexto, perder eso silenciosamente en una actualización tiene exactamente el mismo costo que no haberla construido.
La primera vez que salió una actualización del skill sobreescribí los archivos y perdí las instrucciones para mis zonas. Tardé un día en reconstruirlas de memoria. La segunda actualización ya la apliqué con el archivo del operador separado — diez minutos, sin conflictos, y mis convenciones quedaron intactas.
El patrón de capas no es una práctica avanzada de desarrollo — es una decisión sobre dónde guarda el operador el conocimiento de su operación. El skill público de la plataforma resuelve la interfaz con el servidor MCP: qué herramientas existen, cómo se invocan, qué devuelven. El archivo de convenciones del operador resuelve el contexto de la operación específica: qué significan los datos que el skill devuelve en términos de esa ciudad, ese equipo y esos umbrales propios. Las dos capas responden preguntas distintas y, cuando viven en archivos distintos, se pueden actualizar de forma independiente sin que una afecte a la otra.
Si llevas más de un mes con el skill instalado y aún no has separado las capas, el momento más conveniente para hacerlo es antes de que llegue la siguiente actualización importante. El inventario de lo que haría útil tu capa no es extenso: cinco a ocho convenciones que el equipo usa con suficiente frecuencia para que valga documentarlas en un lugar fijo. Crear el archivo, mover ahí lo que ya tienes disperso en las instrucciones del sistema, y actualizar las referencias en el cliente toma menos de una tarde. Las próximas actualizaciones del skill serán una operación de diez minutos en lugar de una decisión sobre qué perder.
