DEV Community: Yogesh Jamdade

Nova — Intelligent Incident Triage

Yogesh Jamdade — Wed, 21 Oct 2026 15:44:18 +0000

Nova — Intelligent Incident Triage with Cloudflare Clef AI

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Nova is an AI-powered incident triage platform that turns operational alerts into structured, actionable incident classifications.

When a production alert arrives, engineers often need to determine its severity, identify the responsible team, and decide whether it requires immediate attention. Doing this manually for every alert takes time and can delay incident response.

Nova automates this initial triage process using Cloudflare Clef AI and LangChain. It analyzes an incident's title, description, affected service, environment, source, and metadata to produce a structured classification.

Key features

AI-powered severity classification: Categorizes incidents as low, medium, high, or critical.
Intelligent team assignment: Recommends the payments, backend, database, or platform team.
Urgency assessment: Converts an AI-generated urgency score into a boolean decision using a configurable threshold.
Structured outputs: Extracts typed AI responses and validates the resulting classifications.
Input validation: Uses Zod to validate incident payloads before processing.
REST API: Provides endpoints for health checks and incident triage.
Error handling: Handles malformed JSON, invalid inputs, missing configuration, and upstream AI failures.
Modular architecture: Separates AI integration, triage logic, shared schemas, and API handling into dedicated packages.

Nova is designed as a foundation for incident-management workflows. Its recommendations can help engineers prioritize incoming alerts, while the actual incident response remains under human or downstream system control.

Demo

The ideal demo walks through submitting a production incident, validating the request, running AI-powered classification, and inspecting the resulting severity, recommended team, urgency, and reasoning.

Code

GitHub repository: https://github.com/yogesh201sits/nova

Nova is built with TypeScript and Bun in a modular monorepo.

The repository separates the main responsibilities into packages:

@nova/api — HTTP endpoints and request handling.
@nova/clef — Cloudflare Clef AI integration.
@nova/triage — Incident classification orchestration.
@nova/shared — Shared types and validation schemas.

This structure keeps the AI provider integration independent of the API layer and makes it easier to extend the classification pipeline.

How I Built It

Nova combines Cloudflare Clef AI, LangChain's RunnableLambda, Hono, Zod, TypeScript, and Bun.

1. Cloudflare Clef AI for classification

Cloudflare Clef AI acts as the classification engine. Instead of relying exclusively on manually defined keyword rules, Nova sends incident context to the model along with the classification criteria.

The integration requests three types of answers:

Task	Output	Purpose
Severity classification	Choice	Determines incident severity
Team assignment	Choice	Recommends a responsible team
Urgency assessment	Numerical score	Helps determine whether immediate attention is needed

Where provided, the choice responses include confidence information.

This approach lets Nova evaluate the incident context rather than simply mapping individual keywords to predetermined categories.

2. LangChain RunnableLambda for orchestration

I used LangChain's RunnableLambda to encapsulate the custom Clef integration behind a reusable runnable interface.

It handles the provider-specific inference call and keeps that implementation separate from the core triage logic.

This separation makes the pipeline easier to maintain and leaves room for future changes to the underlying AI integration.

3. Structured result extraction

AI output needs to be converted into predictable application data before other services can consume it.

For example, a team classification may look like this:

{
  "type": "choice",
  "choice": "payments",
  "confidence": 0.8831
}

Nova extracts the selected team, validates it against the supported categories, and maps the result into its incident response schema.

The same process extracts the severity choice and urgency score. Urgency is then evaluated against a configurable threshold:

urgent = urgencyScore >= URGENCY_THRESHOLD;

The current threshold is 0.5.

Keeping extraction and validation separate from inference means the application does not have to trust raw model responses as final application data.

4. Hono and Zod for the API

Hono provides the HTTP API, while Zod validates incoming incident payloads and enforces consistent data structures.

The main endpoints are:

Health check

GET /health

Returns the API's health status.

Incident triage

POST /incidents/triage
Content-Type: application/json

Example request:

{
  "title": "Checkout service outage",
  "description": "Payment requests are failing.",
  "source": "Application monitoring",
  "service": "checkout",
  "severity": "medium",
  "environment": "production",
  "metadata": {}
}

The API validates the request, invokes the triage pipeline, and returns a structured incident result.

An illustrative response might contain:

{
  "data": {
    "incidentId": "example-incident-id",
    "severity": "critical",
    "team": "payments",
    "urgent": true,
    "summary": "checkout: Checkout service outage",
    "reasoning": "Critical severity detected. Immediate investigation is recommended.",
    "status": "open",
    "createdAt": "2026-10-15T04:40:00.000Z"
  }
}

This is an illustrative response, not a claim that every incident produces these values. Actual classifications depend on the supplied context and model output.

5. A modular TypeScript architecture

Bun workspaces provide the monorepo foundation, while TypeScript keeps the application logic type-safe.

The architecture separates provider communication from classification logic and HTTP handling. That separation makes it possible to evolve the API, refine classification rules, or introduce additional integrations without tightly coupling every part of the system.

A Next.js interface is also part of the technology stack for submitting incidents and viewing their classifications.

Why Does Open Innovation Matter?

Open innovation makes it easier to experiment with AI-powered infrastructure without building every component from scratch.

For Nova, the combination of Cloudflare's AI tooling, LangChain's composable interfaces, Hono, Zod, and TypeScript made it possible to build a complete classification pipeline from independently developed tools.

Each component has a clear responsibility:

Cloudflare Clef AI provides the inference capability.
LangChain provides a reusable orchestration abstraction.
Hono handles HTTP requests.
Zod validates inputs and data structures.
TypeScript and Bun support modular development.

This composability matters because an AI-powered system should not have to be tied to one monolithic framework.

A note on openness: Nova uses Cloudflare Clef AI through its inference interface. I am not claiming that the underlying model weights are open-weight or that this integration is equivalent to running a model locally. The open-innovation value here is the ability to combine interoperable tools and open-source application frameworks into a useful system.

That architecture also creates a foundation for experimenting with alternative inference providers or self-hosted models in the future, subject to compatibility and implementation work.

My Agent Session

[Add your DevRelay agent session link or embed your session here, if available.]

This section is optional. Include it if you used DevRelay and saved a session that demonstrates how you built or iterated on Nova.

The Lazy Payoff

The goal of Nova is to reduce the repetitive work between receiving an alert and understanding what to do next.

Without automated triage, an engineer may need to inspect an alert, interpret its context, determine its likely severity, identify the responsible team, and decide whether immediate attention is necessary.

Nova consolidates those initial classification steps into a single API request.

The potential payoff is:

Less repetitive manual classification.
More consistent incident metadata.
A quicker starting point for prioritization.
Structured results that downstream tools can consume.

I have not established a measured time-saving figure yet, so I would rather not invent one. A useful next step is to benchmark manual triage against Nova-assisted triage across a representative set of incidents.

Nova's output is a recommendation, not a substitute for monitoring signals, on-call routing, or human judgment during critical incidents.

Prize Categories

[Add the applicable partner categories from the official challenge rules.]

What's Next?

Some areas I would like to explore next include:

Testing classification quality against a labeled incident dataset.
Measuring latency and classification accuracy across incident types.
Adding integration points for incident-management tools.
Supporting alternative inference backends.
Improving observability around inference failures and classification outcomes.

The long-term goal is to make incident triage more consistent, extensible, and easier to integrate into existing operational workflows.

Final Thoughts

Nova started with a practical question: Can we turn an unstructured operational alert into a useful, structured starting point for incident response?

By combining Cloudflare Clef AI with LangChain and a modular TypeScript API, Nova demonstrates one way to approach that problem without tightly coupling the entire application to its AI provider.

There is still work to do around evaluation, reliability, and real-world integrations, but the project provides a foundation to build on.

Thanks for reading!

If you're working on AI infrastructure, incident management, or developer tooling, I'd love to hear what you'd improve or build next.

Mercy: Because “My Bad” Isn’t a Rollback Strategy

Yogesh Jamdade — Tue, 13 Oct 2026 15:55:57 +0000

This is my submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

AI agents are becoming capable of doing real work: editing files, modifying databases, and executing multi-step workflows. But when an agent makes a mistake, recovering from it can be surprisingly difficult.

An agent might delete a file it shouldn't have touched, overwrite important content, or modify the wrong resource. Knowing that something went wrong isn't enough. We need a reliable way to undo the damage.

That's why I'm building Mercy — universal undo and recovery infrastructure for AI agents.

Mercy is designed to let AI agents recover from their own actions through snapshots, action journals, and undo operations. Instead of relying on an agent to remember what it changed or generate a fix, Mercy records the information needed to reverse supported actions.

I'm starting with filesystem operations and database integrations, with an extensible adapter architecture that can support additional tools and resources.

The idea is simple: AI agents should be able to make mistakes without making recovery a nightmare.

Who would pay for it?

Mercy is designed for developers and teams building AI agents that interact with real-world resources, including:

AI coding tools: Recover files after an agent overwrites or deletes the wrong code.
AI automation platforms: Reverse unintended changes made during automated workflows.
Enterprise AI teams: Build safer agents that interact with internal systems and business data.
Agent framework developers: Integrate recovery capabilities without implementing custom rollback logic for every resource.

The long-term business opportunity is to offer Mercy as a developer-focused SDK and MCP integration, with potential hosted infrastructure for teams that need centralized recovery, monitoring, and operational controls.

Demo

Code

GitHub: github.com/yogesh201sits/mercy

How I Built It

Mercy is built with TypeScript and Bun using a modular architecture.

The core is designed around a few key components:

Action Journal: Records supported operations and the information needed for recovery.
Snapshots: Preserve resource state before changes so previous content can be restored.
Undo Engine: Uses recorded action information and snapshots to reverse supported operations.
Adapters: Encapsulate resource-specific behavior, starting with the local filesystem and PostgreSQL.
Runtime and SDK: Provide a reusable interface for applications integrating Mercy.
MCP integration (in development): The goal is to expose Mercy's recovery capabilities to AI applications through the Model Context Protocol.

Each resource has different recovery requirements. Restoring a file is not the same as reversing a database operation, so adapters handle the resource-specific details while the core coordinates the recovery process.

I'm also exploring agent-based testing to simulate realistic scenarios: an agent changes a file, makes another modification, or deletes a resource, and Mercy is tested on whether it can restore the earlier state.

The goal is to make recovery a reusable infrastructure capability rather than something every agent developer has to build from scratch.

Why Does Open Innovation Matter?

AI agent infrastructure should not be locked into a single model provider or agent framework.

Open innovation makes Mercy useful across different AI stacks. Developers should be able to choose their preferred model, framework, and tools while still having access to recovery capabilities.

It also makes the architecture extensible. Developers can implement adapters for their own resources and define how supported operations should be reversed, instead of waiting for a closed platform to support every integration.

Most importantly, open-source development lets people inspect how recovery works, test its behavior, contribute adapters, and identify limitations before trusting it with important data.

For infrastructure that deals with potentially destructive actions, transparency and extensibility matter.

Prize Categories

EndpointX : AI Backend Generator

Yogesh Jamdade — Fri, 09 Oct 2026 03:23:49 +0000

EndpointX: From Prompt to Live Backend in Seconds

This is my submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

EndpointX is an AI-powered backend generator that converts natural language prompts into functional backends with live API endpoints.

Developers often spend hours setting up servers, creating routes, writing boilerplate, and testing APIs before they can focus on the actual product. EndpointX aims to reduce that repetitive work.

Instead of manually building a backend from scratch, describe what you need in plain English. EndpointX generates the backend code, executes it inside an E2B sandbox, and provides a live server URL with working API endpoints.

With EndpointX, you can:

Generate backend code from natural language prompts.
Execute generated code in an isolated sandbox.
Get a live URL for the generated backend.
Test API endpoints through a built-in API Playground.
Automatically detect request parameters and input fields.

The goal is simple: spend less time on backend setup and more time turning ideas into working products.

Demo

Watch EndpointX in action:

Watch the EndpointX Demo on YouTube

How Does It Help People Touch Grass?

The idea behind this challenge is to use technology to make our time more valuable.

Developers can spend hours on repetitive tasks such as creating routes, configuring servers, wiring up backend logic, and testing endpoints. These tasks are often necessary, but they can slow down experimentation and take time away from more meaningful work.

EndpointX aims to reduce that initial friction.

Want to prototype a task management API? Describe it.

Need an endpoint to manage product information? Describe the expected behavior.

Want to experiment with a backend idea before committing to a full implementation? Generate it and test the result.

By automating parts of backend development, EndpointX helps developers move from an idea to a testable prototype faster.

Less time on repetitive setup means more time for creative problem-solving, building useful products, and stepping away from the screen.

How I Built It

EndpointX combines a React frontend, a Node.js backend, an AI orchestration layer, and sandboxed code execution.

Tech stack

React: Frontend interface and API Playground.
Tailwind CSS: User interface styling.
Node.js: Backend services and server-side logic.
LangChain: Orchestration of the AI-powered backend generation workflow.
Groq: Access to the language model used for code generation.
E2B: Sandboxed execution of generated backend code.

Architecture

Natural Language Prompt
          |
          v
    LangChain Agent
          |
          v
  Backend Code Generation
          |
          v
     E2B Sandbox
          |
          v
    Running API Server
          |
          v
   Live Endpoint URL
          |
          v
    API Playground

The process begins when a user describes the backend they want. The AI layer processes the prompt and generates the corresponding backend code.

EndpointX then prepares the execution environment and runs the generated code inside an E2B sandbox. Once the server is running, the user receives a live URL and can test the generated endpoints through the API Playground.

The key idea is to go beyond code generation and make the generated backend immediately testable.

Why Open Innovation Matters

Open innovation makes projects like EndpointX possible by allowing developers to build on existing tools, experiment with different approaches, and improve systems without creating every component from scratch.

For EndpointX, LangChain provides building blocks for AI orchestration, while the broader open-source ecosystem makes it easier to extend the application and experiment with alternative models and backend frameworks.

Using Groq for model access also gives the project flexibility to explore different supported language models as requirements evolve.

Compared with depending entirely on a closed, all-in-one backend-generation service, this architecture provides greater flexibility in how the AI workflow is assembled and how generated code is executed.

Open innovation also creates opportunities for other developers to contribute new capabilities, improve code generation, add framework support, and make AI-powered development tools more accessible.

The exciting part isn't just generating code with AI. It's making the entire workflow open to experimentation and improvement.

Code

Explore the source code and contribute on GitHub:

Repository: https://github.com/yogesh201sits/endpointX

EndpointX is built to be explored, tested, and improved by the developer community. Feedback, bug reports, and pull requests are welcome.

Run It Locally

Clone the repository:

git clone https://github.com/yogesh201sits/endpointX.git
cd endpointX

Create a .env file inside the backend directory:

E2B_API_KEY=your_e2b_api_key
GROQ_API_KEY=your_groq_api_key

Install dependencies and start the frontend:

cd frontend
npm install
npm run dev

In a separate terminal, start the backend:

cd backend
npm install
npm run dev

Refer to the repository instructions for any additional environment or sandbox configuration.

What's Next?

EndpointX is still evolving. Some areas I'd like to improve include:

More reliable backend code generation.
Support for additional backend frameworks and patterns.
Better error detection and recovery when generated servers fail.
Improved endpoint discovery and request validation.
A smoother developer experience for testing and iterating on generated APIs.

The long-term vision is to make backend prototyping as natural as describing an idea.

My project - Persista

Yogesh Jamdade — Mon, 05 Oct 2026 06:37:43 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built Persista, an AI memory infrastructure that gives AI applications a persistent memory layer.

I built it for a friend who uses AI tools frequently but kept running into the same problem: every new conversation started from zero. Important preferences, previous decisions, project context, and useful information were repeatedly lost between conversations.

Persista lets an application remember, search, and recall information across conversations instead of treating every interaction as completely independent.

The core idea is simple:

AI should remember the context that matters.

Persista provides semantic memory, hybrid retrieval, and knowledge-graph capabilities so an AI application can retrieve relevant context when it needs it.

Instead of sending an entire history to a model, the system can store useful memories and retrieve the most relevant information for the current interaction.

What Persista provides

Persistent memory for AI applications
Semantic search for finding conceptually related memories
Hybrid retrieval combining different retrieval strategies
Knowledge graph relationships between stored information
Memory operations such as remember, search, recall, and graph
MCP support so AI agents can interact with the memory layer through tools

The goal wasn't to build another chatbot.

It was to build the infrastructure that lets an AI application remember the person using it.

Demo

Live Demo: [https://persista-mu.vercel.app/]

The demo shows how information can be stored as memory and later retrieved when it becomes relevant to a new interaction.

Code

GitHub: https://github.com/yogesh201sits/persista

Persista is built as a backend-focused AI memory system rather than a single-purpose chatbot, so the memory layer can be integrated into different AI applications and agent workflows.

How I Built It

Persista is built around open-source AI components and an infrastructure-first architecture.

The system uses:

Bun + TypeScript for the runtime and application layer
Hono for the API
PostgreSQL / Neon for persistent application data
Prisma for database access
Qdrant for vector-based semantic retrieval
Neo4j for knowledge-graph relationships
Hugging Face embeddings for semantic representations
LangChain for AI/retrieval components
Groq for model inference
MCP for exposing memory capabilities to AI agents

At a high level, the flow looks like this:

AI Application / Agent
          │
          ▼
       Persista
          │
     ┌────┴─────┐
     │          │
  Memory     Retrieval
     │          │
     ▼          ▼
PostgreSQL   Qdrant
     │
     ▼
Knowledge Graph
     │
     ▼
   Neo4j

When an application wants to remember something, Persista stores the information and creates the representations required for later retrieval.

When the application needs context, Persista can search the stored memories and return the information most relevant to the current request.

The knowledge graph adds another dimension: instead of treating memories as isolated pieces of text, relationships between entities and concepts can also be represented and explored.

Why Does Open Innovation Matter?

AI memory is fundamentally about personal context.

That makes control over the underlying technology important.

Using open-source and open-weight components gives Persista the ability to choose and replace individual parts of the system instead of coupling the entire memory layer to one closed AI provider.

The embedding model can be changed.

The retrieval system can be changed.

The model used for inference can be changed.

The infrastructure can evolve independently.

This also makes experimentation much easier. I can test different models, retrieval strategies, embedding approaches, and storage systems without rebuilding the entire application around a single proprietary API.

For a personal memory system, this flexibility matters because the data belongs to the application and its user, not to a model provider.

Open innovation makes it possible to build the memory layer as an independent piece of infrastructure rather than treating memory as a feature locked inside a closed AI product.

My Agent Session

[Add DevRelay agent session here if available.]

Prize Categories

I am entering:

Best Use of Gemma — if applicable to the submitted implementation
Best Use of MongoDB Atlas — if applicable to the submitted implementation

Thanks for checking out Persista!

hey this is first post

Yogesh Jamdade — Mon, 05 Oct 2026 03:23:28 +0000

hey this is first post