Qué nos enseñó Shippy sobre cómo construir agentes de IA fiables

Introducción

Shippy es un agente de IA creado por Skylight para apoyar la vigilancia y toma de decisiones en el ámbito marítimo, donde un error puede tener consecuencias operativas costosas y riesgos humanos reales. Más que entrenar un modelo, el reto fue construir un sistema que sea comprobable, que respete límites operativos y que se mantenga fiable frente a datos que cambian continuamente —satélites y señales de embarcaciones que se actualizan en tiempo real— en lugar de trabajar sobre una foto estática del mundo.

Para equipos y autoridades en América Latina, con amplias zonas costeras y Zonas Económicas Exclusivas (EEZ) que requieren vigilancia constante, las lecciones de Shippy son relevantes: la confianza operacional se logra con arquitectura, procesos y controles, no solo con capacidades del modelo.

Anatomía del agente: alma, habilidades y configuración

Skylight define a Shippy como la combinación de tres componentes complementarios:

• Alma (soul): es el prompt del sistema que establece la personalidad del agente y sus límites conductuales. En Shippy, el alma dicta qué está permitido hacer y qué no —por ejemplo, no emitir juicios legales sobre si una embarcación incumple la ley— y esas reglas están explícitas para facilitar auditoría y revisión.

• Habilidades (skills): describen cómo Shippy maneja tipos específicos de solicitudes. Las habilidades siguen el mismo formato que usan herramientas de programación: archivos markdown con frontmatter estructurado. Eso facilita versionado, comprensión por parte de desarrolladores y actualizaciones puntuales sin reconstruir todo el agente.

• Configuración (config): agrupa el resto: el ‘agent harness’ que ejecuta la lógica del agente (en el caso de Shippy, OpenClaw), el LLM empleado (Shippy hoy usa Claude Opus 4.6), y ajustes de runtime. Secretos como claves de API se inyectan al ejecutar, de modo que cambiar el modelo o el harness es un cambio de configuración, no una recompilación del artefacto.

Las tres piezas se consolidan en una imagen Docker versionada: un artefacto desplegable que define exactamente qué es Shippy en cada versión.

Habilidades concretas y flujo de trabajo

Shippy integra varias habilidades para consultas marítimas complejas. Entre las principales están:

• Consultas a la API de Skylight para eventos (comportamientos de embarcaciones, como pesca o transbordo) y metadatos de buques.
• Búsqueda de límites de ZEE (EEZ) y áreas marinas protegidas (MPA).
• Interpretación de trazas de embarcaciones (posiciones y movimientos) sobre la clasificación de actividad que generan modelos como Atlantes.
• Generación de enlaces profundos hacia mapas interactivos de Skylight para que un analista pueda verificar en el mapa cada número y referencia que devuelve el agente.

Un ejemplo práctico: ante la consulta ‘mostrar actividad de pesca en la EEZ de Panamá el mes pasado’, la habilidad detalla que Shippy debe resolver ‘Panama EEZ’ mediante la API de regiones de Skylight (no adivinar coordenadas), luego consultar eventos de pesca dentro de esa geometría, dar formato a los resultados con enlaces al mapa y atribuir metadatos provenientes de socios como Global Fishing Watch o TMT. Preguntas que parecen simples pueden implicar varias habilidades en una sola respuesta.

Herramientas determinísticas para un agente no determinístico

Los agentes basados en LLM son intrínsecamente no determinísticos: no podemos predecir exactamente qué camino lógico elegirá el modelo en cada ejecución. La respuesta de Skylight fue hacer determinísticas las herramientas que el agente usa.

En lugar de permitir que Shippy construya llamadas a la API de Skylight desde cero —lo que causó errores sutiles en prototipos: paginación malformada, codificación de geometrías errónea, filtros mal interpretados—, Shippy interactúa mediante una CLI diseñada ad hoc que encapsula esa complejidad. El agente emite un comando claro, por ejemplo ‘skylight events search’ con flags tipados, y la CLI se encarga de autenticación, paginación y salida estructurada.

La CLI es autodocumentada y ofrece mensajes de error detallados que ayudan tanto al agente como a desarrolladores humanos a recuperarse sin adivinar. Además, su salida se escribe siempre a un archivo JSON local (en vez de pasar por pipes que pueden romperse), lo que evita límites de buffer y permite que pasos posteriores accedan programáticamente a los resultados.

Debajo de la CLI está una API estandarizada: tipos de recurso (Eventos, buques, regiones, imágenes satelitales, trazas), accesibles mediante un par de operaciones comunes: search y aggregate. Las entradas y salidas están definidas mediante esquemas tipados con descripciones a nivel de campo. Esta capa tipada y predecible, junto con habilidades que referencian comandos CLI concretos, reduce el dominio de error cuando el agente toma decisiones inesperadas.

Alojamiento aislado y control de ejecución

Para agentes que actúan en dominios operativos críticos es esencial controlar el entorno de ejecución. Consolidar el alma y las habilidades en una imagen versionada facilita desplegar entornos reproducibles y auditar cambios. El aislamiento en contenedores y prácticas de sandboxing permiten limitar el acceso a recursos sensibles (claves, redes) y ayudar a que cualquier comportamiento inesperado quede contenido y rastreable.

Aunque la implementación concreta varía según exigencias, la idea clave es separar lo que el agente ‘sabe’ y ‘puede hacer’ del entorno en el que corre, de modo que incidentes o experimentos no impacten sistemas productivos.

Evaluar un agente, no solo el modelo

Una conclusión importante es que en dominios como la vigilancia marítima hay que evaluar el agente completo, no solo el LLM. La verificación implica chequear que consultas a la API devuelvan datos correctos, que los enlaces al mapa apunten a ubicaciones exactas, que las atribuciones a socios de datos sean correctas y que los límites del sistema (por ejemplo, no emitir juicios legales) se respeten.

Estas comprobaciones deben ocurrir contra datos en vivo: Skylight opera con señales que cambian continuamente, por lo que la evaluación debe captar cómo el agente se comporta cuando la información es dinámica.

La decisión de poner límites explícitos en el prompt del sistema (el alma) contribuye a la auditabilidad: las reglas están escritas y versionadas, no implícitas en pesos de un modelo.

Hacia dónde vamos

Las lecciones de Shippy —modelo como componente dentro de un sistema más amplio, herramientas determinísticas, imagenes versionadas y evaluación orientada al agente— están informando el desarrollo de otras plataformas ambientales de Ai2. Para organizaciones en América Latina, esto ofrece un marco replicable: si la meta es desplegar IA en operaciones críticas (marítimas, forestales, de pesca), conviene diseñar no solo la capacidad de inferencia, sino también la infraestructura, las APIs y los flujos de verificación que aseguren decisiones responsables y verificables.

En resumen, construir agentes confiables para contextos de alto riesgo exige convertir la incertidumbre del modelo en certidumbre operativa a través de diseño de sistemas, herramientas y procesos de verificación. Shippy demuestra que esa arquitectura es tan o más importante que la elección del LLM.