Mukunth Venkatesan is Founder, Director & CEO of Agaram Technologies, a Chennai-based laboratory informatics company specialising exclusively in LIMS, ELN, and SDMS solutions. Under his leadership, Agaram has built Qualis LIMS alongside its Logilab ELN and SDMS platforms, serving both regulated and non-regulated laboratories, with client relationships extending to international research organisations including the UK’s Centre for Process Innovation. With Agaram operating at the frontline of instrument integration, data migration, and laboratory digitisation across India, Mukunth brings a practitioner’s vantage point to this Cover Story — one built on implementation experience rather than platform marketing. In an exclusive interview with Naresh Nunna of Neo Science Hub, he addressed instrument integration failures, common migration missteps, vendor lock-in and data portability, the real scope of AI in production today, and whether Revised Schedule M has genuinely shifted market demand.
Instrument middleware often breaks because the original mapping between an instrument and its software was never properly documented. How often does this show up in your implementations, and what’s the actual fix when you find it mid-project?
Unlike most instrument integration solutions currently available in the market, which are built on rigid, hardcoded architectures requiring vendor intervention for any change, our platform is designed to be fully configurable. This flexibility extends all the way to the end user, empowering laboratory teams to create, modify, and manage their own instrument connections without writing code or depending on external support. This fundamentally different approach not only accelerates deployment and reduces long-term maintenance costs, but also ensures greater adaptability. Notably, due to this configurable framework, we have not encountered this specific issue in any of our implementations to date.
What does a laboratory usually get wrong when scoping a migration — not in the sales conversation, but in the first few weeks after signing?
Most migration requests arrive with a fairly optimistic expectation: that historical transaction data will simply carry over, and that users will be able to pick up their old, ongoing transactions and continue working within the new system exactly as before. In practice, that expectation is rarely what a migration actually delivers. To avoid this mismatch turning into friction later, we make our scope explicit at the proposal stage itself — stating clearly, upfront, that migrated data will be fully searchable, and that queries and reports can be generated from it. What we do not commit to, and are careful to say so from the outset, is treating that migrated data as though it were live, continuable transactions within the new environment.
What would genuine data portability actually look like in a vendor contract, in your experience?
Our approach to this is built around the FAIR data principles — ensuring that data remains Findable, Accessible, Interoperable, and Reusable rather than trapped inside a single proprietary system. In practical terms, this means every customer is given the ability to export their own data in standard, non-proprietary formats: Excel, plain text, or JSON. Because these are open, widely supported formats rather than something only our own platform can read, customers are never structurally dependent on us simply to retrieve what belongs to them. That, in our view, is what genuinely removes the risk of vendor lock-in.
How much of what’s offered under an “AI” label is actually running in production today, versus still on the roadmap?
What we offer today under the AI label is deliberately limited to capabilities that are genuinely working in production: easy search across laboratory data, the ability to compare data sets meaningfully, and automated summarisation of information that would otherwise take a scientist considerable time to compile manually. Beyond that, more ambitious, action-oriented AI capabilities — systems that would take independent decisions or actions rather than simply assisting a human reviewing the data — remain under active research and are not yet part of what we consider production-ready.
Has Revised Schedule M changed what Indian labs are actually asking for?
Despite the introduction of Revised Schedule M and its audit-trail requirements, we have not observed a significant corresponding increase in market demand for our platform. If anything, the pattern we’re seeing runs somewhat counter to what the regulatory deadline pressure might lead one to expect — our non-pharmaceutical customer segment is currently growing faster and performing better than our pharmaceutical segment, which is the segment Schedule M most directly governs.
