Mansoor
Back to portfolio All projects
Project/WardenFlux — Agentic Workflow Automation
Project·2025·Full Stack Engineer

WardenFlux — Agentic Workflow Automation

A multi-agent incident-response orchestrator built on IBM watsonx Orchestrate. Wardenflux ingests a security incident report and routes it through a supervisor agent that coordinates four specialists — Security Response, IT Ops, Legal/Compliance, and Communications — then streams a coordinated reply back over a multi-turn conversation. Node/Express backend with IAM token caching, run polling, and an embedded-channel JWT flow; React 19 + Vite frontend.

WardenFlux — Agentic Workflow Automation

Overview

Wardenflux is a lightweight backend service and demo UI that turns IBM watsonx Orchestrate into a coordinated incident-response command center. A frontend submits an incident report; Wardenflux invokes an Orchestrate supervisor agent, polls the run to completion, and returns the agent's messages plus conversation identifiers so the user can keep the conversation going turn-by-turn.

The goal: take a raw alert ("Unauthorized DB access detected…") and have a team of AI agents triage, contain, advise on legal exposure, and draft communications — without a human manually fanning the work out to each function.

Architecture — supervisor + specialists

A single Incident Response Orchestrator (master controller) decomposes each incident and delegates to four specialist agents, then folds their output into one coordinated response:

  • Security Response — triage, containment, technical analysis
  • IT Ops — system recovery and remediation steps
  • Legal / Compliance — breach-notification and regulatory obligations
  • Communications — crisis-comms drafting (internal + external)

Each agent is grounded in a shared knowledge base (data-breach playbooks, incident-classification matrix, breach-notification requirements, crisis-comms templates, system-recovery procedures).

How it works

  1. POST /api/incident accepts an incident description (and an optional conversationId to continue a thread).
  2. The backend exchanges the IBM Cloud API key for an IAM token (cached until expiry) and starts a run on Orchestrate's /orchestrate/runs endpoint.
  3. It polls the run until completion, extracts the assistant's message content, and returns conversationId, threadId, runId, the reply text, and a hasFollowUp heuristic for multi-turn flows.
  4. The React frontend stores the conversation/thread IDs and renders the agent's reply, enabling follow-up questions.

Key features

  • POST /api/incident — start or continue an incident conversation
  • GET /api/health — service health + live conversation count
  • GET /api/scenarios — predefined incident templates for demos
  • IAM token caching to avoid re-exchanging the API key on every request
  • Run polling with reply extraction and follow-up detection
  • Embedded-channel JWT flow (RS256 over an RSA keypair) for embedding the agent in a web UI
  • Modular service layer: auth, orchestrate, and conversation services behind thin controllers/routes

Technical highlights

  • Correct Orchestrate payload shaping (response_type: "text" content items with UUIDs) to avoid 422s, and strict use of the Orchestrate domain vs. Watson Assistant domains to avoid 401/403s.
  • In-memory conversation store for the demo, with a documented path to Redis/DB, rate limiting, structured logging, retry/backoff, and secret-manager-backed keys for production.

Tech stack

Backend: Node.js 18+, Express, Axios, dotenv, CORS · IBM watsonx Orchestrate REST API · IBM Cloud IAM · JWT (RS256) Frontend: React 19, Vite 7, Tailwind CSS 3, lucide-react

Status & next steps

Built as a focused proof-of-concept (Nov 2025). Documented extensions: an /api/continue endpoint for follow-ups, SSE streaming of agent output (stream=true), and multi-channel entry points (Slack / Teams / email ingestion).

All projects