From Pipeline to Production

How ST Engineering Builds Observable, Safe, and Scalable Agentic AI

Overview

At ST Engineering, Artificial Intelligence (AI) is applied to solve real-world business-critical challenges, where outcomes matter. Delivering reliable outcomes requires the ability to transform emerging technologies into operational capabilities. The Group Engineering Centre (GEC) AI team drives this transformation across the Group.

To close the gap between a working pipeline and production, the GEC AI team built AI Studio, a no-code workflow builder that lets teams build workflows from modular blocks. Working with NVIDIA, ST Engineering is strengthening the platform for production use across its businesses, delivering concrete outcomes across:

• Optimisation: the ability to select the appropriate solver for each workload
• Observability: faster fault diagnosis and more accountable operational decisions
• Guardrails: measurable safety controls that can be evaluated before deployment

This blog shows how AI Studio brings optimisation, observability and guardrails together to move agentic AI from pipeline to production, demonstrated through Maintenance, Repair and Overhaul (MRO) scheduling.

Use Case 1: Optimisation at Scale with AI Studio for Marine MRO

In MRO, scheduling can involve a large number of tasks, each constrained by task dependencies. As the number of tasks grows, finding an efficient schedule quickly becomes increasingly difficult.

To solve the scheduling problem, AI Studio agents call Google OR-Tools, exposed as a Model Context Protocol (MCP) server, to solve it as a mixed-integer programming (MIP) model. This works well for smaller workloads, but as the number of tasks climbs into the thousands, solve times rise sharply. That's where NVIDIA cuOpt comes in. Deployed as a second MCP server behind the same tool contract, it brings GPU-accelerated MIP solving to the same pipeline without changing the agents or their tool calls. 

Testing at Scale

To see how the two solvers compare at scale, cuOpt was put to the test against OR-Tools. cuOpt benchmark runs were executed on NVIDIA H100 GPUs, while OR-Tools was used as the CPU baseline under the same time checkpoints. Both tools were evaluated on the same scheduling tasks, enabling a like-for-like comparison of solver behaviour behind the same MCP tool contract. 

The problem structure is held constant for both solvers, while the task count (N) is scaled from 50 to 2,000. For each task count, the benchmark measures time-to-first-feasible-solution: how long the solver takes to return the first valid schedule.

Below N = 500, the two solvers perform similarly. A crossover occurs at N = 500, after which the gap widens. At N = 1,000, cuOpt reaches the first valid schedule 2.7× faster than OR-Tools; at N = 2,000, cuOpt reaches the first valid schedule 3.7× faster. As the task count grows, the gains from GPU parallelism increasingly outweigh the fixed overhead of GPU execution.

Because task schedules are revised often rather than solved once, those savings add up with every replan.

Figure 1

Use Case 2: Pipeline Observability

AI pipelines aren't foolproof, and when they fail, the failure often shows up only as a bad output. The cause could be a retriever missing context, a tool call failing, or the model reasoning poorly. Without visibility into each step, teams have no easy way to trace the issue.

AI Studio solves this by tracing every pipeline run from start to finish. Incorporating NVIDIA NeMo Agent Toolkit (NAT) observability, it records each step as a structured trace event: when each component starts and ends, which tools are called, the prompts and responses exchanged with the LLM, and how control passes from one component to the next. These traces are exported to Langfuse over the OpenTelemetry Protocol (OTLP), with each run kept separate so that concurrent runs never mix. When something fails, teams can follow the run step by step and see exactly where it went wrong.

In marine scheduling, the agent may revise maintenance windows across hundreds of interdependent tasks. A clear record of how each change was made gives the operations team the confidence to act on it.

Observability in action

With tracing, the team doesn't have to guess which step of the run went wrong. Figure 2 shows a live execution of a standard agent executor on a marine task-scheduling workload. The agent's "Optimise Schedule" tool call fails with a CircularDependencyError, along with an error message that shows exactly where the problem is. Because the trace also holds the full input, output and metadata (session ID, environment), the team can pin the failure to that one tool call instead of seeing a vague "something went wrong."

Figure 2

The agent doesn't stop at finding the error. Once it knows the cause, it runs execute_python_script to fix the problem (Figure 3). It finds the conflicting rows, removes the incorrect prerequisite. It then uses NetworkX, an open-source Python library for graph analysis, to check the task dependency graph and confirm that no cycles remain. Only then does it write the corrected schedule back.

Every step from failure to fix is recorded in the trace. Instead of a black-box repair, users get a decision they can audit and a schedule they can act on with confidence.

Figure 3

Use Case 3: Safety and Compliance

As AI pipelines move into production, they face new risks, such as prompt injection attacks and requests for sensitive information. Guarding against these risks means striking a balance: a guardrail that blocks too much gets in the way of real work. For example, one that wrongly blocks even 5% of valid operational queries could create enough friction for the users.

AI Studio lets teams address both sides of this problem directly on the canvas. Using NVIDIA NeMo Guardrails, teams add guardrails as native pipeline nodes alongside LLM steps, retrievers and tools, with a shared rails configuration defining how they behave. Input guardrails check data entering the pipeline, and output guardrails check responses before they leave it. Because the two are configured and measured separately, teams can tune how well a guardrail stops unsafe content and how often it wrongly blocks valid queries, testing both against their own query patterns before rollout, without changing the underlying pipeline logic.

Benchmarking Guardrails

To evaluate guardrail effectiveness, AI Studio benchmarked NeMo Guardrails against public red-teaming and safety datasets, each mapped to selected risks from the OWASP Top 10 for LLM Applications. 

Each dataset was run through the pipeline twice: once with guardrails disabled and once with input and output guardrails enabled. Both the pipeline's generation step and the guardrails themselves ran on the same underlying model. Each dataset was scored by an evaluator suited to what it tests: an LLM-as-a-judge, a safety classifier, or a refusal classifier. Every score is the percentage of cases where the model behaved safely (resisted the attack, refused the harmful request, or produced a safe output). Figures in brackets show the number of scored cases.    

Guardrails matched or improved safety on every dataset, with the largest gains where the baseline was weakest. Jailbreak-dan rose from 77.27% to 100% and CyberSecEval PI2 prompt injection rose from 76.21% to 86.97%. Where the model was already strong, the guardrails still closed most or all of the gap:  prompt_injection_jailbreak rose from 99.00% to 99.80%, and CyberSecEval 3 Interpreter rose from 93.80% to 100%. 

The results also show the limits. Prompt injection remains the hardest category: even with guardrails, roughly one in eight PI2 attacks still got through. The jailbreak-dan result comes from a small set of just 22 prompts, and 18 Enron Email responses in the guarded run could not be scored.

Benchmarking guardrails before rollout shows where the protection holds and where it doesn't, so agentic AI can be deployed in operations with confidence.

Summary: Building Trust into the Production Layer

Optimisation, observability and guardrails are three examples of how AI Studio has helped our marine MRO users deliver concrete outcomes: choosing the right solver for each workload so schedules return faster as problems grow, diagnosing faults quickly with a clear record of every decision, and applying safety controls that can be measured before deployment.

Behind these outcomes is the ST Engineering GEC AI team, which brings the AI expertise, engineering capability and operational understanding needed to embed these technologies in real business environments. The team bridges the gap between a pipeline that simply runs and a reliable, scalable production system that operations teams across ST Engineering's businesses can trust, adopt and extend to more use cases.