3 ready-to-build workflows

AI agent workflows for Staffing & recruitment agencies

Source and screen at scale, chase timesheets, and keep the bench warm — without a recruiter tied to a spreadsheet.

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. Bulk sourcing & screening against a client req

A client sends a role and a stack of applicants floods in from job boards. A recruiter opens each CV, reads it against the req, and copies notes into a tracker — hours per role, and the applicant screened at 6pm gets less attention than the one at 9am.

Trigger: Webhook (new applicants) or Email (job-board inbox)

How the workflow runs

  1. Trigger

    Applicants land. A Webhook (from your ATS/job board) or an Email trigger on the applications inbox starts the flow — no first-party ATS connector, the board pushes in via Webhook.

  2. Knowledge

    Load the client req. A Knowledge node holds the client's job spec + must-haves; every applicant is compared against it, not a keyword guess.

  3. Loop

    Screen every applicant the same way. A Loop node iterates the full applicant batch so the hundredth CV is read as carefully as the first.

  4. Agent

    Summarize + score fit. An Agent node writes a 3-line summary, a fit score against the req, and the gaps — consistently, for every candidate.

  5. Condition

    Auto-route by fit. A Condition node splits strong / maybe / reject so recruiters only read the shortlist.

  6. Approval

    Recruiter confirms the submittals. An Approval node keeps the human as the decision-maker — the agent ranks, a recruiter decides who goes to the client. This is the placement gate.

  7. Tool (MCP)

    Write back to the ATS/VMS. A Tool (MCP) node updates each candidate's stage and notes in your ATS or the client's VMS.

Channels & connectors

  • Webhook
  • Email
  • Loop
  • Knowledge base
  • Approval / HITL
  • Tool (MCP → ATS/VMS)

Outcome

Every applicant in the batch is read and scored against the client req within minutes; recruiters spend their time only on the shortlist and the submittal decision.

Why it helps

Removes the fatigue bias of screening a big batch by hand and the copy-paste into trackers, while the who-to-submit call stays with a recruiter.

Build spec

1 agent1 screening agent per applicant; the per-applicant Loop, the fit routing and the ATS/VMS write-back are workflow nodes.

System prompt (paste-ready)

You are a staffing screener working a client requisition. Given a résumé and the client's must-haves (from Knowledge), output strict JSON {summary (max 3 lines), fit_score 0-100, matched[], gaps[], recommendation: STRONG|MAYBE|REJECT}. Score only on job-relevant evidence in the résumé. Do NOT use name, gender, age, religion, caste, marital status, or photo as signals — ignore them entirely. If a must-have can't be confirmed, put it in gaps rather than assuming it. You rank candidates; you never decide who is submitted to the client.

MCP connectors

  • ATS / client VMS — via a Tool (MCP) node (no first-party connector)
  • Job board — applicants pushed inbound via Webhook
  • Applications inbox — via Email trigger

Built-in tools

  • knowledge_search (client req + must-haves)
  • file parsing (résumé PDF/DOCX)

Guardrails

  • Bias guardrail: protected attributes are explicitly excluded from scoring in the prompt
  • The agent ranks; it never rejects or submits — the recruiter makes every submittal decision at the Approval node
  • Same Knowledge-grounded rubric for every applicant in the batch — the hundredth CV is scored like the first, not on fatigue

Output & delivery

A Loop node runs the agent per applicant → per-candidate JSON → the Condition node buckets STRONG/MAYBE/REJECT → the recruiter confirms the submittals at the Approval node → a Tool node writes each candidate's stage + notes back to the ATS/VMS via MCP.

2. Bench availability check-ins & redeployment

Contractors roll off assignments and the bench sits idle because nobody has time to call round and check who's free, when, and for what — so the agency re-sources roles a benched consultant could have filled.

Trigger: Webhook (scheduled, bench/availability run)

How the workflow runs

  1. Trigger

    Availability run. A scheduled Webhook trigger evaluates the bench and contractors nearing roll-off each week (fed from your ATS/VMS via Webhook).

  2. Loop

    Per benched consultant. A Loop node iterates the list so each consultant gets a personal check-in.

  3. Agent

    Draft a tailored check-in. An Agent node references the consultant's skills and last assignment, asks about availability, notice and rate expectations.

  4. Output

    Reach out on their channel. An Output node sends the check-in on WhatsApp/SMS/Email and captures the reply.

  5. Knowledge

    Match to open reqs. A Knowledge node searches current open client requirements for genuine skill matches to redeploy them into.

  6. Approval

    Recruiter approves the redeployment. An Approval node routes each proposed match to a recruiter — the agent surfaces the fit, a person decides the placement.

Channels & connectors

  • Webhook
  • Loop
  • WhatsApp
  • SMS
  • Email
  • Knowledge base
  • Approval / HITL

Outcome

The bench is kept warm with real availability data, and free consultants are matched to open reqs before the agency re-sources from scratch.

Why it helps

Consistent, timely check-ins are what surface who's actually available — the manual process skips exactly the consultants who quietly roll off, while the placement decision stays with a recruiter.

Build spec

1 agent1 outreach agent per consultant; the per-consultant Loop, the req-matching Knowledge search and the recruiter Approval are workflow nodes.

System prompt (paste-ready)

You are a bench-management assistant for a staffing agency. For each benched or rolling-off consultant {name, skills[], last_assignment, roll_off_date}, write a personal check-in referencing their skills and last role, and ask about current availability, notice period and rate expectations. Capture their reply as {available_from, notice, rate_expectation, interested: boolean, notes}. Be respectful of their time, honour opt-outs, and don't imply a specific role is confirmed — matching and placement are decided by a recruiter.

MCP connectors

  • ATS / VMS — bench and roll-off list fed inbound via Webhook (no first-party connector)
  • WhatsApp + SMS + Email — via the messaging channels

Built-in tools

  • knowledge_search (current open client requirements)

Guardrails

  • The agent surfaces skill matches to open reqs; the recruiter decides every redeployment at the Approval node — no placement is the agent's call
  • Never implies a role is confirmed or negotiates a rate — availability, notice and rate are captured, not committed
  • Honours opt-outs and check-in frequency so a consultant isn't over-messaged between assignments

Output & delivery

A Loop node runs the agent per benched consultant → an Output node sends the check-in and captures the reply → a Knowledge search matches them to open client reqs → each proposed match goes to the recruiter at the Approval node for the placement decision.

3. Timesheet collection & chasing for placed contractors

Every week placed contractors must submit timesheets before payroll and client invoicing can run; today a coordinator chases missing ones by hand over email, and late sheets hold up both pay and billing.

Trigger: Webhook (scheduled, weekly timesheet run)

How the workflow runs

  1. Trigger

    Timesheet run. A scheduled Webhook trigger fires at the weekly cut-off for all active placements (contractor list fed from your ATS/VMS via Webhook).

  2. Loop

    Per active contractor. A Loop node iterates active placements so each contractor gets their own request.

  3. Output

    Request the timesheet. An Output node messages each contractor on WhatsApp/Email with a one-tap submit link and the hours to confirm.

  4. Condition

    Chase only the missing ones. A Condition node tracks who has submitted and escalates reminders only to the ones still outstanding as the deadline nears.

  5. Approval

    Client manager approves the hours. An Approval node routes submitted hours to the client's approving manager before anything flows to pay or invoice.

  6. Tool (MCP)

    Push to payroll / invoicing. A Tool (MCP) node writes approved hours into your payroll and invoicing system — no first-party payroll connector, MCP calls yours.

Channels & connectors

  • Webhook
  • Loop
  • WhatsApp
  • Email
  • Approval / HITL
  • Tool (MCP → payroll)

Outcome

Timesheets are requested, chased and approved on schedule, with humans touching only the approval — pay and client invoices stop waiting on missing sheets.

Why it helps

Removes the manual weekly chase that delays payroll and billing, while the hours-approval step stays with the client manager who owns it.

Build spec

1 agent1 messaging agent; the per-contractor Loop, the missing-only chase Condition, the manager Approval and the payroll write are workflow nodes.

System prompt (paste-ready)

You are a timesheet-collection assistant for placed contractors. For each active placement, message the contractor a clear request for this week's hours with a one-tap submit link, stating the period and any expected hours to confirm. If they reply with hours, capture {contractor, period, hours, notes} exactly as submitted — never edit, round, or estimate hours on their behalf. Keep reminders polite and send them only to contractors who haven't yet submitted as the deadline nears.

MCP connectors

  • Payroll / invoicing system — via a Tool (MCP) node (no first-party connector)
  • ATS / VMS — active-placement list fed inbound via Webhook
  • WhatsApp + Email — via the messaging channels

Built-in tools

  • http_request (check submission status)

Guardrails

  • Submitted hours are captured verbatim — the agent never edits, rounds, or invents hours
  • Hours go to the client's approving manager at the Approval node before anything flows to payroll or invoicing
  • Only outstanding contractors are chased; already-submitted ones aren't re-messaged

Output & delivery

A Loop node runs per active contractor → an Output node requests the timesheet with a submit link → the Condition node chases only those still missing → the client manager approves the hours at the Approval node → a Tool node writes approved hours to payroll/invoicing via MCP.

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.

See how VegaDūta compares to n8n, Dify and BotpressWhy VegaDūta's architectureEstimate your WhatsApp API costs