Building Shippy: lessons from a real maritime agent

The Skylight team at Ai2 has written up what they learned building Shippy, an agent that helps governments and NGOs in more than 70 countries watch what happens at sea: illegal fishing, ship-to-ship transfers, and other maritime activity. It runs on Claude Opus 4.6 and the OpenClaw framework, and the write-up is useful because it is about the plumbing, not the demo.

Their main structural idea is to split the agent into three parts they can version separately: a soul (the system prompt that sets behavior), skills (task-specific capabilities), and config (runtime settings). They also refuse to let the model build raw API calls. Instead it goes through a purpose-built CLI that hides Skylight's messy API, which removes a whole class of bugs from malformed queries, pagination, and geometry encoding. Tool results get written to local JSON files rather than printed to the terminal, so large outputs do not hit buffer limits. Each user runs in an isolated, short-lived session on a Kubernetes platform they call Mothership, with credentials injected at start so one user can never see another's data.

The honest part is the evaluation. Rather than static benchmarks, subject-matter experts write scenarios with weighted rubrics that run against live deployments. Recent runs surfaced three real failure modes: the agent gave tactical recommendations when it should have stuck to decision support, some location-sensitive queries missed events because map boundaries were simplified too much, and it sometimes invented CLI commands that do not exist.

Why it matters

If you are building a production agent, this is a concrete checklist you can copy: wrap fragile APIs in a strict CLI, isolate users at the infrastructure level, and evaluate with expert-written rubrics on live data instead of trusting benchmark scores.