A ship that keeps coming back
The ticket is short. The crew of MT Jasper says the internet cuts out completely for a few minutes every couple of hours, then comes back on its own. It has been happening since yesterday.
On the NOC's screen there isn't much to go on. The terminal is online, its signal is normal, and it has no open alarm. A problem that fixes itself every time is easy to push down the queue, blame on the weather, or close with a note to keep an eye on it. When it keeps coming back, the usual next step is a visit to check the hardware.
What the ship shows
The terminal's own logs tell a clear story once you find it. Memory climbs from 37% to 90% over about an hour and a half. Then the unit resets, with the same reason code every time, and each reset takes the satellite link down for about five minutes. It happened at 22:05, 23:53, 01:41 and 03:29 UTC, almost exactly every two hours.
Looked at alone, this is a sick terminal. A memory leak in one box points to swapping the box.
What the fleet shows
Now look at the other 39 terminals. Eight more of them reset 11 to 14 times a day, on all four beams. All nine run firmware 4.2.1. Not one of the 31 terminals on firmware 4.1.3 reset even once.
Nothing is wrong with the ship. The firmware leaks memory, and every terminal that runs it drops every two hours. The fix is one remote rollback or a fixed build for nine terminals, not a visit to one.
Why alarm rules can't see it
A beam outage is the easy case. Ten ships drop together and the hub raises its own alarms. A firmware leak is quieter. The ship in this ticket has no alarm at all, so a rule that maps alarms to runbooks has nothing to match.
Three of the nine terminals do raise a memory alarm. But an alarm only knows about the terminal that raised it. Nothing ties those three alarms to each other, to firmware 4.2.1, or to a ticket from a ship that has no alarm at all.
The first question an experienced engineer asks isn't what the alarm says. It's who else is seeing this.
Reading every ticket against the whole fleet
Before FieldAgent I was a software engineering intern at a satellite networking company, and one thing stood out. The evidence for a ticket is rarely in one place. Logs are spread across the terminal, they differ between models and firmware versions, and finding the right file and knowing which lines matter was mostly done by hand. The people who are fast at it carry that knowledge in their heads. That is also why the fleet question goes unasked. If reading one terminal takes that long, nobody reads forty.
FieldAgent is built to ask that question on every ticket. It reads the terminal's own evidence, compares it with the rest of the fleet, and returns one diagnosis, one severity and one next action. Fix it remotely, send a technician with a specific diagnosis, escalate to the hub, or leave it alone. It only reads, and an engineer approves every action. You can open the ticket from this note and see what it returned.
Two things at once
While it checked the fleet, the agent found something else on beam B4. T-1033, on the older firmware, lost power for four seconds at 02:38 and came back with its antenna 1.65 degrees off target. That is a separate fault with a separate fix, a remote re-point, and it was reported on its own instead of being folded into the firmware story.
What the benchmark shows, and what it doesn't
We test against a simulated fleet of 40 GEO VSAT terminals on four beams. The hardest set has 24 tickets with quiet logs, causes that overlap in time, faults outside the known list, and cases where the right answer is to collect more data. A case only counts as correct when both the cause and the action are right.
On that set the agent got 24 of 24.
It isn't perfect. On this very ticket it missed a short rain fade on MT Jasper itself, a second real fault the benchmark had planted. Across the 24 tickets it reported 10 of 13 such second faults. Once it has the root cause, it doesn't always keep looking, and that is one of the things we are working on.
A simulated fleet is not a real one. The same team wrote the simulator and the knowledge the agent starts from, so a perfect score there shows the approach can work, not that the product does. The next test is closed tickets from real operators, scored against what actually fixed them.
What we're looking for
We're taking two or three design partners. Satcom operators and service providers with a NOC that supports maritime or aviation terminals. You share 50 to 100 closed tickets with their logs, anonymized, and we replay them and score the result against your own resolutions. Then it runs in shadow mode next to your engineers and acts on nothing. Here is how a pilot works.
If your queue has ever sent someone to a ship for a problem that lived in the firmware, write to hello@fieldagent.tech.