Integration Runbook Copilot

Integration Runbook Copilot uses Gemini 3 to read Outlook alert emails, prioritize integration incidents, call observability APIs, and generate clear, step‑by‑step runbooks for on‑call engineers.

Comment

Inspiration

Integration support teams are drowning in alert noise. Every day, on-call engineers receive dozens of monitoring emails from MuleSoft, SnapLogic, and other iPaaS platforms—each containing error codes, timestamps, and stack traces buried in HTML tables. Stitching these alerts into a coherent incident, prioritizing by impact, and deciding what to check first takes valuable time during outages.

We wanted to build an AI copilot that thinks like an L3 integration engineer: reading alerts, reasoning about root causes, calling observability APIs for live context, and generating a step-by-step runbook—all in seconds.

What it does

AlertLens (Integration Runbook Copilot) pulls monitoring alert emails from Outlook or Gmail, normalizes them into structured incident data, and sends them to Gemini 3 with a specialized prompt.

Gemini:

  • Groups related alerts into incidents by service, environment, and error pattern.
  • Prioritizes incidents (prod connectivity failures rank as Critical, QA data issues as High/Medium).
  • Calls MuleSoft observability APIs as tools (get_service_status, get_last_deployment, run_smoke_test) to gather live health data.
  • Generates a runbook with:
    • Incident summary
    • Root cause hypotheses with confidence scores
    • Step-by-step remediation checklist, annotated with tool results

Engineers can also use agentic search: type "show only prod SAP→Salesforce failures from today" and Gemini filters and re-analyzes on the fly.

How we built it

Architecture:

  • Frontend: React SPA built with Lovable/Antigravity, deployed at integration-copilot.lovable.app
  • Backend: MuleSoft flows exposed as REST API:
    • Alerts ingestion module: Calls Microsoft Graph API to fetch emails from an Outlook alerts folder, normalizes them into Alert[] using DataWeave.
    • Gemini orchestrator: Builds Gemini 3 Flash requests with structured output schema (JSON for incidents + runbook), handles tool-calling protocol (execute MuleSoft observability flows, pass results back to Gemini).
    • Observability APIs: Internal MuleSoft flows that mock service health, last deployment metadata, and synthetic checks.
  • AI: Gemini 3 Flash with:
    • Structured output for predictable JSON (incidents, hypotheses, steps).
    • Tool calling to query MuleSoft APIs mid-reasoning.

Key flow:

  1. User clicks "Analyze Latest Alerts" or types an agentic query.
  2. Backend fetches alert emails from Outlook.
  3. Gemini groups alerts, identifies top incident, requests tools.
  4. Backend calls MuleSoft observability flows, returns results to Gemini.
  5. Gemini finalizes runbook with live data inlined.
  6. UI renders incidents list + detailed runbook with tool badges.

Challenges we ran into

  • Tool-calling in Mule: No official Gemini connector for MuleSoft, so we hand-crafted the HTTP requests and function-calling protocol using DataWeave and flow orchestration.
  • Parsing messy alert emails: Real monitoring emails vary wildly in format (HTML tables, plain text, different error codes). We built robust DataWeave transformations with regex to extract service, environment, severity, and error summaries.
  • Balancing speed vs. accuracy: We tested Gemini 3 Flash vs. Pro; Flash gave us sub-5-second responses with good-enough hypotheses, which is critical for on-call UX.
  • Agentic search UX: Making natural-language queries feel intuitive required careful prompt engineering so Gemini could interpret vague queries like "recent prod errors" into precise filters.

Accomplishments that we're proud of

✅ Full Gemini 3 integration in MuleSoft—proving you can build agentic workflows in iPaaS platforms, not just Node/Python.
✅ Tool calling works end-to-end—Gemini decides when to call get_service_status, and the runbook reflects live MuleSoft health data.
✅ Structured output eliminates parsing—the UI is basically a JSON renderer; no fragile regex on Gemini responses.
✅ Agentic search feels natural—engineers can ask questions instead of fighting filter dropdowns.
✅ Built in 48 hours—from architecture diagram to working demo with real Outlook alerts.

What we learned

  • Gemini 3's tool calling is a game-changer for operations AI. Instead of just summarizing, it can actively investigate by calling APIs, then incorporate that context into its reasoning.
  • Structured output + JSON Schema = reliable UI integration. We spent zero time debugging "Gemini returned markdown instead of JSON."
  • MuleSoft as an AI orchestration layer works well. DataWeave is expressive enough to build Gemini request bodies, and flow-based tool routing is cleaner than spaghetti if/else in code.
  • Natural language UX lowers cognitive load. On-call engineers loved typing "prod failures today" instead of selecting 3 dropdowns and a date picker.

What's next for AlertLens

  • Multi-platform support: Extend observability tool calling to SnapLogic, Boomi, Digibee, and Workato.
  • Ticketing integration: Auto-create Jira/ServiceNow tickets with the runbook pre-filled.
  • Feedback loop: Let engineers mark hypotheses as correct/incorrect to fine-tune prompts over time.
  • Proactive alerts: Instead of waiting for emails, poll MuleSoft Runtime Manager APIs and trigger runbook generation when anomalies are detected.
  • MCP refactor: Expose Outlook and observability as MCP servers so other Gemini agents can reuse them.

Built with: Gemini 3 Flash, MuleSoft Anypoint Platform, Microsoft Graph API (Outlook), React, Lovable
Live demo: https://integration-copilot.lovable.app/
GitHub: [https://github.com/MuleCraft/gemini-alert-copilot]

Built With

Share this project:

Updates