Shippy respondió en vivo a una consulta sobre la Zona Económica Exclusiva de Ghana mostrando exactamente su trabajo: la fuente de los límites, el corte de datos, la marca temporal de la consulta y un enlace profundo a Skylight para que un analista verifique cada número. ¿Por qué importa esto? Porque en dominios operacionales de alto riesgo, como la protección del océano, la confianza y la verificabilidad son la prioridad, no la magia del modelo.
Qué es Shippy: alma, habilidades y configuración
Shippy se diseña como tres capas claras: soul, skills y config.
-
El soul es el prompt del sistema que define la personalidad del agente y sus límites operativos. Allí se establece, por ejemplo, que Shippy no hará determinaciones legales ni especulará más allá de lo que los datos soportan.
-
Las skills son módulos concretos que siguen el mismo spec de agent-skills usado por herramientas de código: archivos markdown con frontmatter estructurado. Cada skill es versionada y legible. Entre las skills de Shippy están:
- Consultas a la API de Skylight para Events (p. ej. actividad de pesca, transbordo).
- Resolución de límites de EEZ y MPA.
- Interpretación de tracks de buques y clasificación de actividad.
- Generación de enlaces profundos al mapa Skylight para ver el contexto exacto.
-
La config cubre el resto: qué harness de agente usar (Shippy usa
OpenClaw), qué LLM ejecutar (hoyClaude Opus 4.6), y ajustes de runtime. Elementos secretos como API keys se inyectan en tiempo de ejecución. Cambiar modelo o harness es un cambio de configuración, no un rebuild.
Una decisión clave: empacar el soul y las skills en una imagen
Dockerversionada. Eso hace reproducible exactamente "qué es" Shippy en una versión dada.
Arquitectura práctica: API tipada, CLI determinista, y por qué eso reduce errores
El mayor problema no fue el LLM: fue hacer que el agente fuera predecible al hablar con un API complejo. Skylight tiene entradas anidadas, paginación, geometrías y filtros. Dejar que el modelo arme llamadas HTTP produjo errores sutiles: paginación mal formada que silenció resultados, geometrías mal codificadas y filtros mal entendidos.
La solución fue una capa intermedia simple y robusta:
- Una API tipada con recursos como Events, vessels, regions, imagery, tracks, y operaciones comunes
searchyaggregatecon esquemas y descripciones campo a campo. - Una CLI (interfaz de línea de comandos) que colapsa la complejidad en flags tipados: por ejemplo
skylight events search --area POLYGON --from DATE --to DATE. La CLI maneja autenticación, paginación y salida estructurada. - Las skills llaman a la CLI en vez de construir peticiones crudas. Eso convierte la incertidumbre del modelo en comandos previsibles y testeables.
Pequeño detalle operativo: la CLI siempre escribe salida en un archivo JSON local en vez de pasarla por la tubería del shell. Esto evita límites de buffer y fallos con herramientas downstream como jq.
Seguridad, aislamiento y Mothership
Cada usuario conversa con Shippy dentro de una sesión efímera y aislada. La plataforma que lo hace posible se llama Mothership: un hosting de agentes que provisiona un despliegue Kubernetes dedicado por sesión.
- Al abrir una conversación, se crean pods que empaquetan el runtime del agente, sus skills y la CLI Skylight.
- El JWT del usuario se inyecta al provisionar la sesión, por lo que todas las llamadas API se ejecutan con el alcance de los datos del usuario.
- Los archivos que genera el agente existen solo en esa sesión y nunca se comparten entre usuarios.
- La sandbox permite ejecutar código, instalar dependencias y realizar análisis multi-paso, pero con restricciones de red que limitan el acceso solo a servicios necesarios.
Esto permite que una oficina de pesca en Filipinas vea solo sus Areas of Interest y watchlists, sin riesgo de fuga de contexto entre clientes.
Evaluación práctica: Harbor, escenarios expertos y el juez LLM
Los benchmarks tradicionales fallan para agentes que actúan contra datos vivos. Shippy necesitaba una evaluación que midiera cómo selecciona herramientas, consulta datos en vivo y sabe cuándo detenerse.
Así nació un pipeline de evaluación con estas piezas:
- Escenarios y rúbricas escritas por expertos de dominio. Cada tarea tiene criterios y pesos (p. ej. para consultas de eventos la precisión de datos pesa más que el estilo de respuesta).
- Un sandbox que ejecuta la prompt en una sesión real de Shippy.
- Un juez LLM que puntúa cada criterio de 0 a 1, con razonamiento escrito, y se calcula un agregado ponderado para pasar o fallar.
- Harbor, el framework de evaluación, lanza una sesión real de la versión etiquetada de Shippy y produce resultados timestamped y comparativas con la ejecución previa.
Resultado operativo: si una versión regresa en criterios clave, no se despliega a usuarios.
Errores reales y lecciones aprendidas
Trabajar con un sistema así no es teórico. Skylight registra problemas concretos y cómo los resolvieron:
- Dejar que el agente construya llamadas API generó errores sutiles. Solución: envolver la API con una CLI determinista.
- Consultas sensibles a geometría fallaron por simplificación de límites. Solución: resolver polígonos con la API de regiones en vez de hardcodear coordenadas.
- El agente a veces sobrepasó su rol ofreciendo recomendaciones tácticas; los prompts del sistema deben hacer explícitos los límites (no tácticas de patrulla sino apoyo a la decisión).
- Hubo un caso donde Shippy "inventó" un comando CLI que no existía. Lección: las skills deben referenciar comandos comprobados y la CLI debe tener ayuda extensa y errores detallados.
Tomaaways prácticos para tu propio agente:
- Versiona la imagen
Dockerque contiene prompt + skills. Facilita reproducibilidad. - Define APIs con esquemas y descripciones de campo; evita que el modelo manipule strings libres para llamadas complejas.
- Implementa una CLI o SDK que encapsule autenticación, paginación y formato.
- Aísla cada sesión, inyecta credenciales en runtime y borra artefactos al terminar.
- Evalúa end-to-end con expertos y usa un juez automatizado que explique fallos.
Qué viene después para Shippy
Shippy ya está en adopción temprana y la hoja de ruta visible incluye:
- Control de UI impulsado por agente: pasar de enlaces de mapa a que el agente manipule filtros, región y rango temporal en el mapa Skylight.
- Enrutamiento de modelos: delegar búsquedas simples a modelos ligeros y reservar modelos de frontera para investigaciones complejas.
- Memoria cross-thread: persistir hechos relevantes de un analista (jurisdicción, fuentes preferidas) para no tener que reespecificar contexto en cada hilo.
Estas mejoras buscan reducir latencia, costos y fricción en flujos reales.
El trabajo de Shippy no es solo un caso de uso marítimo. Mothership y las prácticas desarrolladas ya influyen en otros proyectos de Ai2, como EarthRanger y OlmoEarth. La lección central es clara: en entornos donde la vida, recursos y reputación están en juego, la ingeniería alrededor del agente importa tanto o más que el modelo.