Entrenar a Compass: la IA dejó de ser un prompt bonito
Lo que aprendimos al diseñar un copiloto conectado al LMS: con datos reales, permisos reales y una regla bastante saludable: publicar debe ser más difícil que redactar.
De chatbot a copiloto operativo
La pregunta dejó de ser “¿responde bien?” y pasó a ser “¿opera con criterio?”
Compass debía acompañar tareas académicas reales: consultar contexto, preparar clases, crear borradores y publicar únicamente con autorización. Ese cambio nos obligó a diseñarlo como producto, no como experimento de prompting.
Antes
- Instructions con todo mezclado
- Archivos cargados sin jerarquía
- Reportes pensados solo como texto
- Éxito medido por “suena bien”
Después
- Reglas críticas compactas
- Knowledge organizado por capas
- Read, Draft y Publish separados
- Pruebas de permisos y errores reales
Un chatbot responde. Un copiloto acompaña decisiones reales.
Cuando empezamos a construir Compass, la idea parecía sencilla: crear un asistente para que los profesores de PLG consultaran información, prepararan clases y redactaran reportes. La palabra peligrosa ahí era sencilla.
Una cosa es generar respuestas académicas correctas. Otra muy distinta es conectarse a un LMS, entender el contexto del profesor, consultar estudiantes autorizados, crear borradores y ejecutar cambios dentro de un sistema real.
Un chatbot que falla deja una respuesta mediocre. Un agente operativo que falla puede guardar información equivocada, publicar sin permiso o recomendar una clase desconectada del estudiante. Ahí entendimos que Compass no debía parecer inteligente: debía ser confiable.
Entrenar un agente no es acumular prompts. Es diseñar una arquitectura que sabe qué hacer, qué consultar y cuándo detenerse.
Más instrucciones no significan mejor entrenamiento.
Al inicio intentamos meter en las Instructions identidad, metodología, formatos, seguridad, Actions, ejemplos y documentos de referencia. En otras palabras: queríamos convertir un mismo bloque en cerebro, biblioteca, manual operativo y reglamento institucional.
El resultado fue predecible: límite de caracteres, prioridades confusas y reglas críticas mezcladas con ejemplos extensos. El aprendizaje fue directo: las Instructions no deben guardar todo lo que el agente sabe; deben conservar lo que el agente nunca puede olvidar.
Instructions
Identidad, seguridad, jerarquía de fuentes, política anti-invención, autenticación y confirmación antes de publicar.
Knowledge
Metodología, formatos, planeación y ejemplos organizados en archivos claros, numerados y fáciles de consultar.
Actions y OpenAPI
La realidad técnica: lo que el agente puede leer, crear o publicar y las condiciones exactas para hacerlo.
El conocimiento necesita jerarquía. No una carpeta llena de fe.
Cargar documentos no equivale a entrenar bien un agente. Compass necesitaba saber cuál archivo consultar, cuándo usarlo y qué fuente debía prevalecer cuando aparecía una contradicción.
Por eso organizamos su conocimiento operativo en archivos numerados: índice, identidad, metodología, formatos, guía de Actions, planeación, escalamiento y ejemplos. El índice no es un adorno; funciona como ruta de navegación para evitar que un ejemplo antiguo termine mandando sobre una regla vigente.
- 00_compass_index.md
- 01_soul.md
- 02_plg_methodology.md
- 03_report_formats.md
- 04_actions_guide.md
- 05_class_planning.md
- 06_internal_escalation.md
- 07_examples_templates.md
Una IA no necesita que su manual operativo se vea bonito. Necesita encontrar la regla correcta antes de cometer una estupidez elegante.
Y por eso Markdown terminó ganando la batalla cotidiana contra el PDF precioso.Markdown para operar. PDF para respaldar.
Los documentos institucionales y visuales siguen siendo valiosos como fuentes originales. Pero las reglas de uso diario, las plantillas, las rutas y los ejemplos funcionaron mejor en Markdown: títulos claros, menos ruido visual, cambios pequeños y consulta mucho más directa.
No se trata de eliminar los documentos bonitos. Se trata de no pedirle al agente que encuentre una regla operativa crítica enterrada en una presentación de veinte páginas cuando puede tenerla limpia, versionable y visible en un archivo breve.
Con Actions, Compass dejó de ser solo generativo.
Mientras Compass únicamente redactaba, bastaba con evaluar la calidad del texto. Cuando lo conectamos al LMS, aparecieron permisos, identificadores, autenticación, payloads, errores, publicaciones y consecuencias reales.
El flujo tuvo que dividirse en tres operaciones diferentes. Consultar no es redactar. Redactar no es guardar. Guardar no es publicar.
Read: consultar con permiso
Recuperar clases, estudiantes asignados o contexto autorizado sin modificar información del sistema.
Draft: preparar algo revisable
Construir una planeación, un comentario o un cierre de ciclo para que el profesor lo valide antes de cualquier publicación.
Publish: ejecutar solo con confirmación
Publicar el resultado final únicamente después de una autorización explícita e inequívoca del profesor.
El contrato técnico manda sobre la buena redacción.
Uno de los aprendizajes más concretos apareció cuando un campo que parecía natural en lenguaje humano no coincidía con el payload aceptado por el LMS. En un reporte, escribir una recomendación en speaking_improve tenía sentido narrativo; técnicamente, ese campo era booleano.
{
"speaking_improve":
"Fortalecer la fluidez oral"
}{
"speaking_improve": true,
"suggestions":
"Fortalecer la fluidez oral"
}El prompt puede orientar el comportamiento. El contrato OpenAPI define qué acepta realmente el sistema. Tipos de datos, campos obligatorios, valores permitidos, efectos secundarios y permisos no son detalles: son el borde entre una recomendación útil y una integración rota.
Los reportes dejaron de ser documentos. Se volvieron interfaces.
Antes, un reporte podía evaluarse por su claridad y su tono. Con integración real entendimos que tiene dos vidas: la visible, que revisa el profesor; y la estructurada, que recibe el LMS.
La capa visible necesita lenguaje humano, observaciones comprensibles y recomendaciones útiles. La capa estructurada necesita IDs correctos, fechas válidas, niveles permitidos, flags, feedback y estados de borrador o publicación.
Esto cambia el propósito del reporte: ya no es un texto que muere después de enviarse. Puede convertirse en evidencia consultable del proceso, alimentar seguimiento y mejorar la personalización futura.
Publicar debe ser más difícil que redactar. El profesor conserva el control; la IA reduce fricción, no responsabilidad.
Personalizar no es llenar una planeación de detalles.
Compass debía apoyar el modelo hiperpersonalizado de PLG, y eso nos obligó a separar personalización real de decoración automática. Poner el nombre del estudiante en una actividad genérica no cambia la experiencia. Agregar páginas de contenido tampoco garantiza una mejor clase.
Personalizar implica conectar nivel, objetivo, historial, habilidad prioritaria, contexto de uso del idioma y evidencia observable de avance. La IA es útil cuando ayuda al profesor a leer esas señales y convertirlas en decisiones de clase viables.
Un agente se conoce en los casos incómodos.
Los ejemplos felices sirven para demostrar una idea. Los errores muestran si existe producto. Por eso probar Compass implicó simular usuarios sin sesión, permisos insuficientes, consultas sin resultados, drafts desactualizados, confirmaciones ambiguas, intentos de acceder a datos no autorizados y fallos al publicar.
El criterio no se evidencia cuando todo sale perfecto. Se evidencia cuando el agente no inventa, no exagera sus permisos y no asegura que una operación funcionó cuando la Action falló.
Lo que haríamos diferente desde el primer día.
Definir el rol antes del tono
Quién usa el agente, qué decisiones apoya, qué datos necesita y qué jamás debe hacer.
Revisar la integración antes de inventar formatos
Si habrá LMS o CRM, la arquitectura de datos y el contrato técnico deben aparecer desde el comienzo.
Separar reglas, conocimiento y ejecución
Instructions compactas, Knowledge organizado y Actions gobernadas por permisos y confirmación.
Probar errores antes de celebrar demos
Un agente entra a producción cuando falla de forma segura, no cuando impresiona durante cinco minutos.
Diez principios que nos deja Compass.
- No se entrena un agente acumulando texto; se diseña una arquitectura.
- Las Instructions contienen reglas críticas, no toda la biblioteca.
- Un Knowledge sin jerarquía también puede desinformar.
- Markdown funciona mejor para conocimiento operativo cotidiano.
- Las Actions convierten al agente en parte del producto.
- OpenAPI manda sobre cualquier formato intuitivo.
- Los reportes deben funcionar para humanos y sistemas.
- Personalizar depende de contexto, no de volumen de texto.
- Publicar exige más control que redactar.
- La calidad real aparece cuando algo falla.
Construir IA educativa real no es ponerle un chat al proceso.
Compass nos confirmó que la tecnología educativa solo tiene sentido cuando ayuda a profesores y estudiantes sin quitarles control, sin enfriar la experiencia y sin esconder las decisiones importantes detrás de una caja negra.
Un buen agente no reemplaza el criterio docente. Le permite consultar mejor, preparar mejor, registrar mejor y personalizar mejor.
La pregunta no es si una IA puede responderle al profesor. La pregunta es si puede ayudarle a tomar mejores decisiones sin quitarle el control del proceso.
Ese es el tipo de tecnología educativa que vale la pena construir desde PLG EdTech Lab.
