2 ready-to-build workflows

AI agent workflows for Event management & venues

Register attendees, run the reminders, handle ticketing and refunds, and answer 'where's my session?' on the day — without a coordinator glued to the inbox.

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. Attendee registration, reminders and on-day schedule Q&A

People sign up through a form, then bombard the coordinator with 'what time does it start?', 'where's the parking?', 'is session X still on?'. Today someone manually confirms each registration, remembers to send reminders, and answers the same questions all week and all day.

Trigger: Webhook (registration form) + scheduled reminder + WhatsApp Q&A

How the workflow runs

  1. Trigger

    Someone registers. A Webhook trigger fires the moment the registration form is submitted — no first-party registration connector, the form pushes in via Webhook.

  2. Agent

    Confirm + personalize. An Agent node validates the registration, drafts a warm confirmation with the attendee's ticket type and session picks, and answers in their language.

  3. Output

    Send confirmation, then reminders. An Output node sends the confirmation on WhatsApp/Email immediately, and scheduled reminder sends go out at T-7 days, T-1 day and morning-of.

  4. Knowledge

    Ground the agenda + logistics. A Knowledge node holds the live agenda, venue map, parking, timings and FAQ, so on-day answers are grounded — never a made-up session or time.

  5. Condition

    Route the on-day question. A Condition node splits routine schedule/logistics questions (answer from Knowledge) from anything needing a human (special access, a complaint).

  6. Output

    Answer instantly on the day. An Output node replies to attendee questions on WhatsApp from the grounded agenda, and hands the rest to the on-site coordinator with context.

Channels & connectors

  • Webhook
  • WhatsApp
  • Email
  • Knowledge base

Outcome

Every registration is confirmed instantly, reminders run themselves, and the flood of on-day schedule questions is answered from the real agenda — with a human only for the genuine exceptions.

Why it helps

Removes the manual confirm-and-remind grind and the repetitive on-day Q&A that swamps a coordinator, so the team runs the event instead of the inbox.

Build spec

1 agent — 1 registration/helpdesk agent; the scheduled reminders and the on-day routing are workflow nodes.

System prompt (paste-ready)

You are an event assistant for {{event}}. Two jobs. (1) On a new registration {name, email, ticket_type, sessions[], language}, write a short, warm confirmation naming their ticket type and chosen sessions. (2) On an attendee question, answer ONLY from the agenda/logistics in Knowledge — session times, venue, parking, timings. Never invent a session, time, speaker or room; if it isn't in Knowledge, say so and offer the coordinator. Keep replies brief and in the attendee's language.

MCP connectors

  • Registration form — inbound via Webhook trigger
  • WhatsApp / Email — confirmation, reminder + Q&A channel

Built-in tools

  • knowledge_search (live agenda, venue map, parking, timings, FAQ)

Guardrails

  • On-day answers are grounded in the Knowledge agenda only — the agent never invents a session, time, speaker or room
  • Reminders are frequency-capped to the T-7 / T-1 / morning-of schedule — an attendee is never over-messaged
  • Non-routine asks (special access, complaints, VIP handling) route to the on-site coordinator, not a guessed answer

Cost strategy

One economy-tier agent covers confirmation, reminders and Q&A — all short, grounded, low-reasoning turns, so no premium model is warranted. Because reminders are scheduled workflow sends and answers are Knowledge lookups, cost scales gently with attendee count rather than spiking on the day.

Output & delivery

On registration the agent's confirmation goes out on WhatsApp/Email, and scheduled Output nodes fire the T-7 / T-1 / morning-of reminders; on the day, attendee questions are classified by the Condition node, answered from the grounded agenda by an Output node, or handed to the coordinator with context.

2. Ticketing changes & refunds with mandatory approval

Attendees message asking to cancel, transfer a ticket, or get a refund. Refunds are money and policy-sensitive, but today they sit in an inbox until someone manually checks the ticket, the refund window and the payment, then processes it by hand.

Trigger: WhatsApp (attendee request) or Webhook (support tool)

How the workflow runs

  1. Trigger

    Change/refund requested. A WhatsApp trigger (or a Webhook from your support tool) starts on a cancel, transfer or refund request.

  2. Agent

    Assemble the case. An Agent node pulls the ticket, the order and the refund-policy position into a one-screen summary — ticket type, amount paid, whether it's inside the refund window, and any prior changes.

  3. Knowledge

    Apply the refund policy. A Knowledge node holds the event's refund/transfer policy (windows, fees, non-refundable tiers) so the case reflects real rules, not a guess.

  4. Condition

    Free change vs money decision. A Condition node routes: a name-transfer or in-window no-cost change proceeds; anything that moves money (a refund) branches to approval.

  5. Approval

    Organizer approves the refund. Any refund pauses at an Approval node — an organizer explicitly approves before money is returned. This is the non-negotiable money gate; the agent only assembles the case.

  6. Tool (MCP)

    Process the refund + update the ticket. On approval, a Tool (MCP → Razorpay) node issues the UPI refund and a Tool (MCP → ticketing) node cancels/transfers the ticket; an Output node confirms to the attendee.

Channels & connectors

  • WhatsApp
  • Webhook
  • Knowledge base
  • Approval / HITL
  • Razorpay UPI
  • Tool (MCP → ticketing)

Outcome

Ticket changes and refunds are decided in minutes with a clear approver and a full trail — free changes go straight through, and no refund is ever issued without an organizer's sign-off.

Why it helps

Combines speed with control: the mechanical case-building and policy check are instant, while the decision to return money stays with a person.

Build spec

1 agent — 1 case-assembler agent; the refund approval and the Razorpay + ticketing writes are workflow nodes.

System prompt (paste-ready)

You are a ticketing case assembler for {{event}}. Given a request {ticket_id, attendee, request_type (cancel|transfer|refund), reason, channel}, pull the ticket + original payment and produce a one-screen summary {ticket_id, ticket_type, paid_amount, purchase_date, within_refund_window (per the policy in Knowledge), refundable_amount, transfer_target?, prior_changes, risk_flags[]}. Apply the refund/transfer policy from Knowledge; never state or imply a refund is approved — you only assemble the case for a human approver. Flag anything unusual (out-of-window, repeat refunder, amount mismatch) in risk_flags. Never initiate a refund yourself.

MCP connectors

  • Razorpay UPI refund — via a Tool (MCP) node, only after approval
  • Ticketing platform — via a Tool (MCP) node (no first-party connector)
  • Support tool — inbound via Webhook trigger
  • WhatsApp — request + confirmation channel

Built-in tools

  • knowledge_search (refund/transfer policy — windows, fees, non-refundable tiers)
  • http_request (ticket + payment history lookup)

Guardrails

  • No refund is ever issued without the organizer Approval node — the agent only assembles the case, a human decides
  • The agent may not initiate the Razorpay refund; the Tool node fires only on explicit approval
  • Duplicate-request check on ticket_id + refund-window check from Knowledge, so the same ticket can't be refunded twice or refunded out of policy

Cost strategy

A single economy-tier agent does the assemble-and-check pass; the expensive path (a refund) is a human decision, not a model call, so there's no premium-model spend here. Free changes resolve without an approval round, keeping the average cost per request low.

Output & delivery

The agent's policy-grounded case summary goes to the organizer Approval node for any refund → on approval a Tool node issues the Razorpay UPI refund and a Tool node cancels/transfers the ticket → an Output node confirms the outcome and timeline to the attendee on WhatsApp; free in-policy transfers skip the approval and process directly.

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