Forem: Sreenu Sasubilli

On-Call Incident Triage Panel

Sreenu Sasubilli — Thu, 05 Feb 2026 19:08:33 +0000

This is a submission for the Algolia Agent Studio Challenge: Consumer-Facing Non-Conversational Experiences

What I Built

I built an On-Call Triage Intelligence Panel for SRE and DevOps teams.

Instead of a chatbot, this system proactively surfaces the most relevant operational patterns, likely causes, and first-check actions when an engineer is diagnosing an incident. The goal is to reduce cognitive load and MTTR during high-stress on-call situations — without requiring back-and-forth conversation.

Engineers already work inside dashboards, runbooks, and incident tools. This experience enhances that existing workflow by injecting AI-driven retrieval intelligence directly into incident triage, rather than asking users to “chat” with a system.

Demo

Live Index (Algolia Search Explorer):

https://dashboard.algolia.com/apps/BF4Z56HB7R/explorer/browse/oncall_triage_kb

This demo uses Algolia’s Search Explorer to simulate how the On-Call Triage Panel would operate when embedded inside an SRE workflow (alerting tools, observability dashboards, or internal runbooks).

Example scenarios you can try:

High latency incident
- Query: orders-api p99 latency
- Filters:
- service = orders-api
- env = prod

Network-related incident
- Query: packet loss
- Filters:
- service = orders-api
- env = staging

Database error spike
- Query: db errors
- Filters:
- service = payments-api
- env = prod

You can also explore by filtering on:

service (payments-api, search-api, orders-api)
env (prod, staging, any)
severity (high, medium, low)

What happens:
Each search instantly surfaces the most relevant triage patterns, showing:

Why the pattern was matched (contextual explainability)
Likely root causes based on historical incidents
A copy-ready “first checks” checklist for immediate on-call action

This demonstrates proactive, non-conversational assistance — intelligence is injected directly into the workflow without requiring chat or back-and-forth interaction.

Mock Screenshot (UI Concept):

Source: https://github.com/sasubillis/oncall_triage_mock/blob/main/index.html

How I Used Algolia Agent Studio

Algolia Agent Studio was used to power the retrieval intelligence layer, not a conversational UI.

Indexed Data

I indexed ~100 realistic SRE knowledge records including:

Incident patterns
Historical incidents
Symptoms
Services and environments
Severity levels
Likely causes
First-check remediation steps
Confidence and explanation metadata

Each record is structured to represent operational decision artifacts, not free-form text.

Retrieval Strategy

Instead of prompting an LLM, the system relies on:

AI-powered semantic relevance
Attribute weighting
Typo tolerance
Contextual ranking across multiple signals

For example, a query like:

packet loss payments api

Automatically retrieves:

Relevant historical incidents
Matching triage patterns
Environment-appropriate remediation steps

No conversation is required — the intelligence is embedded in retrieval itself.

Targeted Prompting (Non-Conversational)

Agent Studio is used to:

Explain why a pattern is shown
Rank patterns by confidence and operational relevance
Surface the most actionable next steps first

This is agentic behavior without dialogue.

Why Fast Retrieval Matters

In on-call scenarios, every second matters.

Sub-50ms retrieval allows triage guidance to appear instantly during active incidents, when seconds matter.

Algolia’s fast, contextual retrieval enables:

Sub-second access to operational knowledge
Reduced time spent searching runbooks
Fewer context switches during incidents
Faster identification of known failure patterns

Instead of engineers remembering where knowledge lives, the system remembers for them.

This is especially critical in high-severity incidents where cognitive overload is common.

Why This Fits the Challenge

This project is intentionally non-conversational.

There is no chat interface and no back-and-forth prompting. The AI value comes from:

Learning-based relevance ranking
Pattern recognition across historical incidents
Proactive surfacing of the most useful information at the right moment

It demonstrates how AI-powered retrieval can quietly enhance real workflows — exactly what the Consumer-Facing Non-Conversational Experiences category is about.

Closing Thoughts

Many AI demos focus on talking to users.

This project focuses on helping users think less during critical moments.

By embedding AI directly into operational workflows through Algolia’s retrieval engine, this approach shows how intelligent systems can assist users without ever asking a question back.

CI Guardian: Safe Human-in-the-Loop AI CI Remediation

Sreenu Sasubilli — Tue, 27 Jan 2026 08:40:39 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

CI Guardian is implemented as a GitHub CLI extension (gh ci-guardian) and runs entirely from the terminal, integrating GitHub Actions logs with GitHub Copilot CLI for safe, human-in-the-loop remediation.

Instead of blindly applying AI-generated patches, CI Guardian analyzes real CI logs, summarizes the failure, and attempts a minimal fix only if it’s low-risk. If the fix is unclear or unsafe, it stops and leaves the decision to a human.

The tool can:

Diagnose CI failures with structured root-cause analysis
Attempt minimal, semantic fixes
Automatically open PRs only when patches apply cleanly
Refuse unsafe or low-confidence fixes and escalate to a human when necessary

I tested CI Guardian on both a small demo repo and a real fork of Flask, including scenarios with fork permissions, pull-request-only CI, and multiple workflows.

Demo

Repository:

https://github.com/sasubillis/gh-ci-guardian

The extension entrypoint maps directly to ci_guardian/cli.py, which handles run discovery, log extraction, Copilot prompting, patch validation, and PR creation.

All screenshots below were captured against real repositories with real failing CI runs, including a fork of Flask to demonstrate behavior on a production-scale codebase.

Example usage:

# Diagnose the latest failing CI run
gh ci-guardian diagnose --latest --branch all

# Attempt a safe fix and open a PR if possible
gh ci-guardian fix --latest --branch all

What the demo shows:

CI failures diagnosed into structured JSON
Copilot-generated unified diffs
Automatic PR creation when patches are safe
Graceful refusal with preserved diffs when fixes are unsafe (human-in-the-loop)

This behavior was demonstrated on a real Flask fork where CI failures only surface on pull requests, not direct pushes.

Diagnosis on Failing CI with demo repo

Fix made by ci-guardian on demo repo

PR opened in GitHub by ci-guardian
When a fix is safe and minimal, CI Guardian automatically opens a remediation pull request.

Diagnosis on Failing CI on real repo (Flask)
CI Guardian converts a real failing GitHub Actions run into a structured, machine-readable diagnosis using GitHub Copilot CLI.

Human-in-the-loop Intervention
CI Guardian safely refuses to auto-fix an ambiguous CI failure on a real Flask fork and escalates to human review.

My Experience with GitHub Copilot CLI

GitHub Copilot CLI was used as a reasoning engine, not a blind code generator. I used copilot -p to:

Summarize CI logs into structured root-cause explanations
Generate minimal unified diffs grounded in real failure logs
Draft concise pull request titles and descriptions

The key insight was that Copilot is most effective when paired with strict guardrails. CI Guardian treats Copilot output as a proposal, not a command, and enforces safety checks before applying any change. This results in automation that accelerates debugging without sacrificing trust or correctness.

Building an IPL Cricket Stats Assistant with Algolia Agent Studio

Sreenu Sasubilli — Sat, 10 Jan 2026 01:02:05 +0000

IPL Cricket Stats Assistant — A Conversational AI Powered by Algolia

This is a submission for the Algolia Agent Studio Challenge:

**Consumer-Facing Conversational Experiences**

What I Built

I built an IPL Cricket Stats Assistant, a consumer-facing conversational AI that answers natural-language questions about IPL batting performance.

Users can ask questions like:

“Rohit Sharma highest score”
“Sharma highest score”
“Virat Kohli at Chinnaswamy Stadium”

The assistant returns grounded, factual answers sourced directly from structured IPL match data.

This assistant is designed for everyday cricket fans, not analysts.

It supports natural language questions using familiar terms, nicknames, and partial names, allowing users to explore IPL statistics conversationally without needing structured filters or technical knowledge.

Demo

Live Agent (Algolia Agent Studio):

The agent is published and testable directly inside Algolia Agent Studio.

Frontend Demo:

A lightweight React + InstantSearch demo was built locally to validate real-world usage.

Screenshots
Example queries demonstrating alias resolution, ambiguity handling, and deterministic retrieval

Alias handling
Nickname handling

Canonical name + venue filter

Ambiguity handling + Clarification follow-up

Season filter

How I Used Algolia Agent Studio

Algolia Agent Studio serves as the orchestration layer between:

A fast, structured Algolia Search index
A conversational LLM interface
Carefully designed agent instructions

Key design choices:

Every answer is retrieved using Algolia Search (no guessing).
Each record represents one batsman’s performance in one match, enabling deterministic responses.
Filters are applied whenever possible (batsman, season, venue, match_id).
The agent explicitly handles ambiguous queries (e.g., “Sharma”) by asking for clarification instead of assuming intent.

The result is a conversational experience that feels natural, but behaves like a reliable data system.

Data Source & Modeling

The original data comes from the publicly available IPL Complete Dataset on Kaggle:

https://www.kaggle.com/datasets/patrickb1912/ipl-complete-dataset-20082020

The raw dataset contains ball-by-ball delivery data (150K+ rows).

For this project, I transformed the data in a Google Colab notebook to make it agent-friendly.

Modeling decisions:

Aggregated ball-level data into one record per batsman per match
Precomputed runs, balls, fours, and sixes per match
Added a batsman_aliases field to support natural queries (e.g., “Rohit”, “Hitman” → “RG Sharma”)
Removed the need for cross-record arithmetic inside the agent

This reduced the dataset to ~9.5K clean, deterministic records, optimized for fast retrieval and conversational accuracy.

Why this mattered:

Modeling the data at the “one batsman, one match” level ensures the agent never invents statistics and can answer questions instantly using pure retrieval.

(Optional: Google Colab notebook showing how raw IPL ball-by-ball data was aggregated into one-record-per-batsman-per-match for Agent Studio ingestion:

https://colab.research.google.com/drive/1UXomb6vJfgX2aT8Patvb1HubTHk38eOG?usp=sharing)

Why Fast Retrieval Matters

Cricket statistics are fact-heavy and precision-sensitive.

A single incorrect number breaks user trust.

Algolia’s fast, contextual retrieval ensures:

Sub-100ms responses, even with filters
Accurate grounding for every answer
Clean handling of ambiguity and partial queries
A conversational UX without sacrificing correctness

Instead of generating answers, the agent retrieves facts and explains them.

Final Thoughts

This project demonstrates how Agent Studio + well-modeled data can create conversational experiences that are:

Trustworthy
Fast
User-friendly
Production-ready

Rather than building “just a chatbot,” I focused on designing an agent that behaves like a reliable statistical assistant, grounded in real data and optimized for human queries.

Thanks for checking it out!