The operator and the brief — what we set out to change in 90 days
This is a 90-day account of a Singapore-based operator overseeing multi-asset operations rolling out an AI-augmented operations platform with MLTech Soft as the integration partner. The operator runs a multi-shift operations centre, coordinates vessel movements with bunker calls and pilot bookings, and produces daily operational reporting that goes to a management team and, in summary form, to a regulatory desk.
The brief, agreed before go-live, was specific. Shift handover was taking too long. Exception triage was producing a backlog the team chased every morning before 08:00. Operational reporting was eating roughly two hours of senior-controller time each day. The platform was scoped to reduce all three.
We deliberately did not scope the platform to “decide” anything. Decision authority stayed with humans across the board. The platform’s job was to read context, prepare summaries, propose options, and surface exceptions. The team’s job was still to choose.
Our role as the integration partner was to wire the platform into the operator’s existing systems under ISO 27001 controls, design the rollout in 30-day phases, and run change-management for the operations team alongside the technical work. We are not the platform vendor — which is part of why we can be specific about both the wins and the limits.
So what? The brief looked unambitious from the outside. The rollout team viewed that as the strategy, not a weakness. Most failed maritime AI rollouts in 2025–2026 over-scoped what the platform would “own”. Our scope was deliberately bounded — and bounded scope is what made the 90 days feel like a project, not a bet.
Day 1: where the platform was inserted, and where humans deliberately stayed in charge
On Day 1, the platform was inserted at three points in the operator’s daily workflow.
First, it was given read access — through a controlled API — to the operations dashboards covering vessel movements, berth allocations, bunker calls, and crew rotations. Read access only. No write. No actions.
Second, it was connected to the operator’s communications channels (email, the internal operations chat, and the shared shift-handover document) so that it could read messages and produce drafts.
Third, it was made available to operators as a sidebar assistant in the existing operations console. The assistant could be invoked at any time with a natural-language question, and it could prepare drafts — handover notes, exception summaries, daily report skeletons — for human review.
The places where humans deliberately stayed in charge were spelled out before go-live, and we wrote them into the integration’s permission model so they could not be bypassed:
- Regulatory filings — port state control records, flag-state declarations, MPA submissions — were prepared by humans, with the assistant providing source-material summaries only.
- Safety-of-life decisions — vessel routing in heavy weather, crew medical evacuation calls, ISM-code-triggered actions — were entirely human, with no assistant participation in the decision.
- Commercial commitments — accepting a charter, confirming a bunker price, agreeing a demurrage settlement — stayed with the commercial team. The assistant could not draft these.
- Crew personal data — the assistant’s access to personnel records was limited to the operational context required for shift rosters, not the full HR record.
Here’s what this looked like in practice on a typical Day 1 morning: the senior controller arrived at 06:00, the assistant had already drafted the previous shift’s handover note in plain language, and a junior operator pulled the exception queue with one query instead of opening four browser tabs. Both still made every decision. The platform had not taken anything over.
So what? Bounded scope at insertion is what made every later expansion of capability a small, well-understood step rather than a risk-laden one. The temptation to “let the platform do more” early is the failure mode we worked hardest to avoid.
Day 90: what the daily workflow actually looks like now
Ninety days in, the workflow is different in ways that show up in the day’s shape, not in any single dramatic moment.
The morning shift comes on at 06:00. The previous shift’s handover note is already drafted by the assistant and reviewed by the outgoing controller. The handover meeting runs in roughly half the time it used to — closer to ten minutes than the previous twenty-five. The conversation is now about what to do about open items, not about reading them aloud.
Exception triage, which used to take the team about ninety minutes on a typical Monday, now takes closer to fifty. The assistant pre-sorts the queue. It groups related exceptions, recommends a routing per item, and surfaces the items where it is uncertain. A human still makes every routing decision. The improvement is in attention, not autonomy.
Daily reporting — the report that goes to management and the abstracted version that feeds the regulatory desk — is now drafted by the assistant and edited by a senior controller. The edit takes roughly half the time the full draft used to take, on most days. On the days when the report requires non-routine commentary, the edit takes the same time as before — because the controller is doing the same work.
Rounded indicative outcomes from the first 90 days, expressed in ranges to protect operational specifics:
- Shift handover time: reduced by 30–40%.
- Exception-triage queue depth on Monday mornings: meaningfully shorter, with the team consistently clearing by 08:00 rather than 09:30.
- Daily report preparation effort: roughly halved on routine days; unchanged on non-routine days.
- Operator-reported time spent “reading dashboards just to know what is happening”: down sharply.
What did not improve: Decision speed on complex items. The hard decisions still take the same time, because the hard part was never the information; it was the judgment. The team is now spending that time on the judgment instead of on the information gathering. We treat that as the right outcome.
So what? The platform did not change what the team can do. It changed where their attention goes. That is the more honest framing of what a well-scoped AI operations platform actually delivers at the 90-day mark.
The three usage patterns we did not predict
The three observations below are what the team will tell you at the bar after the rollout meeting. They are not in any vendor brochure.
Pattern 1: Junior staff adopted the assistant faster than senior controllers
We expected senior controllers to be the heaviest users. They have the deepest pattern recognition. They benefit most from amplification. The opposite happened.
Junior operators — staff with 1–3 years in the operations role — adopted the assistant most aggressively. They used it more times per shift than the senior staff did, asked more varied questions, and reported the highest perceived value. The senior controllers used it usefully but conservatively, often validating its outputs by checking the source systems themselves before relying on it.
The pattern that emerged on reflection is straightforward. Senior controllers already know what to ask. Their pattern library is internal. Junior operators are still building theirs, and they treat the assistant like a tireless senior peer they can interrupt at any time — at 02:00 on a Saturday, in the middle of an exception, without feeling they are imposing.
That single behaviour reshaped the operator’s training programme more than any feature in the platform. The next intake of junior operators will be paired with the assistant from week one as a deliberate part of how they learn the operations role. The senior controllers’ training is now lighter: a refresh on how to validate the assistant’s outputs, not a fundamental rework of how they do the job.
Pattern 2: The most-used feature was not the headline feature
The platform’s headline feature, in the vendor’s marketing, was its ability to recommend exception routing. That feature is used. It is not the most used.
The most-used feature, at 90 days, is the assistant’s shift handover drafting. The team writes between 8 and 14 handover drafts per day across shift boundaries, including the small intra-shift handovers when a controller goes for a meal break. Each draft is a few paragraphs. Each is reviewed in under a minute.
In aggregate, that adds up to the single largest time saving the platform delivers, and it was not the lead feature anyone chose the platform for. We have started discussions with similar Singapore operators about scoping a future rollout around the handover use case as the primary driver, with the exception-routing capability as an ancillary benefit.
Pattern 3: The assistant became a shift-handover artefact, not a decision-maker
The team’s relationship with the assistant looks different from what the vendor positioned and different from what the operator expected.
The vendor positioned the assistant as a decision-support layer. The operator expected to use it as a decision-support layer. In practice, after 90 days, the team treats the assistant as a shared artefact — a kind of always-on shift document that any operator can consult, contribute to, and use as the team’s working memory across the day.
When a senior controller hands over to a junior, they often say “the assistant has the context, ask it about the vessel” — and they mean it literally. The assistant is the artefact that carries the day’s state. It is not the decision-maker; it is the medium.
That framing changed how we tune the assistant. We invested more in making its outputs consistent and inspectable, less in making its recommendations sharper. A good shared artefact is one you can trust to be current and complete. A good decision-maker is one you can trust to be right. The team needed the first more than the second.
So what? The features you discover in production are different from the features you bought. Scope your 90-day review to learn from production, not to validate the original brief.
What the platform did not change — and why we are fine with that
A useful list of what stayed the same.
Regulatory filings. Port state control records, flag-state declarations, MPA submissions, and classification society correspondence are still prepared by humans. The assistant provides source-material summaries that speed up the preparation, but the signing party is human and the controlled document is human-prepared. We expect this to stay true through 2026 and likely 2027.
Safety-of-life decisions. Vessel routing in heavy weather, crew medical evacuation, ISM-code-triggered actions — all unchanged. The assistant is available to summarise the situation. It is not invited into the decision. We made that boundary explicit in the integration’s permission model and tested it during pre-go-live.
Commercial commitments. Charter party acceptance, bunker price confirmation, demurrage settlement — all unchanged. The commercial team uses the assistant for context, not for commitment. The platform cannot send a quote.
Engineering and maintenance decisions at the vessel level. The technical superintendent’s authority over vessel-specific engineering choices was never in scope and has stayed that way. The assistant can pull together maintenance history and surface anomalies. The superintendent decides.
We are fine with each of those because the cost-of-error in those areas is high enough that the human round-trip is cheap relative to the risk. That calculation may change in 2027 or 2028. It did not change in this 90 days, and we did not pretend otherwise.
So what? A 90-day rollout that leaves the high-consequence work with humans is not a failure of ambition. It is the right design today. The platform’s value is in the lower-consequence high-volume work, and that is exactly where it earned its place.
What we would do differently if we started again
Three changes, in order of impact.
First, we would invest more upfront in junior-operator training and less in senior-controller change management. The shape of adoption surprised us, and the budget should follow the actual behaviour, not the predicted one. Specifically, we would build a structured “first 30 days with the assistant” programme for every new operations hire, and we would treat it as core to onboarding, not as an add-on.
Second, we would design the rollout’s reporting around the handover use case from day one, instead of the exception-routing use case. The handover capability is what drives the largest single time saving, and a rollout that measures it explicitly will be easier to evaluate and to expand.
Third, we would build observability into the assistant’s behaviour earlier. We have it now — token use, latency, decision logs, the lot — but we built it in phase two rather than phase one. Building it in phase one would have made the first 30 days much easier to debug and would have shortened the learning curve on tuning the assistant’s outputs.
Honest acknowledgment: The 90 days did not go to plan. The plan was approximately right. The team’s actual usage rewrote which features mattered, who used them most, and what we should measure. The right response to that is to re-plan, not to insist the original plan was correct.
So what? A 90-day rollout plan that survives contact with production unchanged is probably a 90-day rollout plan that did not learn anything. Treat the surprise patterns as the most valuable output of the period.
FAQ: AI-Augmented Operations Platform Rollouts
How long should a first-phase AI-augmented operations platform rollout actually take? Plan for three months from go-live to a steady-state operating model, with phased capability expansion. The platform can be installed in weeks; the operating-model change takes longer. Compressing the timeline below 90 days usually means skipping the change-management work, which is where most of the lasting value is created. Operators who rush the rollout typically re-do it within twelve months.
Should an AI operations platform make autonomous decisions in maritime operations in 2026? Not yet, for the high-consequence work. Regulatory filings, safety-of-life decisions, commercial commitments, and vessel-level engineering choices should stay with humans through 2026 — and in most cases through 2027. The platform’s role is to read context, summarise state, and surface options. The decision authority and audit responsibility stay with named humans. Operators who blur that line invite regulatory and insurance complications they have not sized.
Which operations roles benefit most from an AI-augmented platform? Counterintuitively, junior operators. They use the assistant more aggressively, ask more varied questions, and report the highest perceived value. Senior controllers benefit, but more conservatively. The implication for the training plan is to pair every junior operator with the assistant from week one as a structured part of onboarding, not to treat the assistant as a tool that augments existing senior expertise.
What is the integration cost of an AI-augmented operations platform for a Singapore-based operator? The platform subscription is a small fraction of the total. The dominant first-phase costs are the API and integration work to expose existing systems for read and (limited) write access, the audit and permissions work required for ISO 27001 alignment, and the change-management work with the operations team. Operators routinely under-budget the integration and over-budget the model. Plan the opposite way around.
Can a Singapore maritime operator deploy an AI-augmented operations platform under current MPA guidance? Yes, with appropriate human-in-the-loop controls on actions that touch regulatory submissions or safety-of-life decisions, and with an audit trail that demonstrates clear human accountability for outcomes. MPA’s broader digitalisation guidance does not prohibit AI assistance in operations — it expects the operator to demonstrate control, auditability, and clear accountability. That is exactly the integration work that ISO 27001-certified partners are built to deliver.
The Short Version
A 90-day rollout of an AI-augmented operations platform at a Singapore-based operator overseeing multi-asset operations produced measurable workflow gains in handover, triage, and reporting — and a more interesting set of lessons in how operators actually use such a platform.
The team did not need a decision-maker. It needed a shared artefact that carries the day’s state. The feature that mattered most was not the headline one. The staff who benefited most were not the staff anyone predicted. The work that stayed with humans was right to stay with humans.
The honest summary at 90 days is that the platform did not change what the team can do. It changed where their attention goes. That is the change worth paying for in 2026 — and the design pattern we are taking into the next Singapore rollout we scope.
Next step: If you are within six months of a go/no-go decision on an AI-augmented operations platform — and you would value a candid one-hour discussion of what your own first 90 days would actually look like — MLTech Soft offers a complimentary AI integration readiness conversation. We share what we have learned across rollouts like this one and leave you with a written summary. This is an offer of perspective, not a sales pitch. Get in touch via the contact page at mltechsoft.com.
Table of Contents
