Shippy es un agente marítimo diseñado para decisiones donde un error tiene consecuencias reales. ¿Qué aprendimos al poner IA en una operación en tiempo real, con datos satelitales y embarcaciones cambiando a cada minuto? Aquí te explico la arquitectura, los retos y las lecciones técnicas que Ai2 lleva a otras plataformas ambientales.
Anatomía del agente: alma, skills y config
Pensamos en un agente como tres cosas: alma, skills y config.
- El alma es el
system promptque define la persona de Shippy y sus límites comportamentales. Es explícito, auditable y fácil de revisar cuando hay que ajustar restricciones. - Las skills son instrucciones específicas empaquetadas como archivos Markdown con frontmatter (el mismo spec que usan herramientas de código como Claude Code y Codex). Cada skill es versionable y legible por humanos: por ejemplo, la skill que consulta la API de Skylight resuelve una petición tipo "mostrar actividad pesquera en la EEZ de Panamá el mes pasado" traduciendo "Panama EEZ" a un polígono mediante la API de regiones, consultando eventos de pesca en esa geometría y devolviendo enlaces profundos al mapa.
- La config incluye el harness del agente (
OpenClaw), el modelo (Claude Opus 4.6) y parámetros de ejecución. El alma y las skills están empacadas en una imagen Docker versionada; cambiar de modelo o de harness es una modificación de configuración, no un rebuild.
Esta separación permite auditar la política (alma), iterar las skills y cambiar infra sin romper lo que el analista espera.
Herramientas determinísticas para un agente no determinístico
Los modelos son inherentemente no determinísticos. Entonces, ¿cómo controlar la parte que sí podemos? Con herramientas determinísticas.
Shippy no hace llamadas API crudas. Usa un CLI propósito-built que expone comandos simples como skylight events search con flags tipados. El CLI se encarga de autenticación, paginación y salida estructurada. Resultado: menos bugs sutiles (paginación malformada, encoding de geometría, filtros mal interpretados). Además, el CLI siempre escribe la salida en un archivo JSON local, evitando límites de buffer en pipes y facilitando que pasos posteriores procesen resultados.
Debajo del CLI hay una API tipada: recursos como Events, vessels, regions y tracks, con operaciones search y aggregate. Esas firmas con descripciones campo a campo permiten tests automáticos y documentación que el agente puede consultar.
El patrón es claro: tipado API -> CLI determinístico -> skills que llaman al CLI. Cada capa reduce el espacio de errores de la siguiente.
Aislamiento y hosting: Mothership
Skylight sirve a cientos de agencias y ONG; los datos de un usuario no pueden filtrarse. Para esto construyeron Mothership, una plataforma que provisiona un despliegue Kubernetes efímero por sesión de usuario.
Cuando abres una conversación, el sistema levanta pods con el runtime del agente, sus skills y el CLI. El JWT del usuario se inyecta en el momento de provisión, de modo que las llamadas retornan datos con el scope correcto. Todo lo que el agente escribe durante la sesión queda aislado y se destruye al cerrar.
Dentro del sandbox el agente puede escribir y ejecutar código, instalar dependencias y procesar datasets, pero la red está restringida solo a lo necesario. Esto permite flujos multi-paso seguros sin exponer información entre usuarios.
Evaluando un agente, no solo un modelo
La evaluación también se diseñó para el sistema completo. Shippy se evalúa con datos en vivo: escenarios y rúbricas creadas por expertos en dominio, ponderando criterios según la tarea (por ejemplo, una consulta de eventos de pesca prioriza la precisión de datos y la resolución de la frontera).
El pipeline: un prompt corre en el sandbox, un juez LLM puntúa cada criterio de 0 a 1 explicando por qué, y se calcula un agregado ponderado contra un umbral de aprobación. Ejecutan esto mediante Harbor, con un plugin que levanta una sesión real de Shippy contra la versión a probar. Cada cambio en skills, modelo o datos dispara la evaluación; si hay regresión, la versión no llega a usuarios.
Los resultados revelaron patrones útiles: Shippy mantiene bien la recuperación de datos y los guardrails (por ejemplo, rechaza consultas de inteligencia militar), pero falló en tareas de planificación táctica (se inclinó a dar recomendaciones operativas), en consultas sensibles a geometría por simplificaciones y en un caso inventó un comando CLI inexistente. Esos fallos alimentan mejoras puntuales en las skills y el CLI.
Lecciones prácticas y recomendaciones técnicas
Si vas a construir un agente para un dominio crítico, toma nota de lo que realmente funciona:
- Define límites explícitos en el
system prompt. Evita que el modelo infiera prohibiciones en fine-tuning opaco. - Encapsula APIs complejas detrás de una capa determinística (CLI o SDK tipado). Reduce la superficie de error del modelo.
- Usa esquemas tipados y documentación campo a campo para que tanto humanos como agentes tengan expectativas claras sobre entradas y salidas.
- Versiona skills como artefactos independientes (Markdown con frontmatter) para trazabilidad y despliegue sencillo.
- Aísla cada sesión del usuario con entornos efímeros (Kubernetes pods) e inyección de credenciales en tiempo de provisión.
- Evalúa el agente completo contra datos reales con rúbricas ponderadas y juicios expertos. No te quedes en benchmarks estáticos.
- Diseña para el enrutamiento de modelos: rutea consultas sencillas a modelos pequeños y deja el modelo grande para investigaciones complejas.
- Considera memoria selectiva para persistir hechos relevantes por analista (jurisdicción, fuentes preferidas) sin exponer privacidad.
Hacia dónde van y por qué importa
Ai2 abre Shippy a adoptantes tempranos para que rompan esquemas y encuentren preguntas que el agente responde mal. Las próximas piezas: control de UI por parte del agente (que manipule filtros y rango temporal en el mapa), routing de modelo por costo/latencia y memoria cross-thread para persistir contexto útil.
Mothership está diseñado para ser general. Lo que funciona en marítimo ya influye en EarthRanger y OlmoEarth. Esto no es solo una historia técnica; es una forma práctica de llevar agentes confiables a operaciones reales que protegen ecosistemas y a las personas que trabajan en el terreno.
Shippy no es el fin, es un laboratorio vivo: una mezcla de prompts cuidadosos, ingeniería de infraestructura y evaluación con expertos que convierte promesas de IA en herramientas útiles y verificables.