DEV Community: Mrittiga M

# Building a Cloud Incident Responder Agent with TrueForge and Qodo

Mrittiga M — Sun, 30 Aug 2026 17:13:48 +0000

Building a Cloud Incident Responder Agent with TrueForge and Qodo

Cloud incidents can happen unexpectedly — a database connection failure, memory overload, service crash, or application timeout can quickly affect users and business operations. Traditionally, engineers need to inspect logs, identify the root cause, determine a suitable remediation, and then execute the fix manually.

For this project, I explored how an AI-powered agent can assist with this process while keeping safety and human approval at the center.

I built a Cloud Incident Responder, an autonomous DevOps agent that analyzes incident logs, diagnoses problems, proposes remediation actions, and waits for human approval before executing them.

🔗 GitHub: https://github.com/mrittiga/cloud-incident-responder

🚀 What is the Cloud Incident Responder?

The Cloud Incident Responder is an AI-assisted incident-response system designed to help DevOps and cloud engineering teams respond to infrastructure problems faster.

The workflow is:

Incident → Log Analysis → Diagnosis → Remediation Proposal → Safety Validation → Human Approval → Execution → Metrics

For example, when an incident reports a database connectivity problem combined with high memory usage, the agent analyzes the available incident information and determines a possible root cause.

Instead of immediately executing a potentially risky command, it proposes a remediation and asks for approval.

This creates a balance between automation and operational safety.

🎯 The Problem I Wanted to Solve

Cloud environments can generate a large number of alerts and incidents. During an incident, engineers may spend valuable time:

Reading and filtering logs
Understanding the root cause
Determining which action should be taken
Checking whether a command is safe
Executing the remediation
Monitoring the result

The goal of my project was to demonstrate how an AI agent could automate the repetitive parts of this workflow while ensuring that critical actions remain under human control.

The project is particularly useful as a prototype for DevOps teams, cloud engineers, SRE teams, and infrastructure automation workflows.

🧠 How I Used TrueForge

I used TrueForge as the agent harness for the incident-response workflow.

The agent is responsible for coordinating multiple stages of incident handling.

1. Reading the incident

The agent first accesses the incident information and relevant logs.

2. Diagnosing the problem

It analyzes the available information and identifies a likely cause of the incident.

3. Generating a remediation

After diagnosing the issue, the agent proposes an action that could resolve the incident.

4. Safety validation

Before execution, the proposed action is checked against safety rules.

This is important because an autonomous agent should not blindly execute arbitrary commands on infrastructure.

5. Human approval

The agent pauses and waits for approval before executing the remediation.

This introduces a human-in-the-loop safety mechanism.

6. Execution and metrics

After approval, the remediation can be executed and the system records execution-related metrics.

This architecture allowed me to experiment with autonomous incident response without giving the agent unrestricted control over infrastructure.

🛡️ Why Human Approval Matters

One of the most important design decisions in this project was requiring human approval before executing a remediation.

AI agents can generate useful solutions, but an incorrect infrastructure command can potentially cause additional failures.

For example:

AI Agent:

Database connectivity issue detected. Proposed remediation: restart the affected service.

Instead of immediately executing the command:

Agent → Safety Check → Human Approval → Execution

This makes the workflow safer and gives engineers the final decision.

For a production system, I would further strengthen this approach using structured, allowlisted remediation actions rather than allowing arbitrary shell commands.

🔍 How I Used Qodo

I also integrated Qodo Code Review into the development process.

Qodo helped me review the code and identify potential problems that could be overlooked during manual development.

One particularly useful finding involved the project's execution-latency metric.

The review identified that the latency calculation could include the time spent waiting for human approval. That means the metric could represent:

Approval Waiting Time + Execution Time

instead of only:

Actual Execution Time

This was an important observation because accurate observability is critical for an incident-response system.

It showed me that code review is not only about finding syntax errors or obvious bugs. It can also identify issues in metrics, system behavior, safety, and architecture.

📊 Observability and Metrics

Another part of the project was adding metrics around the agent's behavior.

Useful metrics for an incident-response agent include:

Policy checks performed
Approval outcomes
Remediation execution
Execution latency
Successful and failed actions

These metrics can help engineers understand how the agent behaves and identify areas for improvement.

For a production implementation, I would expand this into dashboards containing:

Incident Detection → Diagnosis Time → Approval Time → Execution Time → Recovery Time

This would make it easier to evaluate the effectiveness of automated incident response.

🏗️ High-Level Architecture

The overall architecture can be represented as:

              ┌──────────────────┐
              │ Cloud Incident   │
              │     / Alert      │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │  Incident Logs   │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │   AI Diagnosis   │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │   Remediation    │
              │     Proposal     │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │  Safety Checks   │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │ Human Approval   │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │    Execute       │
              │    Remedy        │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │ Metrics & Logs   │
              └──────────────────┘

💡 What I Learned

Building this project taught me several important lessons.

1. AI agents need guardrails

Giving an AI agent the ability to interact with infrastructure requires strong safety controls.

An agent should have clearly defined permissions and boundaries.

2. Human-in-the-loop systems are valuable

Full autonomy is not always the best solution.

For sensitive operations, allowing the AI to recommend an action while allowing a human to approve it provides a safer architecture.

3. Code review can improve system design

Qodo helped me discover an issue in the way execution latency was measured.

This showed me that automated code review can provide value beyond conventional bug detection.

4. Observability is part of reliability

An incident-response system needs accurate metrics to understand whether automation is actually improving the response process.

5. Production systems need stronger controls

The prototype uses safety checks, but a production-ready implementation should use approaches such as:

Allowlisted remediation actions
Role-based permissions
Audit logs
Rate limiting
Approval policies
Rollback mechanisms
Monitoring and alerting
Structured tool interfaces

🔮 Future Improvements

There are several areas I would like to explore in future versions.

Automated incident classification

The system could automatically classify incidents into categories such as:

Database
Memory
CPU
Network
Authentication
Application failure

Integration with cloud platforms

The agent could be connected to cloud monitoring services and infrastructure platforms to process real-time incidents.

Better remediation policies

Instead of generating arbitrary commands, the agent could select from a predefined set of safe remediation actions.

Incident history

The system could maintain previous incidents and use them to improve diagnosis and remediation recommendations.

Dashboard

A web dashboard could display:

Active incidents
Root-cause analysis
Proposed remedies
Approval status
Execution status
Response-time metrics

🌱 Final Thoughts

This project gave me hands-on experience building an AI-powered DevOps workflow and understanding the challenges involved in safely applying AI to infrastructure operations.

Using TrueForge, I was able to structure the agent's incident-response workflow with diagnosis, remediation, safety checks, approval, and execution.

Using Qodo, I gained another layer of automated code review that helped identify an issue with execution-latency measurement and encouraged me to think more carefully about production-grade safety and observability.

The biggest lesson I learned is that building an AI agent is not only about making it autonomous. It is also about making it predictable, observable, secure, and safe.

The combination of AI agents + DevOps automation + human oversight + automated code review has significant potential for improving how cloud incidents are handled.

🔗 Project: https://github.com/mrittiga/cloud-incident-responder

AI #AIAgents #DevOps #CloudComputing #TrueForge #Qodo #CloudEngineering #SRE #Automation #GenerativeAI #SoftwareEngineering

SmartForm AI — Building Forms with AI in Seconds

Mrittiga M — Mon, 24 Aug 2026 07:23:13 +0000

Hey DEV Community! 👋
For the past 72 hours, our team has been heads-down in an intensive building sprint for DoraHack 2.0 as part of the Dora Fellowship. Today, we are excited to give you an exclusive First Look at what we’ve been working on!
Meet SmartForm AI 🧠⚡
💡 What is SmartForm AI?
Building web forms shouldn't mean spending hours setting up schema validations, state management, and UI fields. SmartForm AI turns natural language prompts into live, ready-to-use forms instantly.
🎥 Sneak Peek & Key Highlights
We’re putting the final polish on our production build, but here’s a preview of what’s coming:
🧠 Prompt-to-Form Generation: Type what data you need, and let AI build the schema and layout automatically.
⚡ Instant Field Logic: Dynamic validation rules created on the fly.
🚀 One-Click Deployment: Go from an idea to a live shareable URL in seconds.
⏰ Full Launch Coming Tonight!
We are running our final test suite and will be dropping the live demo link, walkthrough video, and project breakdown tonight.

Stay tuned for the official drop. In the meantime, what's your biggest pain point when handling forms in web apps? Drop your thoughts in the comments below! 👇

🚀 Building Asha AI: A Vernacular Multi-Agent Voice Platform for Kirana Retail (#VoiceForBharat)

Mrittiga M — Sat, 15 Aug 2026 07:57:32 +0000

📌 1. Introduction & The Problem Statement
In India's fast-evolving retail ecosystem, millions of local Kirana store owners and everyday consumers face digital barriers due to complex application interfaces, text-heavy steps, and language differences.
During the 10 Days of Voice Agents — VoiceForBharat Edition challenge hosted by Murf AI, I chose the Local Retail & Kirana Commerce Track to build Asha AI.
Asha AI is a voice-first Kirana assistant designed to bridge this gap. By enabling real-time, hands-free voice interactions in Indian languages (English, Hindi, and Tamil), Asha AI allows customers to inquire about product prices, check stock availability, request returns/refunds, and automatically escalate complex queries.
🛠️ 2. The 10-Day Building Journey
Here is how Asha AI evolved step-by-step over the 10-day sprint:

Days 1–2 (Foundation & Voice Setup): Configured real-time Web Speech Speech-to-Text (STT) and integrated low-latency Indian voice synthesis (en-IN-aarav) powered by the Murf Falcon TTS API.
Days 3–4 (Personality, Objectives & Guardrails): Defined system prompts, safety guardrails, and customer interaction objectives for regional Indian retail.
Days 5–6 (Multilingual Support & Live UI): Added language switching for English, Hindi (हिंदी), and Tamil (தமிழ்), paired with a glassmorphism frontend dashboard displaying active state and live call metrics.
Days 7–8 (Memory, Tools & Outbound / Escalation Systems): Integrated SQLite for database lookups (stock, pricing, customer history), structured call logging, and automated store manager escalation tickets (#HUM-XXXX).
Day 9 (Multi-Agent Handoff): Implemented sub-agent orchestration where the Asha Main Agent hands off refund/damaged goods queries to a specialized Returns & Refunds Agent.
Day 10 (Documentation & Showcase): Consolidated architecture, code, performance metrics, and build learnings into this public guide. ⚙️** 3. Complete Architecture & Workflow Diagram** Here is how audio, user text, backend logic, database queries, and voice output flow through Asha AI: ┌─────────────────────────────────────────────────────────────┐ │ USER INTERFACE │ │ [ Browser Mic Input / Text Chat / Button Triggers ] │ └──────────────────────────────┬──────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ ASHA AI CORE PROCESSING ENGINE │ │ (python: day9_asha_full_dashboard.py) │ └───────┬──────────────────────┬──────────────────────┬───────┘ │ │ │ ▼ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ SQLite Inventory │ │ Sentiment Engine │ │ Session Manager │ │ & Call Logging │ │ & Escalation │ │ & Agent Handoff │ └────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘ │ │ │ └──────────────────────┼──────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ MURF FALCON TTS API │ │ (Low-Latency Speech Generation via en-IN-aarav) │ └──────────────────────────────┬──────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ AUDIO & UI FEEDBACK │ │ [ Real-Time Voice Output & Glassmorphism Dashboard ] │ └─────────────────────────────────────────────────────────────┘

📋 Detailed Step-by-Step Workflow:

User Voice Input: The user clicks the Voice Mic button or types a query in English, Hindi, or Tamil.
Intent Parsing & Sentiment Engine: Asha's backend analyzes input keywords (e.g., "price", "honey", "damaged", "human") and logs tone sentiment (Positive, Neutral, Negative).
Database & Multi-Agent Routing:
- Inventory Enquiries: Queries the local SQLite inventory table.
- Returns & Refunds: Hands context over to the specialized Returns Agent.
- Frustration / Human Help: Triggers an explicit Human Escalation event.
TTS Generation & UI Feedback: Transformed text is rendered into speech via the Murf Falcon TTS API, while live metrics update instantly on the glassmorphism dashboard. 🎯 4. Key Project Features Highlight
Murf Falcon TTS Integration: Lightning-fast text-to-speech audio rendering using Murf AI's conversational voice endpoints.
Sub-Agent Handoff: Seamless transition between main agent conversation and specialized sub-agents while retaining session context.
SQLite Live Inventory Engine: Direct database lookups for product stock and order logs.
Real-time Glassmorphism Analytics: Displays live audio visualizer state, call success rates, customer sentiment metrics, and stock updates. 💥** 5. Challenges Faced & Solutions** ❌ Challenge 1: Latency & Audio Buffering on Fast Responses
Root Cause: Generating audio responses in real-time caused small playback buffers when processing long strings or switching languages quickly.
Solution: Priority queuing with direct streaming from the Murf Falcon API while implementing a fallback browser Web Speech audio pipeline to guarantee uninterrupted voice response fallback. ❌ Challenge 2: Context Retention During Sub-Agent Handoffs
Root Cause: Session context (user details, prior items mentioned) was clearing when transitioning between Asha Main Agent and Returns Specialist Agent.
Solution: Created a global Python session state manager (session_state) that preserves conversational context, order history, and sentiment logs across agent boundaries. ❌ Challenge 3: Vernacular Code-Mixed Speech Processing
Root Cause: Handling Hinglish/Tanglish mixed phrases (e.g., "Honey oda price enna?") resulted in misclassified database queries.
Solution: Normalized incoming transcripts into target item keywords using a dictionary mapper before executing SQLite queries. 💻** 6. How Readers Can Setup & Run Asha AI** Follow these steps to test the project locally: Step 1: Clone the Repository git clone https://github.com/mrittiga/voice-for-bharat-challenge-2026.git cd voice-for-bharat-challenge-2026

Step 2: Configure Environment Variables
Create a .env file in your root folder (never commit API keys publicly!):
MURF_API_KEY=your_actual_murf_api_key_here

Step 3: Run the Application
python day9_asha_full_dashboard.py

Open your browser and navigate to http://127.0.0.1:8000 to interact with the voice agent interface.
🔮 7. Future Enhancements

Adding WebSocket streaming audio transport for near zero-latency full duplex voice communication.
Expanding voice support to additional Indian regional languages (Telugu, Kannada, Marathi).
WhatsApp Business API integration for sending instant invoice receipts. 🔗** 8. Links & References**
GitHub Repository: mrittiga/voice-for-bharat-challenge-2026
Murf AI Falcon Documentation: Falcon API Docs