El skill del agente está instalado, el servidor MCP conectado y el agente accede a los datos de la operación en tiempo real. Las respuestas llegan rápido. Y sin embargo, hay una distancia entre lo que el agente responde y lo que el coordinador de turno necesita: cuando le preguntas por la cobertura de la zona norte, el agente devuelve el número pero no dice si ese número es problemático para esa ciudad un martes a las 18:00. Cuando le preguntas cómo manejar conductores fuera del área principal durante un pico, te da opciones razonables pero no la resolución que encontraste hace dos meses que funcionó en ese contexto específico. Esa distancia entre «responde» y «diagnostica» tiene una sola causa: el archivo de contexto del operador no contiene la información que convertiría los datos de la API en diagnósticos específicos para esa operación.

Este artículo no es sobre el skill base ni sobre cómo separar las capas de configuración para mantener las actualizaciones sin conflictos — eso está cubierto en el artículo sobre el fork del skill público. Es sobre el contenido del archivo de contexto del operador: qué secciones lo hacen útil, qué datos concretos van en cada una, cuánto detalle es suficiente para una primera versión funcional, y qué errores convierten el archivo en algo que existe pero no produce diagnósticos distintos a los que el agente daría sin él. El artículo está dirigido al operador que ya tiene el agente activo y nota que sus respuestas son correctas pero demasiado genéricas para ser directamente accionables.

Por qué el archivo determina el techo de lo que el agente puede diagnosticar

El agente opera sobre dos tipos de datos: los que obtiene en tiempo real de la API de la plataforma — conductores activos, cobertura actual, viajes en curso, cancelaciones de la última hora — y los que están en su contexto de sistema: las convenciones de la operación que definen qué significa cada número. La plataforma provee el primer conjunto; el operador provee el segundo. Cuando ese segundo conjunto está vacío o es demasiado genérico, el agente tiene acceso a los datos correctos pero carece del punto de referencia para interpretarlos: sabe que hay doce conductores activos en la zona norte, pero no sabe si eso es suficiente, bajo o crítico para esa zona a esa hora.

La diferencia práctica entre un agente con un archivo de contexto bien construido y uno sin él no es de velocidad ni de acceso a datos — es de especificidad. Con el archivo, el agente puede responder: «la zona norte está a doce conductores activos, un 30% por debajo del umbral mínimo para las tardes de martes en temporada alta; la última vez que cayó a ese nivel en condiciones similares el patrón que funcionó fue reubicar dos conductores desde zona centro antes de las 18:30». Sin el archivo, el agente da la misma respuesta a cualquier operación con doce conductores en una zona: describe el número y deja la interpretación al coordinador. Esa es la diferencia entre una herramienta que amplifica el criterio del coordinador y una que devuelve datos sin referencia.

Las cinco secciones que distinguen un archivo útil de uno de relleno

Un archivo de contexto que produce diagnósticos específicos tiene cinco secciones. No es la única estructura válida, pero sí la que cierra los vacíos de información más comunes en operaciones que llevan más de treinta días con el agente activo:

Zonas y umbrales: el vocabulario compartido y los números que lo hacen específico

Las definiciones geográficas resuelven el problema más frecuente en operaciones donde el equipo usa nombres internos que no coinciden con los identificadores del sistema. El agente que recibe una pregunta sobre «la zona industrial» necesita saber si ese nombre corresponde a la zona norte del panel, si incluye o excluye el acceso por la carretera federal, y si en ese contexto «zona industrial» en el turno nocturno se refiere a los tres polígonos del sistema o solo al principal. Sin esa correspondencia, el agente trabaja con ambigüedad — cada respuesta puede referirse a una geografía distinta dependiendo de cómo el coordinador formuló la pregunta — y ese costo se acumula en diagnósticos inconsistentes.

Los umbrales operativos son la sección más directamente conectada con la calidad del diagnóstico, porque son los que permiten al agente interpretar un número en lugar de devolverlo sin referencia. Un umbral bien documentado no dice «disponibilidad baja en zona norte» — dice «menos de 14 conductores activos en zona norte entre las 17:00 y las 20:00 de lunes a viernes es nivel alerta; menos de 8 conductores en ese mismo período es nivel crítico que justifica activar incentivos de reposicionamiento». Esa especificidad permite al agente comparar el estado actual con la referencia de esa operación y generar un diagnóstico accionable en lugar de un dato neutral que el coordinador tiene que interpretar sin contexto.

Incidencias y resoluciones: la memoria que elimina el diagnóstico desde cero

La sección de incidencias y resoluciones es donde más varía la calidad entre archivos que producen diagnósticos útiles y archivos que existen sin producir diferencia. La distinción entre una entrada útil y una de relleno es concreta: una entrada útil describe la situación con sus parámetros específicos, la decisión que tomó el coordinador, el resultado observable en los treinta minutos siguientes y el contexto que explica por qué esa decisión funcionó. Una entrada de relleno dice «zona norte sin cobertura, se activó incentivo, se resolvió» — eso no tiene nada que el agente no pudiera inferir. Lo que convierte la entrada en útil es el detalle que no está en los datos: que en ese caso específico la zona sur también estaba baja y mover conductores desde allí no era viable, que la resolución correcta fue el incentivo de punto fijo en lugar del de zona general.

El formato concreto para una entrada de incidencia bien documentada tiene cuatro campos. Situación: qué pasaba al momento de la incidencia, con los números específicos de cobertura, cancelaciones pendientes y solicitudes sin asignar. Contexto: qué era inusual o explicativo — un evento cercano, fin del turno escolar, lluvia, día de quincena. Acción: la decisión tomada con sus parámetros exactos — cuántos conductores, hacia qué zona, qué tipo de incentivo, en qué ventana de tiempo. Resultado: qué cambió en los quince o treinta minutos siguientes. Cuando el agente tiene veinte o treinta entradas en ese formato, el tiempo de diagnóstico en incidencias recurrentes cae de diez o quince minutos a dos o tres porque el agente puede identificar el patrón y recuperar la resolución en lugar de construir un diagnóstico desde cero.

La primera versión en dos horas: qué incluir y qué dejar para después

El error más común al construir el archivo de contexto por primera vez es intentar documentar todo antes de empezar a usarlo. Un archivo que intenta cubrir todos los escenarios posibles en la primera sesión lleva días de trabajo y termina lleno de hipótesis sobre situaciones que no han ocurrido — que el agente puede inferir de los datos con casi la misma precisión. Lo que no puede inferir porque requiere conocimiento local son tres cosas: los nombres internos de las zonas y su correspondencia con los identificadores del sistema, los umbrales de las tres o cuatro zonas principales en las franjas horarias de mayor demanda, y las dos o tres incidencias recurrentes más costosas con sus resoluciones documentadas.

Una primera versión funcional puede construirse en dos horas usando el propio agente como par de trabajo. El proceso concreto: exportar la lista de zonas del panel, pedirle al agente que tome esa lista como base y formule las preguntas de umbral que necesita que el operador responda (esto toma entre veinte y treinta minutos), luego documentar las dos o tres incidencias más recurrentes con el formato de cuatro campos (cuarenta a sesenta minutos). Lo que queda fuera de esa primera sesión — patrones estacionales, conductores individuales, eventos locales — se añade en sesiones cortas después de turnos donde ocurrieron incidencias relevantes. El archivo crece con el uso, no en una sesión de diseño inicial, y cada incidencia documentada en tiempo real produce una entrada más precisa que las que se reconstruyen de memoria semanas después.

Los tres patrones que hacen un archivo técnicamente presente pero operativamente vacío

El primer patrón que elimina la utilidad del archivo es la ausencia de números específicos. Describir que «la zona norte tiene disponibilidad baja en horas pico» no aporta nada que el agente no pueda inferir de los datos en tiempo real. Lo que añade valor es el umbral: cuántos conductores exactamente es «bajo» en esa zona en ese horario, para ese operador en esa ciudad. Sin ese número el agente no puede comparar el estado actual con la referencia específica de la operación y produce la misma respuesta que daría sin el archivo: correcta pero genérica, útil para confirmar el estado pero no para diagnosticar si ese estado requiere acción.

El segundo patrón es documentar solo el estado de la operación sin resoluciones de incidencias pasadas. Un archivo lleno de descripciones de zonas y patrones es útil para responder preguntas de estado — cómo está la cobertura, cuántos conductores están activos, qué zonas tienen más cancelaciones — pero no para reducir el tiempo de diagnóstico en los momentos críticos del turno, que es exactamente donde el agente produce más valor con el contexto correcto. El tercer patrón es usar en el archivo nombres que no coinciden con los identificadores del sistema: si el archivo dice «zona industrial» y la plataforma registra la zona como «Zona_Norte_03», el agente gasta parte de su contexto en resolver la ambigüedad antes de llegar a la respuesta — ese costo de desambiguación se repite con cada consulta y degrada la especificidad de cada diagnóstico.

El archivo de contexto del operador no es un documento de incorporación que se construye una vez al instalar el skill — es un registro operativo que crece con cada turno donde ocurre algo que vale documentar. Cada incidencia registrada con su resolución, cada umbral ajustado a la temporada actual, cada patrón estacional documentado antes de que llegue, es contexto que el agente puede usar en la próxima consulta para producir un diagnóstico más específico que el anterior. Ese crecimiento por acumulación no se puede replicar sin el tiempo de operación: es el único insumo que ninguna configuración genérica de la plataforma puede proveer en el momento de instalar el skill.

Los operadores que llegan a los seis meses con un archivo bien mantenido tienen algo que ninguna configuración de la plataforma puede entregar directamente: la inteligencia específica de su ciudad, sus zonas y su operación, acumulada turno a turno en un formato que el agente puede usar para responder preguntas que no tienen respuesta genérica. Esa especificidad es lo que hace que la misma pregunta sobre cobertura en zona norte produzca diagnósticos diferentes para operadores que usan la misma plataforma con los mismos datos en tiempo real. La diferencia no está en el skill — está en el contexto que cada operador construyó.