What a Maritime AI Agent Taught Me About Building Agents That Actually Work
By Warren Schuitema, Founder | Matchless Marketing | The AI Dad
The Allen Institute for AI just published a technical breakdown of how they built Shippy, their maritime AI agent for ocean monitoring. It's aimed at researchers and engineers. But buried inside is some of the clearest thinking I've read on what actually makes an AI agent reliable, and it maps directly to what you're trying to do in your business.
Building an AI agent for a high-stakes operational domain is, above all, a problem of reliability. For a maritime analyst, a wrong answer could send a patrol vessel miles in the wrong direction, costing significant resources that are already stretched thin and potentially putting personnel in harm's way.
That's the world Shippy was built for. Your world is different. But the problem is the same: an agent that hallucinates, goes off-script, or confidently answers the wrong question doesn't save you time. It creates new problems.
Here's what the Shippy team figured out, and how to apply it.
Your Agent Needs a Soul, Not Just a Prompt
This is the framing that stopped me when I read it.
Shippy's architecture is structured around three components: a soul (system prompt), skills (task handling), and config (runtime settings). That's the whole design in one sentence.
The soul is the system prompt. It defines who the agent is, what it will do, and critically, what it won't do. The soul defines what Shippy will and won't do. It won't make legal determinations about whether a vessel is breaking the law, that is a determination for people, not an agent. It also won't speculate beyond what the data supports. These boundaries are explicit in the system prompt, not implicit in fine-tuning, which makes them auditable and easy to revise.
That last part is the key insight. If your agent's guardrails live inside a fine-tuned model, you can't see them, you can't easily change them, and you have no idea when they break. If they live in a written system prompt, you can read them, edit them, and test them in five minutes.
For your business, this means writing your agent's identity like a job description with teeth. Not "you are a helpful customer service agent." Instead: "You handle questions about our services. You do not quote prices. You do not make commitments on timelines. When asked about refunds, you direct to our returns page. Full stop." That specificity is what makes the agent trustworthy.
Don't Let Your Agent Touch APIs Directly
This is where most people's first agent builds quietly fall apart.
One of the more instructive early lessons came from letting Shippy construct raw API calls directly. The result was a steady stream of subtle failures: malformed pagination that silently dropped results, geometry encoding errors, and queries that looked correct but returned wrong data due to misunderstood filter types. The Skylight API has dozens of input types, nested filter objects, pagination cursors, and complex geometry inputs, the kind of surface area that invites model-generated errors.
The fix wasn't a better model. It was a better interface. Shippy "talks" to Skylight through a purpose-built CLI that calls the API, rather than issuing raw calls itself. The Skylight CLI collapses that complexity into a predictable interface. Shippy issues a single command, skylight events search with typed filter flags, and the CLI handles authentication, pagination, and structured output.
Think about what this means for an agent you're building in n8n or with a ChatGPT custom action. Every time you let the model construct a raw API call or a complex SQL query, you're betting on it getting the syntax exactly right, every time, across every edge case. It won't. Give it a narrow, clean tool instead, one that does one thing and handles its own error states. Your agent gets dramatically more reliable, not because the model got smarter, but because you made it harder to fail.
Skills Are How You Keep an Agent Focused
Shippy's skills follow the same agent-skills spec used by coding tools like Claude Code and Codex: plain markdown files with structured frontmatter. This keeps each skill comprehensible, versioned, and easy to revise.
Skills tell the agent how to handle specific types of requests. They're modular, so you can add new ones without touching the soul or the config. A single question posed to Shippy can hook into several skills at once. "Are there vessels operating near the Cordillera de Coiba MPA?" draws on the Skylight skill for data query, a partner database for MPA boundary context, and the vessel track skill for interpreting vessel behavior. All of this happens in a single dialogue turn.
You can apply this pattern right now with a ChatGPT custom GPT or a Claude project. Instead of one massive system prompt trying to do everything, break it into focused instructions per task type. One instruction block for intake questions. One for proposal formatting. One for follow-up emails. When you need to update how the agent handles proposals, you update that block only. Nothing else breaks.
Show Your Work, Every Time
Shippy surfaces the signal and shows its work, citing each data source so analysts can verify and apply their own judgment.
This design choice isn't about transparency for its own sake. It's about accountability. Shippy sticks to maritime questions, presents facts without making legal judgments, declines defense-related requests, and stops rather than guess when a question runs past what its data can answer. Decisions such as where to send a patrol, the team says, stay with "the humans in the room."
The agents I trust most in my own stack do this. When my content agent drops a draft into Notion, it includes a one-line note explaining what source it drew from and what decision it made. When my research agent files a summary, it links the original. That single habit means I can spot errors quickly instead of trusting outputs blindly.
Build this into your agents from day one. Have them explain their reasoning in a note field, a log entry, or a comment. Not a wall of text, one sentence. It takes 30 extra tokens and saves you hours of chasing bad outputs.
The Bigger Picture
Mothership was designed to be domain-agnostic, and Skylight's parent organization Ai2 is already applying lessons from Shippy to EarthRanger, its wildlife conservation platform, and OlmoEarth, its open suite of Earth observation tools. The architecture, soul, skills, config, deterministic tooling, session-isolated sandboxing, and live-data evaluation, represents a blueprint for deploying AI agents in any domain where the cost of a wrong answer is measured in something other than user frustration.
That's the line worth sitting with. For a maritime analyst, a wrong answer is measured in wasted resources and endangered personnel. For a business owner, it might be a client who got a wrong quote, a follow-up that went out with someone else's name, or a lead who fell through the cracks.
Same architecture problem. Same solution.
Building a trustworthy AI agent turns out to be far more about system design than model selection. The model is almost never the problem. Your agent isn't underperforming because you need a newer one. It's underperforming because the soul is vague, the tools are loose, and the skills aren't defined.
The one thing you can do today: Go back to your most-used agent or GPT and write a five-sentence soul for it. What does it do? What does it never do? What does it say when the answer is outside its scope? Those five sentences will do more for your agent's reliability than any model upgrade.
Warren Schuitema is the founder of Matchless Marketing and the creator of The AI Dad, a brand and platform helping small business owners and solopreneurs implement AI tools without hype, overwhelm, or a developer on retainer. He builds, tests, and documents real AI systems live so his audience can follow what actually works inside a running business. Warren is the operator behind a fully automated AI agent workforce managing content, leads, research, and client onboarding at Matchless Marketing. The Shippy case study is the clearest external validation he's seen of the same architecture principles he's been building into his own agent stack.