2 ready-to-build workflows

AI agent workflows for IT service desk

Deflect the repetitive tickets — access, resets, how-tos — and triage the rest.

Each recipe below is expressed only in VegaDūta's real workflow building blocks — Trigger, Agent, Knowledge, Condition, Approval, Output, Tool (MCP), Voice, Device, Loop, Code and Parallel — so it maps 1:1 to something you can assemble in the Workflow designer. Consequential actions always pass a human Approval step.

1. Self-serve access & password requests

Half the ticket queue is 'reset my password' and 'give me access to X' — each handled manually by an engineer who'd rather be fixing real problems.

Trigger: Slack / WhatsApp / Webhook (ticket created)

How the workflow runs

  1. Trigger

    Request comes in. A Slack, WhatsApp or Webhook trigger catches the request.

  2. Agent

    Understand + verify. An Agent node confirms identity and what's actually being asked.

  3. Knowledge

    Check policy. A Knowledge node grounds the answer in your access policy / runbooks.

  4. Approval

    Manager approves privileged access. An Approval node gates anything sensitive behind the right owner — routine resets can auto-proceed, privileged grants can't.

  5. Tool (MCP)

    Execute the change. A Tool (MCP) node performs the reset / grant in your IdP or ITSM.

  6. Output

    Close the loop. An Output node confirms to the requester and logs it.

Channels & connectors

  • Slack
  • WhatsApp
  • Webhook
  • Knowledge base
  • Approval / HITL
  • Tool (MCP → IdP/ITSM)

Outcome

Common requests resolve in seconds with the right approvals; engineers keep the queue for real incidents.

Why it helps

Removes the highest-volume, lowest-value tickets while keeping privileged actions approval-gated and audited.

Build spec

1 agent — 1 service-desk agent; the approval gate and the execute step are workflow nodes.

System prompt (paste-ready)

You are an IT service-desk agent. Classify the request as {password_reset | group_access | software_access | other}, confirm the requester's identity, and check it against the access policy in Knowledge. Output JSON {type, target, requires_manager_approval: boolean, policy_citation}. Set requires_manager_approval=true for any privileged/admin/production access. Never reveal secrets, tokens, or another user's data.

MCP connectors

  • Identity provider (Okta/Entra/Google) — via a Tool (MCP) node
  • ITSM (Jira/ServiceNow) — via a Tool (MCP) node

Built-in tools

  • knowledge_search (access policy + runbooks)

Guardrails

  • Least-privilege: privileged/prod access ALWAYS sets requires_manager_approval → Approval node before execution
  • Identity verification before any change; routine self-service resets can auto-proceed, grants cannot
  • Every action is logged with who-asked / who-approved / what-changed for audit

Output & delivery

Agent classifies + policy-checks → Condition auto-resolves routine resets, routes privileged grants to the manager Approval node → on approval a Tool node performs the change in the IdP/ITSM via MCP → Output confirms and logs it.

2. Incident triage & first-response

Alerts and tickets pile up unclassified; on-call wastes minutes just working out severity and owner.

Trigger: Webhook (alert / new incident)

How the workflow runs

  1. Trigger

    Alert fires. A Webhook trigger receives the alert/incident payload.

  2. Agent

    Classify + summarize. An Agent node sets likely severity, component and a plain-English summary.

  3. Knowledge

    Attach the runbook. A Knowledge node surfaces the matching runbook and recent similar incidents.

  4. Output

    Page the right channel. An Output node posts to the correct Slack/on-call channel with everything on-call needs.

Channels & connectors

  • Webhook
  • Knowledge base
  • Slack

Outcome

On-call opens a fully-triaged incident with the runbook attached, instead of a raw alert.

Why it helps

Compresses the manual 'what is this and who owns it' step that eats the first minutes of every incident.

Build spec

1 agent — 1 triage agent; the runbook attach is Knowledge and the page-out is an Output node.

System prompt (paste-ready)

You are an incident-triage agent. Given an alert/incident payload {source, message, metrics, service}, set a likely severity (SEV1–SEV4), the affected component and owning team, and write a plain-English summary of what's happening and its impact. Use Knowledge to attach the matching runbook and recent similar incidents. Base severity on the evidence in the payload — don't inflate or downplay. If it's ambiguous, say so and default to the more cautious severity so on-call can adjust.

MCP connectors

  • Monitoring/alerting source — inbound via Webhook trigger
  • Slack — on-call channel
  • Incident tool (PagerDuty/Opsgenie) — via a Tool (MCP) node

Built-in tools

  • knowledge_search (runbooks + incident history)

Guardrails

  • Severity is evidence-based; ambiguous cases default to the more cautious level for a human to adjust
  • The agent triages and pages — it does not take remediation actions on systems
  • Every triage posts the runbook + similar incidents so on-call starts informed

Output & delivery

The agent classifies severity/component/owner and attaches the runbook, then an Output node pages the correct Slack/on-call channel with the full triaged summary.

Related industries

Build one of these in minutes

The sandbox gives you a live agent workspace — no account, no card. Or head back to the full catalogue and compare patterns across every industry.

Try this in the sandbox — no signupBrowse all industries
See how VegaDūta compares to n8n, Dify and BotpressWhy VegaDūta's architectureEstimate your WhatsApp API costs