DEV Community

Cover image for Manrova: What We Learned Building a Multi Agent System That Watches, Doesn't Just Answers
sirmos
sirmos

Posted on

Manrova: What We Learned Building a Multi Agent System That Watches, Doesn't Just Answers

This post was created for the purpose of entering the All Things Agentic Hackathon.

The question that started it

Most agent demos answer a question you already knew to ask. Manrova started from a different question: what if the hard part isn't answering, it's noticing?

A vessel produces a constant stream of operational signals: GPS and radar position, crew watch schedules, near-miss reports, compliance records. None of that is missing information. The problem is that nobody has time to correlate four different systems, for every vessel, every day, before a small disagreement becomes an incident report instead of a warning.

So instead of building a chatbot that waits to be asked, we built a system of agents whose job is to watch continuously, investigate when something looks off, coordinate with each other, and only interrupt a human when a decision genuinely needs one.

The shape of the system

Manrova has four specialist agents and one orchestrator, the Officer of the Watch (OOW).

  • A Navigation Integrity Agent checks whether GPS and radar-derived position actually agree.
  • A Crew Readiness Agent looks at rest and duty patterns for fatigue risk.
  • A Fleet Pattern Agent scans near-miss history across the whole fleet, not just one vessel.
  • A Compliance Readiness Agent reasons about certificate exposure relative to a vessel's actual schedule, not just a raw expiry date.

None of them work in isolation. When the Navigation Integrity Agent flags something, the Officer of the Watch decides what other context is worth pulling in, correlates the evidence, and runs it through deterministic risk logic to settle on an overall severity. Below a threshold, Manrova keeps watching, silently. Above it, the OOW prepares a response and stops, waiting for a human to approve anything that goes out externally.

That gate was the single most important design decision in the whole project: the system assists the watch. It does not replace the watch.

The design choice we'd defend the hardest

Safety-critical math never touches a language model. Position deviation, weighted risk scoring, incident state transitions: all deterministic Python, computed the same way every time, auditable, reproducible. The LLM layer sits on top of that structured output, interpreting it and narrating it in plain language for a fleet operator.

It would have been faster to just hand raw telemetry to a model and ask it to decide. It also would have been the wrong call for a system where a false negative has real consequences. Deterministic logic draws the boundary. The agents interpret what's inside it. A human holds final authority when the boundary is crossed.

Building the enterprise trust layer for real

For the Fortified Enterprise Fleet track, we didn't want to just describe these components conceptually, we wanted them actually running.

  • Agent Registry: all five agents (four specialists plus the OOW) are published to a live Firestore collection, versioned, with the exact permissions each one is allowed to exercise.
  • Agent Gateway: every specialist call is routed through a policy check against that registry before it's allowed through.
  • Model Armor (our own guardrail implementation of the same pattern): any untrusted free text, like a near-miss report description, is screened for prompt injection and has PII redacted before it ever reaches a model.
  • Agent Observability: every investigation is wrapped in OpenTelemetry trace spans, so the full reasoning chain is inspectable.
  • Memory Bank: completed investigations persist in Firestore, so a vessel's history survives across sessions instead of resetting on every request.
  • Agent Identity: each agent runs under its own IAM service account, least-privilege, rather than one shared credential doing everything.

Real data, not just demo data

It bothered us that most hackathon demos run on the same three lines of fixture data forever. Manrova's live site supports two paths: a one-click fixed demo scenario, and a real registration flow where any fleet operator can register, add a vessel (a real name or an internal alias, never required to disclose a hull identity), and run an investigation on genuinely entered navigation and crew data. For testing, we used public AIS-derived position data for a real, currently operating vessel as the basis for a realistic scenario, clearly separated from the synthetic demo data used elsewhere in the app.

What surprised us

We expected the hard part to be prompt engineering. It wasn't. The hard part was deciding, agent by agent, exactly what each one was allowed to trust, when it should hand off to another agent, and where control had to return to a human no matter what the model said. Getting that division of responsibility right mattered more than any single prompt.

We also came away convinced that deterministic logic and agentic reasoning aren't competitors. They're better together than either one trying to do the whole job: the deterministic layer sets the boundary, the agents interpret what's happening inside it, and a human holds the final call when the situation actually calls for one.

Try it

Built with Gemini (3.5+) via Google's Agent Development Kit, with Firestore as the persistence layer, and a parallel implementation on AWS Strands Agents SDK running on Amazon Bedrock.

Top comments (0)