Pravesh Chhabra

Combined agentic analysis with graph-based infrastructure relationships and telemetry context to correlate related alarms, support probable root-cause investigation, and help reduce incident triage time.

Business challenge

A single electrical fault can trigger alarms across many downstream devices. Operators had to work out by hand which alarm was the originating issue and which were symptoms, which slowed investigation and triage.

My role

Led the architecture, delivery, and adoption with reliability teams, and contributed hands-on to the engineering of the agents and correlation services.

Key decisions and trade-offs

• Split the work across specialised agents: one detects new and cleared alarms, one correlates them, and one writes the investigation summary.
• Expose telemetry and device topology to agents as tools through an MCP server, so agents query live context rather than working from a static snapshot.
• Correlate through the infrastructure graph: when a parent device is already in alarm, related child alarms are grouped under it, and electrical rules classify the pattern.
• Keep the language model to reasoning over pre-correlated alarms, producing a plain-English report of the probable root cause for engineers to confirm, not a confirmed diagnosis.

What was built or changed

• A multi-agent pipeline combining alarm monitoring, topology-aware correlation with electrical rules, and LLM-written root-cause reports.
• Telemetry (volts, amps, kW) and parent/child device relationships available to the agents during investigation.

Outcome

In production, giving operations teams related alarms grouped by infrastructure dependency and a probable root cause to investigate first. Measured triage-time results are not published here.

Built and evolved the Insights data platform for one of the largest data center operators in the US, supporting an ecosystem of 300,000+ devices.

Business challenge

Teams needed Industrial IoT (IIoT) telemetry for dashboards and analytics, but building directly on the core telemetry platform created tight coupling and slowed every new data product.

My role

Built and evolved the platform as its lead engineer and architect.

Key decisions and trade-offs

• Democratized IIoT data through configurable directed acyclic graphs (DAGs) for transformation and aggregation, with a versioned draft-and-publish lifecycle.
• Brought time-series telemetry, asset records, and device-hierarchy relationships behind one API, with role-based access and full tracing.

What was built or changed

• Configurable DAG workflows that teams author, version, publish, and share.
• APIs for metrics, device topology, and device health that power operational dashboards.

Outcome

Teams can rapidly build dashboards, analytics, and downstream data products without tight coupling to the core telemetry platform.

A governed multi-agent platform that takes a business brief through analysis, design, security review, development, and testing — with people approving each step.

Business challenge

AI coding tools speed up individual tasks, but enterprise delivery needs traceability, approvals, and audit across requirements, architecture, security, and testing. That is where most agent demos break down.

My role

Designed and built the platform: the requirements, architecture, agents, governance model, and validation approach.

Key decisions and trade-offs

• Durable Temporal workflows for agent work, so long runs survive restarts and failed stages retry with guidance — at the cost of more infrastructure than a simple job queue.
• Typed decisions kept separate from free-form generation, with rules able to override the model.
• Tool access only through an MCP gateway, with scoped policies and single-use approvals.
• Models routed by capability, with local models as explicit, visible fallbacks.

What was built or changed

• Agents for business analysis, requirements, architecture, development, review, QA, and security review.
• Project knowledge base with cited answers; held-out evaluation and regression-gated promotion with rollback.

Validation result (not production use)

On a sample product brief, produced an approved design: 30 prioritized requirements, 53 stories, a 20-component architecture with 14 decision records, and a STRIDE security review. Lesson: real model runs exposed defects test fixtures hid — such as a silent fallback to a small model that gave confident, wrong answers.

An explainable research and decision-support tool for NSE and BSE stocks, where deterministic analysis runs first and an AI agent only explains results it can cite.

Business challenge

Market research tools often present opaque scores or confident AI answers without showing where the numbers came from, how fresh the data is, or how often the signals have been right.

My role

Designed and built the product: data pipeline, analysis agents, AI research assistant, validation framework, and user interface.

Key decisions and trade-offs

• The language model never decides whether a stock will rise. It explains structured results and must fetch every number through tool calls; figures that are not in a tool result are removed.
• Free, official data first — NSE and BSE reports, SEBI, RBI, World Bank, and publisher RSS — with every record labelled for freshness. Nothing is presented as live.
• Opportunity, risk, confidence, and data quality shown separately rather than merged into one score.
• Success criteria fixed before results, and no machine-learning model allowed to influence scores until a validation gate and human review approve it.

What was built or changed

• Analysis agents for technicals, fundamentals, news, sector, institutional flows, macro and global context, and historical similarity, plus an agent that reads SEBI orders and circulars into structured data.
• An AI research assistant with cited sources, running on a local model or on Amazon Bedrock AgentCore.
• Backtesting with Indian trading costs, paper trading, and a Validation Lab tracking accuracy, calibration, and drift.

Lessons so far

Validation is ongoing, so there are no performance results to report. Building it reinforced that trustworthy AI needs data freshness labels, append-only audit logs, and evidence collected under rules fixed in advance.