Operator: cuando responder no basta

A developer is training a compact model called Operator to execute actions within the Kernel Memory Protocol (KMP), a contract for reading, navigating, and writing memory in the Underpass Kernel. The model is designed to handle the strict, operational layer of memory tasks—such as issuing valid tool calls like `kernel_near` or `kernel_write_memory`—rather than open-ended reasoning, after benchmarks showed that even GPT-4o could understand queries but fail at precise memory operations. Operator does not replace a primary model but instead takes over the specific job of deciding the next verifiable KMP action from a structured state, aiming to make memory operations auditable and trainable rather than relying on intuition within free-form responses.

Operator es un modelo compacto que estoy entrenando para operar Kernel Memory Protocol KMP , el protocolo de memoria de Underpass Kernel. KMP no es un estándar externo. Es el contrato que estoy definiendo dentro de Underpass para leer memoria, moverse por ella y escribir nueva información de forma validable. Operator no nace porque KMP sea difícil de usar. KMP está diseñado para agentes, humanos y herramientas mediante MCP o una API tipada. Operator nace de una observación concreta: en benchmarks como LongMemEval o MemoryArena, GPT-4o podía entender la pregunta y aun así fallar en la operación. Elegir la herramienta MCP, copiar la referencia exacta, respetar un cursor, mantener el presupuesto o escribir una relación con evidencia válida no son detalles secundarios. Son parte del resultado. También aparece una inercia típica de los modelos de propósito general: volver a pensar la pregunta. Operator busca lo contrario: tomar un estado visible y emitir la siguiente acción KMP. Esa es la hipótesis que quiero medir: si un modelo compacto puede aprender la parte estricta de operar ese contrato. Cuando un sistema opera contra un protocolo o una API, una acción casi correcta no sirve. La llamada tiene que ser válida. Ahí entra Operator. La idea es simple: no todas las decisiones de un sistema de agentes tienen que ser razonamiento abierto. El modelo principal puede entender la tarea, interpretar la evidencia y producir la respuesta final. Operator ocupa un espacio más estrecho: decide cuál es la siguiente acción KMP que conviene ejecutar desde el estado visible. No sustituye al modelo principal. Le quita una parte concreta del trabajo: operar memoria con precisión en escenarios exigentes. Lo importante es que esa operación deja de ser una intuición dentro de una respuesta libre. Pasa a ser una acción verificable, entrenable y auditable. Operator es: tool call , prepared tool call , stop o escalate ;Las herramientas que puede emitir incluyen: kernel ingest ; kernel write memory ; kernel wake ; kernel ask ; kernel goto ; kernel near ; kernel rewind ; kernel forward ; kernel trace ; kernel inspect .Operator no es: Tampoco es una capa necesaria para usar KMP. Un modelo capaz puede operar KMP directamente mediante MCP. Operator no ve todo el problema. Ese es el punto. Su mundo es más acotado que el mundo del modelo principal. No recibe una conversación completa para interpretarla desde cero. Recibe un estado estructurado: la parte de la memoria y del contrato que necesita para decidir el siguiente paso. Ese estado puede incluir un objetivo operativo, referencias conocidas, cursores, dimensiones, herramientas permitidas, presupuesto restante y observaciones anteriores. No tiene que decidir qué significa todo. Tiene que decidir qué hacer ahora. Con eso produce una única acción. Una muestra real, reducida a lo esencial, queda así: ESTADO VISIBLE objetivo: expandir alrededor de ref 0001 modo: read dimensión relevante: session:handoff presupuesto: 1 llamada, 600 tokens refs conocidas: ref 0001 ... ref 0005 ACCIÓN EMITIDA tool call: kernel near anchor: ref 0001 dimensions: session:handoff limit: 4 La salida no es una explicación. No es una respuesta al usuario. Es una acción. KMP es el contrato. MCP es una forma de exponer ese contrato como herramientas para agentes. Operator solo propone la siguiente acción. No tiene una API privada. No salta por detrás de Underpass Kernel. Emite acciones sobre el mismo contrato que usaría cualquier agente mediante MCP. php estado visible + objetivo + presupuesto - Operator - acción KMP/MCP - Underpass Kernel - evidencia, refs, prueba o error Operator no se entrena con preguntas y respuestas finales. Se entrena con decisiones operativas. El entrenamiento parte de trayectorias de operación: php estado visible - acción esperada El estado visible es la parte de la memoria que Operator puede usar en ese paso: objetivo operativo, referencias conocidas, cursores, herramientas permitidas, presupuesto y observaciones previas. La acción esperada es la decisión correcta para ese estado: inspeccionar una referencia, ampliar una ventana temporal, parar porque ya hay evidencia suficiente, escalar porque hace falta razonamiento abierto o emitir una escritura preparada. Cada trayectoria se convierte en una fila SFT con tres mensajes: php system - contrato MCP/KMP, herramientas permitidas y reglas de salida user - estado visible de memoria assistant - acción esperada en JSON estricto Después se ajusta Qwen/Qwen2.5-0.5B-Instruct con LoRA SFT sobre ese formato. Qwen no aprende a contestar el benchmark. Aprende a no volver a resolver la tarea desde cero y a emitir la siguiente acción KMP válida desde el estado que ve. LoRA permite hacer ese ajuste sin reentrenar todo el modelo. La base de Qwen se mantiene congelada y se entrenan adaptadores ligeros sobre algunas capas. Esos adaptadores son los que aprenden el patrón operativo de KMP: leer el estado visible, respetar el contrato y emitir el JSON correcto. Para que ese aprendizaje sea medible, el dataset tiene que estar muy controlado: ref 0001 , ref 0002 , about 0001 ; user no puede incluir la respuesta esperada del benchmark, la acción objetivo, memoria oculta ni salidas de herramienta que el modelo no debería ver;Sin esas reglas, el resultado de evaluación deja de medir Operator. Puede estar midiendo fuga de datos, divergencia entre entrenamiento y servicio o memorización de nombres de dominio. Después del entrenamiento, el adaptador LoRA se ejecuta sobre el conjunto de evaluación. Para cada fila, Operator recibe el estado visible y debe producir una única acción. Esa es la diferencia con la respuesta libre de un LLM convencional: aquí la salida se puede comprobar. El proceso genera predictions.jsonl y summary.json . Luego el evaluador compara cada predicción contra la acción esperada. Las métricas principales son: La última métrica es la que evita autoengaños. Un JSON puede parecer correcto y fallar contra el kernel real. Si falla ahí, la acción no sirve. La afirmación publicable que busco es esta: Operator predice acciones acotadas de Kernel Memory Protocol desde estados visibles de memoria, con contrato estricto y replay real contra Underpass Kernel mediante MCP. Qwen 0.5B encaja con la hipótesis de Operator: especializar un modelo abierto en una tarea estrecha y verificable. Operator no tiene que escribir un ensayo ni resolver una incidencia completa. Tiene que: Por eso Qwen es una buena base: No busco demostrar que Operator sea más inteligente que un modelo de propósito general. Busco comprobar si un modelo abierto y compacto puede aprender a operar un contrato estricto. La evaluación también puede engañar. Un evaluador puede aceptar acciones demasiado parecidas. Si esperaba Stop reason=NoCandidate y acepta Stop reason=AnswerReady solo porque ambas son stop , la exactitud aparente sube pero la semántica está mal. También puede pasar con cursores. Una herramienta puede ser correcta y el cursor equivocado. En KMP eso no es un detalle: cambia la acción. Otro fallo posible es enseñar al modelo información que no debería ver: respuestas finales, referencias futuras, sesiones objetivo o nombres de dominio. Por eso antes de hablar de exactitud hay que hablar de contrato. El pipeline ya existe: preparación SFT, referencias opacas, paridad entre entrenamiento y servicio, ajuste LoRA, predicción, evaluación y replay por MCP. El trabajo abierto está en endurecerlo: ampliar y diversificar el conjunto de entrenamiento, reducir errores en llamadas casi correctas y validar replay contra memorias realmente cargadas en Underpass Kernel. No es una idea en papel. Es un sistema en entrenamiento. Operator no intenta competir con otros modelos. Quiere ocupar otro lugar. La pregunta es más concreta: si un protocolo de memoria está bien definido, ¿puede un modelo compacto aprender a operarlo con disciplina? Underpass Kernel convierte la memoria en una estructura que se puede leer, recorrer, escribir y auditar. KMP define el contrato. Operator intenta aprender a ejecutarlo.