Aashrav Shah

Device error logs are processed in batch — so biomedical and field service engineers see failures hours after they happen, long after the window to intervene has closed. It is hardest for smaller, portable devices such as anesthesia machines, which move around the hospital and are difficult to cover with a service contract. Discovery with 20+ biomedical engineers made the real brief clear: this wasn't an analytics problem, it was a delivery problem. Those devices now push their log files in real time through an API for fault analysis, and we're migrating them one at a time toward the streaming platform (case study 02).

At 5TB+/day, batch became the ceiling on everything: ML couldn't run on fresh data, remote diagnostics worked hours behind, and every new data source took ~4 months to onboard. The platform needed a new foundation — HIPAA-compliant throughout the migration, and open to products that didn't exist yet.

I started with service and remote engineers to find where latency actually changed a decision. Most use cases needed data within minutes, not milliseconds — so the North Star became the share of critical telemetry use cases with data available in under 5 minutes, not raw infrastructure latency. We onboarded the highest-value use cases first: fault detection fell from up to 24 hours to about 20 minutes, and the time-critical 20% of use cases are still heading for under 5.

Three things sit on top of the stream. A pipeline health dashboard follows data from device to data lake and shows where packets are lost, delayed or duplicated — teams used it to cut P90 data latency by 30%. Reusable self-service dashboard building blocks, which teams extend for their own needs, grew users by 20%. And metadata governance on Glue Schema Registry, standardizing schemas and lineage across 5+ formats, took onboarding for internal quality and NPI teams from 4 months to days.

Service and engineering teams had plenty of machine telemetry and technical documentation, but getting an answer meant going through several data sources and interpreting the result manually. The data wasn't the bottleneck; the last mile of understanding was.

Two kinds of knowledge feed the assistant. Unstructured material — service manuals, training content — is chunked, embedded and retrieved on demand (RAG), so the model answers from our documents rather than from memory. Structured machine data is queried directly. An orchestration layer brings both together and passes that context to the LLM.

The assistant recommends; it never acts on a machine or makes an irreversible service decision. The engineer makes the call, and we capture whether the recommendation was followed and whether it resolved the issue. I judged the product at three levels: did it retrieve the right information, was the response accurate and grounded, and did engineers investigate issues faster. Next: stronger retrieval and evaluation, tighter guardrails, and automating low-risk, reversible actions while keeping human approval for the rest.

Our product knowledge lived in Confluence, Git repositories and years of requirements, features and user stories in Rally. Turning a new requirement into well-structured engineering stories meant translating all of that by hand — and once the work was delivered, validating it against the acceptance criteria was manual too.

I drove the product side: defining the problems and workflows worth improving, working out where AI adds value, shaping the agent workflows and knowledge sources with engineering, and setting the human-in-the-loop model. Time saved is the headline, but not the whole picture — story quality, acceptance accuracy, human override rate and manual effort removed tell us whether the agents are actually good.