This article is by Sanjib Mitra, Platform Product Manager, FINEOS

For insurance technology providers that support core administration, billing and claims systems, platform availability directly affects the services insurers rely on to support their customers.
As a result, the lead up to product releases is an incredibly tense and nail-biting time for both engineering and operations teams. Many sleepless nights have been spent worrying about deploying new software and the potential destructive effect this could have on the performance and uptime of critical, customer-facing environments. Eyes are glued to dashboards, waiting nervously for a red flag to appear, signalling an issue that could lead to a service disruption or dip in performance.
Running critical insurance services at scale
Every engineer knows how it feels to be on-hand day and night to monitor systems and respond to issues before they seriously impact customer experience. This has only been exacerbated by the move from on-premise to cloud based SaaS systems, rapidly expanding the size and scale of the IT estates we are responsible for.
The integrations and services that organisations now use have increased exponentially. We operate a multi-tenant, multi-region architecture spanning more than 400 cloud environments hosted on 200 AWS accounts in up to seven regions globally. Overseeing such an expansive estate naturally means engineers are scanning more dashboards than ever before. Keeping track of performance metrics across multiple platforms during a critical system update is a panic-inducing task for any engineer. But the real challenge for engineers is coordinating deployments across dozens of individual customer accounts where each has its own infrastructure, its own data sensitivity classification, and its own strict SLAs.
When I talk to our teams about the reality of managing this modern cloud environment, I use a specific analogy: it’s like trying to mow your neighbour’s lawn while you’re standing on the other side of the fence in your own garden. It’s easy to mow your own lawn, you can see the task at hand, and you can push the lawnmower yourself. But mowing your neighbour’s lawn is a completely different task. If you don’t have keys to your neighbour’s garden gate, you need to be able to steer a lawnmower you can’t physically touch. In order to do your job, you need remote controls and you need cameras everywhere so you can actually see what you’re doing.
This is what it’s like to run a workload in the AWS cloud, for example. We take security very seriously; each customer workload runs in its own AWS account and operates through federated access, which means we see their environment through telemetry rather than direct entry. We need to have eyes everywhere and we need to see what’s happening at every point in time.
Moving beyond the single pane of glass
To have eyes everywhere, the knee-jerk reaction is to build more dashboards to give a complete view of your estate. Like many financial technology teams, we rely on observability platforms such as New Relic for Java-based APM, browser monitoring, and synthetic testing. Our senior leaders benefit from the user interface and use querying languages like NRQL to understand data from our applications.
But as IT estates and the number and types of our applications grow, if you solely rely on dashboards, you find you no longer have a single pane of glass. Instead, you have many puzzle pieces for an engineer to piece together to build a complete picture.
This is where the Model Context Protocol (MCP) comes in.

How querying the backend changes the day-to-day routine
My team has begun leveraging Large Language Models (LLMs) through MCP to query data directly at its source. MCP is configured inside our own development environment and acts as a secure bridge, enabling AI assistants to interact natively with our observability tools.
The AI queries across 400+ AWS environments, correlating New Relic APM data with CloudWatch logs from specific customer accounts, cross-referencing our Jira ticket history, and pulling cost data from Cost and Usage Report (CUR) files via Amazon Athena.
This capability has transformed how our team works in three key ways.
Firstly, my morning routine looks entirely different. I no longer start my day opening a browser to check multiple dashboards. Instead, I log into my IDE and ask the AI a plain-English question: “Have there been any sudden increases in logs or error rates across our production environments?” The AI evaluates alerts in New Relic, jumps over to customer accounts via an AWS MCP connector to pull raw logs, and validates the root cause.
Secondly, for operations teams, it provides pre-deployment checks before rolling out updates. The AI performs a readiness validation across accounts, verifying the state of the infrastructure to ensure a smooth deployment.
Finally, we can triage mid-incident during an active issue which saves engineers time hunting for logs across multiple accounts. Mapping real-time telemetry against previous Jira tickets and codebases allows us to see if a similar trend occurred six months ago and identifies the exact fix that resolved it.
Protecting customer experience in the autonomous era
At FINEOS, we are gradually moving away from a legacy system where we need to have humans in the loop when we are rolling out deployments. We are moving to a system where we leverage more telemetry through observability, so we no longer need a team of people sitting around waiting for alerts to appear.
MCP enables us to bridge our telemetry, cloud environment, and historical ticketing systems to extract what I call “verified knowledge.” This verified knowledge not only helps us fix incidents faster; it provides insights into potential dips in our system performance before they ever impact the end user experience.
The answer isn’t to abandon dashboards. Instead, we have changed when and how we use them. Dashboards are invaluable for exploratory troubleshooting and validating if and where an incident exists. They give us context which LLMs won’t always have, and great UI design is always going to be vital in our day-to-day work.
However, to build resilience into our fast-evolving IT environment, we must arm our engineers with new, innovative ways to gain visibility into our systems. Deploying the right AI tools finally gives them the automated “eyes everywhere” to keep the entire estate running smoothly.

Be the first to comment