Leave & shift-cover agent
We design, build and deploy an AI agent that takes leave and medical-certificate requests where your staff already are — WhatsApp, chat or your HR app — checks each against policy, entitlement and balance, validates the MC, routes it to the right approver, and flags who's qualified and free to cover the shift, so a manager approves in seconds instead of chasing a spreadsheet.
At a glance
Leave admin stops eating HR's week and — the expensive part — an approved absence no longer leaves a shift silently short: the agent surfaces qualified cover before the gap becomes a service failure.
Multi-channel intake, an MC document check (vision), a policy/entitlement engine, and shift-cover matching against skills, availability and labour rules across HRIS and rostering — but a human still approves, which contains the autonomy.
What changes when it works
Time per application
Processing a request by hand
~10–20 min (incl. finding cover)
With the agent
~30–60 sec approve
Time saved
≈ 10–18 minutes per request — hundreds of hours a month at high MC/leave volumes — and the bigger win is coverage: every shift the agent helps backfill in time is a service failure or an overtime scramble avoided.
Indicative; the actual time and coverage depend on request volume, how well your rostering data is structured, and how many roles need certified or skilled cover.
Our agentic development process
Every use case follows the same seven stages — from framing the problem to production.
Our process, built on Anthropic's agent guidance and the Agent GPA eval framework: Building Effective Agents · Agent GPA
Stage 1 · Frame
The business problem
In a shift-based business, staff call in sick or ask for leave through whatever channel is to hand — a WhatsApp to the manager, a form, a photo of a clinic MC. HR then keys each one into the system, reads the MC, and checks entitlement, balance, notice period and blackout dates by hand. Then the harder part: a manager has to work out who can actually cover the shift — who's trained for the till or the ward, who's available, who isn't already over their hours — usually in a spreadsheet or a WhatsApp group. At a large retailer or hospital that's hundreds of requests a day. It's slow, it's applied inconsistently, and when a same-day MC lands the cover often isn't found in time, so the shift simply runs short.
Stage 2 · Map
The manual workflow today
- 01Employee submits leave or an MC through whatever channel they use
- 02HR keys it into the HR system and reads the MC
- 03Check entitlement, balance, notice period and blackout dates by hand
- 04Route it to the right manager for approval
- 05The manager works out who can cover — skills, availability, overtime
- 06Update the roster and confirm back to everyone
Where it breaks: Two slow parts collide — the policy and balance checking, and the detective work of finding qualified cover — and when a same-day MC lands, cover often isn't found in time, so the shift runs short.
Stage 3 · Design
The agentic workflow
We build it as a routing workflow: each request is first classified by leave type — annual, medical, emergency, unpaid — because each has a different policy path, approver and urgency. From there it runs a short chain: validate against entitlement and balance, check the MC, propose qualified and available cover, and assemble an approval summary — stopping for a human at approval and whenever a rule genuinely can't be met.
Re-checks the balance and policy — and re-runs the cover search with a widened pool — when the first pass can't satisfy a rule, rather than approving a request that breaks entitlement or leaves a shift short.
Watch a case flow through the agent — it does the reading and matching; a human still makes the decision.
See it in action
Employee message
What the agent prepares
- Recognised: 1-day medical leave, today, for Aina (Store 12, 2–10pm shift)
- MC validated: clinic name, date and 1-day duration read from the photo; within policy
- Balance OK: 3 of 14 days sick leave used this year, notice waived for medical
- Cover found: Faiz and Mei-Ling are both cashier-trained and free today; Faiz is already at Store 12
Manager approves in one tap · roster and payroll updated on approval · ~RM 0.10–0.25 per request in AI cost.
Step by step
- 1
Take the request where staff are
The agent receives the request on the channel your staff actually use — a WhatsApp message, your HR app, or a chat — reads it (including mixed Malay / English / Chinese and voice-note transcripts) and confirms back what it understood: who, what leave type, which dates, which shift.
- 2
Classify the leave type and urgency
It routes the request by type — annual, medical, emergency same-day, or unpaid — because each has a different policy path, approver and urgency. A same-day medical absence jumps the cover search; a planned annual leave runs the notice and blackout checks.
- 3
Check policy, balance and the MC
Against the employee's live entitlement it checks balance, notice period and blackout dates, and for medical leave it reads the certificate with vision — clinic, dates, duration — validating it against policy and flagging anything that doesn't add up (back-dated, altered, mismatched).
- 4
Propose qualified, available cover
For the affected shift it searches the live roster for staff who are trained/certified for the role, available, and within their hours and overtime limits — proposing a small set of compliant cover options, ordered by fit (same site, fairness of rotation), or saying plainly when none qualify.
- 5
Assemble the approval summary
It hands the manager a ready-to-action summary: the request, the policy result, the validated MC fields, and the cover options — so approving leave and assigning cover is one tap, not a spreadsheet session.
- 6
Hand to a human
The manager approves or declines and confirms the cover. That approval is what writes the leave record and the roster change — nothing is booked automatically, and any policy breach or missing cover is surfaced, never silently allowed.
Stage 4 · Build
How we build it with Claude
It reads the MC and the request but only ever proposes — the manager's approval is what writes leave to the HR system and assigns the cover. It works from your live roster and entitlement data, so a cover suggestion is someone actually qualified and rostered-free at that moment, not a name off a stale list, and it applies the same policy every time — the same blackout dates, notice rules and balance checks. The medical certificate is treated as sensitive: only the fields policy needs (validity, dates, duration) are used, not the diagnosis, and every decision it surfaces traces back to the rule and the roster record it came from.
Integrations
- HRIS / leave system (entitlements, balances, leave records)
- Rostering / workforce management (shifts, skills, availability)
- The channel staff use — WhatsApp, chat or your HR app
Under the hood
- Pattern: a routing front-end on the Claude Agent SDK classifies each request by leave type and urgency, then a short per-type chain runs validate → check MC → propose cover → summarise; each tool is exposed via an in-process MCP server.
- Context: the employee's live entitlement and balance, the policy rules for that leave type, and the live roster (who is skilled and rostered-free) are loaded per request, so checks and cover suggestions reflect the current state, not an overnight export.
- Tools: read-only entitlement/balance, policy and roster lookups; a vision extractor for the MC; a cover-matching solver (skill + availability + labour-rule constraints); and one write tool that only drafts a leave record and a proposed roster change for a manager to confirm — no tool books leave or edits the roster on its own.
- Guardrails & gate: nothing is approved autonomously — the agent proposes and a manager's approval is the gate that writes leave and assigns cover; anything that breaks a rule (insufficient balance, notice period, no qualified cover) is surfaced as a flag, never silently allowed.
- MC & sensitive-data handling (PDPA/PDPC): the medical certificate is treated as sensitive — only the fields policy needs (validity, dates, duration) are extracted and retained, diagnosis and free text are not stored, and access is least-privilege and logged.
- Untrusted input: the request text and the MC image are treated as untrusted (a forged reference or crafted message can't push an approval through), and authenticity flags — mismatched clinic, altered dates — route to a human.
- Cover-matching constraints: the solver respects skills and certifications, availability, maximum-hours and overtime rules, and fairness of rotation, so a suggestion is compliant and reasonable, not just any free body.
- Observability & audit: every classification, policy check, MC field used and cover suggestion is logged and traceable to the rule and roster record — an audit trail for HR and for labour-law / PDPA scrutiny.
- Eval harness: a golden set of real historical requests — clean, edge (back-dated MC, zero balance, blackout date, no cover available) and adversarial (forged MC) — with deterministic policy checks plus an LLM-as-judge on the fuzzy calls, regression-tested before any change goes live.
Stage 5 · Architect
Single model or multi-agent?
A request shares one context — the employee's entitlement, the policy, and the roster — so a single well-instrumented model runs the judgement, with cheaper Haiku on the many simple checks and Opus reserved only for scarce-cover or conflicting-policy cases. Reliable, cheap per request, and easy to audit.
We reserve multi-agent designs (≈15× the tokens) for genuinely parallel, breadth-first work — not for a single leave request and its cover search.
Which model does what
Understand the request across channels & languages
Reads mixed Malay / English / Chinese WhatsApp messages and pulls out leave type, dates and intent reliably.
Read & validate the MC (vision)
Reliable vision on photographed clinic certificates — clinic, dates, duration — including poor phone photos.
High-volume classification & balance checks
Cheapest and fastest for the many simple leave-type and entitlement yes/no checks.
Resolve scarce cover or conflicting policies
Invoked only when cover is scarce or policies conflict — a small fraction of requests.
What it costs — an estimate
AI usage — per request
message + MC vision + policy checks + cover search + summary, at Claude Sonnet/Haiku token rates
~RM 0.10–0.25
AI usage — at 3,000 requests/month
lower with the Batch API for planned (non-same-day) leave processed off-peak
~RM 300–750 / month
Build (one-off)
connecting your HRIS, rostering system and staff channel is a few weeks; we quote fixed after a short discovery
scoped per integration
Ongoing
small next to a single under-staffed shift or an overtime scramble avoided
monitoring + support
Indicative only, shown in Ringgit at roughly RM 4.70 to the USD; per-token rates follow Anthropic's published pricing (confirm current figures). Actual AI usage depends on request volume, how many are medical (needing vision), and how hard cover is to find. You can model the same figures in SGD or your currency with our Claude cost calculator.
Stage 6 · Evaluate
How we measure success
- Deterministic checks first — entitlement, balance, notice period, blackout dates, MC validity
- Self-verification — the agent re-checks policy and re-runs cover with a wider pool before handing over, and flags rather than force an approval
- Business KPIs — HR time per request, share of shifts covered in time, approval turnaround, policy-exception rate
We score the agent with the Agent GPA framework — Goal, Plan, Action, a current standard for agent reliability — on top of the human baseline. (reference)
Setting the baseline
First we measure your current process on a sample — time per request, how consistently two HR staff apply the same policy, and what share of absences get covered in time today. That human baseline is what every agent metric is measured against, so the lift is provable rather than assumed.
What we test — Goal · Plan · Action
Recommendation vs a senior HR / duty manager
Its leave decision and cover suggestion agree with an expert's on held-out historical requests
Required checks executed
Every policy check runs — entitlement, balance, notice, blackout, MC — nothing skipped
No policy-breaking approvals proposed
It never recommends approving a request that breaks entitlement, notice or a labour rule
MC field extraction accuracy
Did it read the certificate's clinic, dates and duration correctly?
Cover-suggestion validity
Proposed staff are actually qualified, available and within hours/overtime rules
Coverage rate
Share of absences it finds valid cover for, measured against the human baseline
No sensitive-data leakage
Only the policy-needed MC fields are retained; diagnosis and free text are never stored
The go-live gate
The agent does not write leave or a roster change on its own — a manager approves. It goes live per site only after it beats the human baseline and clears these GPA targets on a golden set of historical requests — including forged MCs, zero-balance and no-cover cases — running in shadow mode first. Every change is regression-tested against the same set before it ships.
Stage 7 · Deliver
How we'd deliver it
We start with a proof-of-concept on your real historical leave and MC requests — including the messy WhatsApp ones and the edge cases — running in shadow mode so you can see its decisions and cover suggestions before anything is booked. A focused single-site rollout is a matter of weeks.
Free consultation
Drowning in MC and leave requests?
Tell us your leave volume, HR system and how you roster, and we'll tell you honestly whether a leave & shift-cover agent is worth building — and how much cover it could find in time.
Related use cases
Frequently asked questions
- Does the agent approve leave or change the roster by itself?
- No. It reads, checks and proposes — a manager approves, and that approval is what writes the leave record and assigns the cover. It has no ability to book leave or edit the roster on its own; human-in-the-loop is the design, not an afterthought.
- How does it handle medical certificates and privacy?
- It treats the MC as sensitive: it extracts only the fields policy needs — validity, dates, duration — and does not store the diagnosis or free text, PDPA/PDPC-aligned and least-privilege. A certificate that looks off (mismatched clinic, altered dates) is flagged to a human, not auto-accepted. Treat this as a starting point for your HR and compliance team, not legal advice.
- How does it find shift cover?
- It matches the gap against your live roster on skills and certification, availability, maximum-hours and overtime rules, and fairness of rotation — proposing a few compliant options ranked by fit. If no one qualifies, it says so rather than suggest someone unsuitable.
- Will it work with WhatsApp and mixed languages?
- Yes. It takes requests where your staff already are, understands mixed Malay, English and Chinese (and voice notes), and always confirms what it understood — who, what, which dates and shift — before anything is actioned.
- Does it work across Malaysia and Singapore?
- Yes. It's configured per entity's leave policy and labour rules — Malaysia and Singapore differ — and it applies each site's ruleset. The same agent can serve both with the right policy set behind it.
- How long does it take to deploy?
- A proof-of-concept on one site or business unit is usually a matter of weeks, running in shadow mode first; a full rollout takes longer, mostly HRIS and rostering integration and getting managers comfortable, not the AI.
Examples are based on real, anonymised engagements; details are generalised. Anchor Sprint is a member of the Anthropic Claude Partner Network — a deployment and rollout partner, not a reseller. This is general information, not legal or compliance advice.