We built the monitoring layer we wished we'd had.
ResonanceOps is an early-stage AI infrastructure startup based in Lalitpur, Nepal. We build model monitoring, drift detection, evaluation, and alerting for teams running machine learning and LLM systems in production.
Before ResonanceOps, most of the founding team worked on ML platform teams at larger companies, where the same failure kept happening in different disguises: a model would ship, perform well for a few weeks, and then quietly start making worse predictions — not because anything crashed, but because the world underneath it had shifted.
Nobody found out from a dashboard. They found out from a support ticket, a finance review, or — in the worst case — a customer. By the time the root cause surfaced, it had usually been live for weeks, and the trail of which requests it actually affected was mostly gone.
Existing observability tools weren't built for this. They know how to tell you a service is down. They have no concept of what a healthy prediction distribution looks like, or that a model's hallucination rate just doubled between two versions.
ResonanceOps exists to close that gap — drift detection, evaluation, and alerting built around model behavior specifically, not retrofitted from generic infrastructure monitoring.
“A model doesn't announce when it starts being wrong. Something has to be watching for it.”
The idea we keep building around
Principles we build with
Production traffic is the only ground truth
A model that looks fine on a held-out test set and degrades in production isn't an edge case — it's the default outcome without monitoring. We build around what actually happens after deploy.
An alert without a trace is just noise
Telling someone a metric moved isn't enough. Every signal ResonanceOps raises comes with the request that caused it, so the first response is debugging, not re-discovering the problem.
Monitoring shouldn't need a PhD to configure
Statistical drift detection is genuinely technical. The interface for using it shouldn't be. We spend real effort making the defaults correct so most teams never touch the advanced settings.
Small team, direct answers
Every support message is read by someone who understands the product deeply, not routed through tiers. We'd rather stay small longer than lose that.
A small team, on purpose
We're deliberately staying small while we work closely with our first design partners — every person on the team talks to customers directly.
Engineering
Product & Research
ML Infrastructure
Want to be one of our first design partners?
We're working closely with a small group of early teams. Tell us what you're running.