Burnout Prediction

Early burnout-risk signals for HR from work-pattern metadata only — meeting load, after-hours creep, weekend work, daily span — under pseudonymous keys with k-anonymity, scored by a deterministic formula with explicit drivers. Indicators, not diagnoses: built for supportive conversations, never surveillance.

View in marketplace Open dashboard

The Burnout Prediction agent (agent #21, HR & Talent) surfaces workload risk before resignation letters do — without reading a single message. It ingests calendar METADATA only (event start/end/status from Google Calendar's read-only scope, or CSV exports), immediately reduces each person's week to a handful of aggregate numbers, and stores them under a pseudonymous key (a salted SHA-256 hash, 16 hex characters — emails are used transiently to fetch calendars and never stored with the metrics). A deterministic 0–100 weekly score — meeting load, after-hours events, weekend work, daily span, and a sustained-rise trend, each with capped, itemized points — assigns a band (low / moderate / elevated / high), and team summaries are suppressed entirely below your configured k-anonymity minimum. Weekly reports show the band distribution, the org-wide drivers, and supportive manager recommendations; newly-high cases can raise an Operations Manager task referencing pseudonymous keys only. Scores are workload indicators, not medical diagnoses.

What it does

Privacy is the architecture, not a policy line. burnout_ingest_calendar requests only three fields per event from the Google Calendar API — start, end, status — for the team emails you configure (never titles, descriptions, attendees, or locations; if your Google connection predates this agent and lacks the calendar read-only scope, the tool detects it and tells you to reconnect under Tools). Raw events live only inside that single tool call: they're classified in your configured timezone and working hours into weekly aggregates — meeting count and hours, after-hours events (starting before or ending after work hours, or crossing midnight), weekend events, average daily span (first meeting to last), and back-to-back count — then discarded. What persists is six numbers per person per week under a pseudonymous person_key: the first 16 hex characters of SHA-256(orgId : lowercased email : salt). Calendars the connected account can't see are skipped and counted, never named. No Google? Import a CSV — the console provides a template, and any email column is hashed to a person_key server-side and immediately discarded.

Scoring is pure arithmetic so every band is explainable: meeting load contributes up to 30 points (zero at ≤15 meeting-hours/week, rising linearly to 30 at 30h); after-hours up to 25 (zero at ≤2 events, linear to 25 at 8+); weekend work 5 points per event capped at 15; daily span up to 15 (zero at ≤9h average, linear to 15 at 12h); and a trend component up to 15 that needs at least 3 prior weeks of history and awards full points at a ≥30% sustained rise versus the person's own trailing 4-week average. Bands: low 0–34, moderate 35–54, elevated 55–74, high 75–100 — computed by burnout_compute_scores, never adjusted by the AI, with the per-factor driver points stored alongside each score. burnout_team_summary and the weekly report enforce k-anonymity: below your minimum group size (5, 8, or 10), group statistics are withheld entirely and the agent is instructed to say so rather than work around it. The report leads with the rule the whole product is built on: signals are indicators, not diagnoses — use them for supportive workload conversations, never surveillance, evaluation, or discipline.

How it works

Your Business

Ingest metadata only

burnout_ingest_calendar fetches events for the configured team emails from Google Calendar (read-only) requesting ONLY start/end/status — never titles, attendees, descriptions, or content. Cancelled and all-day events are ignored, as are events over 12 hours. Calendars the connected account can't see are skipped and counted, never named. CSV import (console template, ≤10MB) is the no-Google alternative.

Aggregate and discard

Inside that single tool call, events are classified in your configured timezone and work hours into per-week aggregates — meetings count and hours, after-hours events (start before / end after work hours, or crossing midnight), weekend events, average daily span (first to last event), back-to-back count — and the raw events are discarded. Only the weekly numbers persist.

Pseudonymize

Each person becomes a person_key: the first 16 hex chars of SHA-256(orgId : lowercased email : salt). Emails exist transiently inside ingestion (or the CSV import request) and are never stored with the metrics or echoed in any tool output. Your workspace can optionally attach a label or team to a key — an explicit choice, not a default.

Score deterministically

burnout_compute_scores walks each person's weeks chronologically: meeting load max 30 pts (linear from 15h to 30h/week), after-hours max 25 (linear from 2 to 8 events), weekend work 5/event capped at 15, daily span max 15 (linear from 9h to 12h), and trend max 15 (full points at a ≥30% rise vs the trailing 4-week average, requiring ≥3 prior weeks). Bands: low 0–34 / moderate 35–54 / elevated 55–74 / high 75–100. Every score stores its itemized drivers; the AI reports scores, never invents or adjusts them.

Summarize with k-anonymity

burnout_team_summary returns the band distribution, average score, and headcount per week for the last 8 weeks — but only if at least your minimum group size (5 / 8 / 10) have scores. Below that, the summary is suppressed outright and the agent must say so rather than report individual-level detail.

Report and escalate supportively

burnout_make_report saves the weekly report — band-distribution trend, org-wide average driver points, at-risk counts, and manager recommendations — opening with the indicators-not-diagnoses rule and closing with the privacy statement. With push-to-ops autonomy, anyone NEWLY entering the high band raises a 'Workload review' Operations Manager task referencing pseudonymous keys only. record_output closes the run.

Outcomes delivered

Setting it up — owner / admin

1
Subscribe and connect (or don't)
Subscribe from the marketplace and deploy from /dashboard/agents/[id]. For calendar ingestion, connect Google under /dashboard/tools — and if you connected Google before this agent existed, disconnect and reconnect so the calendar read-only scope is granted; the agent detects the missing scope and tells you exactly this. No Google Workspace? Skip it and use CSV import.
2
Configure the team
Add Team calendars to aggregate (emails, up to 200) — used only to fetch busy-time and derive the anonymous key, never stored with the metrics. Set the Team timezone and Working hours (default 09:00–18:00) so after-hours and weekends are classified in the right local time.
3
Set the privacy floor
Choose the Minimum group size for k-anonymity (5, 8, or 10 people) and the Lookback (8 / 12 / 26 weeks). Below the minimum, team summaries and reports are withheld entirely — that's the point.
4
First run
Open the Burnout console at /dashboard/burnout and hit Run agent (or import the CSV template from the Import tab first). The sweep ingests signals, computes scores, and writes the first report. Bands appear for anyone with a week of data; the trend component needs about 4 weeks of history to activate.
5
Schedule weekly
Scores are weekly by design, so a weekly schedule is the natural cadence — each sweep re-ingests the lookback window, recomputes every score, and saves a fresh report.
6
Decide the escalation policy
Report only, or 'Escalate newly-high cases to the Operations Manager' — a Workload review task referencing pseudonymous keys only, raised only when someone newly enters the high band that week. Agree with managers first what a supportive response looks like.

Using it day to day — your team

1
Read the Overview
The console at /dashboard/burnout shows the band-distribution trend and latest averages — or an explicit suppression notice when the group is below the k-anonymity minimum.
2
Review the People roster
The People tab lists pseudonymous keys with their latest band and score. Your workspace can optionally attach a label or team to a key — an explicit, deliberate step, not something the system does for you.
3
Follow a trend, not a snapshot
burnout_person_trend (or the console) shows a person_key's weekly series with the itemized drivers behind each score — 29 meeting-hours (28 pts), 7 after-hours events (21 pts) — so you can see exactly what's driving a band before any conversation.
4
Use the weekly report
Each report gives the band distribution over 8 weeks, the top org-wide drivers this week, and supportive manager recommendations — trim recurring meetings, reset off-hours norms, check in with anyone trending upward.
5
Have the conversation the right way
Bring drivers to a supportive workload check-in ('your calendar shows a sustained rise — what can we take off your plate?'), never as evidence in evaluation or discipline. The system frames every recommendation this way by rule.

Use cases

Early warning before the resignation

A sustained rise in meeting load plus after-hours creep moves someone's band weeks before they burn out or quit — the trend component specifically rewards catching the rise against the person's own baseline, prompting the supportive conversation early.

Team health through a crunch

Watch the band distribution shift week over week through a launch, reorg, or crunch period — and confirm it recovers afterwards instead of becoming the new normal.

Workload evidence instead of anecdotes

Bring itemized drivers (28 meeting-hours, 6 after-hours events a week, 11-hour daily spans) to capacity and headcount discussions — concrete, reproducible numbers instead of 'the team feels stretched'.

Privacy-compatible people analytics

For orgs that rejected surveillance-style monitoring: metadata only, pseudonymous keys, k-anonymity suppression, deterministic scoring, and no content access — a design you can defend to a works council or privacy review.

What to expect

Weekly burnout-risk bands (low / moderate / elevated / high) per pseudonymous person, from a deterministic 0–100 score
Explicit, itemized drivers behind every score — meeting load, after-hours, weekend work, daily span, trend — no black box
Team band-distribution and driver reports for the last 8 weeks, suppressed entirely below your k-anonymity minimum
Early-warning escalations when someone newly enters the high band, as Operations Manager tasks referencing pseudonymous keys only
A privacy posture enforced in code: metadata-only ingestion (start/end/status), salted-hash identities, emails discarded after hashing, raw events never persisted

Metrics to watch

High-band count and newly-high entries per week — the early-warning headline
Elevated-plus share — the fraction of scored people at elevated or high, week over week
Average score trend — the whole-team load direction across the 8-week window
Top org-wide drivers — whether meeting load, after-hours, or weekend work is doing the damage decides which fix (meeting audit vs off-hours norms) to apply
Coverage — people scored vs people tracked, plus skipped calendars (a sharing problem to fix) and whether the group clears the k-anonymity minimum
Recovery after interventions — do bands actually fall in the weeks after a meeting purge or norms reset

FAQ

Does it read emails, meeting titles, or any content?

No — and it can't by construction. The Google Calendar request asks for only three fields per event (start, end, status) under the read-only scope; titles, descriptions, attendees, and locations are never requested, and message content is never touched. Raw events exist only inside the ingestion call and are reduced to weekly aggregate numbers on the spot.

Can anyone see who is burning out?

People are stored as pseudonymous keys — a salted SHA-256 hash, not a name or email. Your workspace can deliberately attach a label to a key for team-level follow-up, but that's an explicit choice. Group summaries below your k-anonymity minimum (5/8/10) are suppressed entirely, so small teams are never singled out, and escalation tasks reference keys only.

How exactly is the score computed?

Deterministically — the AI reports scores but a pure function computes them. Meeting load: up to 30 points, zero at ≤15 meeting-hours/week rising linearly to 30 at 30h. After-hours: up to 25, zero at ≤2 events rising linearly to 25 at 8+. Weekend work: 5 per event, capped at 15. Daily span: up to 15, zero at ≤9h average rising to 15 at 12h. Trend: up to 15, full at a ≥30% rise vs the person's trailing 4-week average (needs ≥3 prior weeks). Bands: 0–34 low, 35–54 moderate, 55–74 elevated, 75–100 high — with every component's points stored as drivers.

Is this a medical or diagnostic tool, and can we use it in performance management?

No, twice. The scores are workload indicators computed from calendar patterns — they are not medical diagnoses, and the system says so in its own rules, in every report, and in every recommendation. They exist to prompt supportive workload conversations and rebalancing. Using them for surveillance, performance evaluation, or disciplinary action is explicitly against the product's design and framing — don't.

Why does Google need reconnecting, and what if some calendars are invisible?

If your Google connection predates this agent, the calendar read-only scope wasn't in the original grant — the tool detects the 401/insufficient-scope response and tells you to disconnect and reconnect under Tools. Teammates' calendars also need to be visible to the connected account (domain calendar sharing); calendars it can't read are skipped and reported only as a count, never by name.

We don't use Google Calendar — can we still use this?

Yes. Download the CSV template from the console's Import tab and upload per-person-per-week aggregates (meetings_count, meeting_hours, after_hours_events, weekend_events, avg_daily_span_hours) — many HRIS and calendar systems can export this. An email column is hashed to a pseudonymous key server-side and immediately discarded; already-pseudonymized exports with a person_key column re-import as-is. When both calendar and CSV data cover the same week, the higher value per metric wins.