Wellbeing Agent

Inspiration

The spark was a mismatch I kept noticing: every wellness tool I looked at treats "asking" as the finish line. A mood score gets collected, a dashboard gets built, and nothing downstream actually changes for the person who answered. Meanwhile the one moment an organization does get honest signal about someone struggling is the exit interview — after it's too late to do anything but say goodbye.

The tools that do exist for "wellbeing" share three structural gaps: they ask, but don't act; they trust self-report blindly, even though people say "I'm fine" far more often than they mean it; and they have no accountability loop — if HR's fix doesn't actually help, nothing tracks that failure or escalates it.

There was also a more personal thread. MarkOps work is built entirely around systems that watch for a signal, decide whether it crosses a threshold, and escalate through a chain of owners until someone actually acts — lead scoring, decay schedules, SLA breaches. Track 3's framing of agentic over generative was the prompt to ask: what if that exact discipline — sense, reason, escalate — got pointed at keeping a person well instead of closing a deal? That reframing is where the Wellbeing Agent came from.

What it does

1. Signal capture. Employees get a short daily Slack check-in (mood, free text, self-reported hours, workload) plus a weekly validated WHO-5 wellbeing survey — under 60 seconds, because survey fatigue kills data quality faster than low response rates do. Onboarding includes a plain-language notice — "check-in responses may be used to suggest wellbeing actions" — so participation is transparent from the first message.

2. Agentic reasoning, not keyword matching. Every check-in is passed to Claude with behavioral context (calendar load, after-hours activity, meeting density). Claude cross-checks what the employee said against what the data shows — if someone reports "I'm fine" but their calendar shows a 60-hour week, that mismatch is itself flagged. Claude returns a structured decision:

{
  "severity": "high",
  "signal_mismatch": true,
  "threshold_exceeded": true,
  "proposed_action": "calendar_block",
  "employee_facing_message": "Sounds like today was a lot. Want us to block some quiet time on your calendar tomorrow?"
}

3. Human-in-the-loop, always. The agent never auto-executes anything. It proposes an action through an interactive Slack message with Approve/Dismiss buttons — nothing happens without explicit consent. And voluntary means voluntary both ways: if an employee doesn't respond to a check-in, that silence is never treated as a red flag or auto-escalated. The case simply stays open.

4. A real accountability ladder, not a mood-tracker-and-forget:

| If this happens... | Then it escalates to... |

| HR doesn't act within an SLA | The same reviewer, for a second attempt | | Employee confirms the action didn't help | The internal or external wellness team (notified via email/Slack) | | Still unresolved | Leadership visibility + a confidential, manager-bypassing EAP offer |

Every stage is logged with structured notes, not a status toggle someone can quietly click to make a red flag disappear.

5. Leadership sees patterns, not people. The dashboard tracks aggregate metrics only — cases resolved by HR vs. by the wellness team, cases still pending, and critically, "HR action taken but not cleared by employee" — the number that answers whether the organization is actually helping or just closing tickets. I checked this design against the US state notice laws (Connecticut, Delaware, New York, Texas) and India's DPDP Act — the notice-first, consent-first, never-punish-silence structure holds up under both.

Component	Status
Reasoning pipeline (n8n + Claude API)	Live
Approval + nudge delivery (Slack)	Live
Daily check-in reminder	Live
HR dashboard, escalation ladder, manager views	Prototype (Figma , clickable)
Calendar / Microsoft Teams API integration	Roadmap — simulated for this demo

How we built it

I split the build deliberately: a live, working core loop in n8n, plus Figma for the parts of the system that don't need to run live to prove the idea.

The live loop is three n8n workflows:

• A Google Sheets Trigger reads each new check-in and calls the Claude API with a structured system prompt that returns a strict JSON decision.
• If threshold_exceeded is true, an HTTP Request node posts a real interactive Slack message — via Slack's Web API directly, not a generic connector — with Approve/Dismiss buttons.
• A second workflow, triggered by Slack's own interactivity webhook, catches the button click and delivers the actual nudge on approval.
• A third handles the daily check-in reminder.

The rest of the system — the HR dashboard, the calendar-block screen, the manager's view, and the full multi-tier escalation ladder — lives in Figma, wired and clickable, so the complete vision is walkable even where I chose not to spend build hours on live infrastructure.

Challenges we ran into

Getting structured, reliable JSON out of an LLM in production is harder than it sounds. Claude Sonnet 5's extended-thinking mode returns a "thinking" block ahead of the actual answer, and occasionally wraps the JSON in markdown fences despite explicit instructions not to. I stopped trusting the model to format perfectly every time and wrote defensive parsing that locates the text block and strips fences before parsing.

Slack's native "send message" node silently failed to render interactive buttons. No error, just plain text where Block Kit buttons should have been. I worked around it by calling Slack's chat.postMessage API directly via HTTP request nodes.

A quiet identity bug cost me real time: testing across multiple Slack sessions meant hardcoded channel IDs from different tests pointed nudges at the wrong conversation. I traced it back and standardized on a single resolvable Slack User ID.

n8n's "Published" state isn't the same as "Active." My reasoning workflow looked live but was actually only ever firing on manual test clicks — the difference between a demo that needs babysitting and one that runs unattended.

The hardest challenge wasn't technical at all. A compliance pass against US employee-monitoring notice laws surfaced a real design flaw: an early version auto-escalated employees who simply hadn't responded to a check-in within ten days — which quietly breaks the "truly voluntary" requirement most of this legal framework depends on. I redesigned it so silence is never treated as a red flag, and added an explicit onboarding notice.

Accomplishments that we're proud of

I shipped a genuinely working agentic loop, solo, not a mockup of one. Real reasoning, real Slack delivery, real approval flow — end to end, live, within the hackathon window.

The accountability ladder is actually built, not just diagrammed. Most wellness-tool pitches stop at "we show a dashboard." This one tracks whether the organization's response actually worked, and keeps escalating until it does.

I caught and fixed a real legal issue before submitting, not after. The compliance pass against US employee-notice laws surfaced a genuine design flaw in the escalation logic — and fixing it changed real system behavior, not just a policy document.

The whole system was designed privacy-first from day one: no wearables, no individual-level surveillance, aggregated-only leadership visibility, and an explicit refusal to treat silence as guilt.

And I'm proud this came from a non-traditional path into building. My background is MarketingOps at Freshworks — rule-driven lead scoring, decay schedules, multi-tier escalation logic. The threshold gates, the retry-then-escalate ladder, and the "don't act until you're confident" discipline in the Wellbeing Agent are the same engineering pattern I've used building trigger systems for sales and marketing teams — just pointed at a problem with real human stakes instead of a pipeline number. That combination is what let me ship something real in this window instead of a set of static screens describing one.

What we learned

• Agentic beats generative, even in a thin slice. A system that senses, reasons, and acts — with real approval in the loop — reads as fundamentally more credible than a well-designed chatbot.
• Asking permission is a feature, not a limitation. I expected the human-in-the-loop gate to feel like a constraint. It turned out to be the thing that makes the whole system trustworthy enough to actually deploy.
• No-code doesn't mean no debugging. Diagnosing API auth quirks, platform-specific state (Publish vs. Active), and LLM output formatting took the same careful troubleshooting real code would have.
• Compliance review should happen during design, not after. Catching the auto-escalation issue changed actual system behavior, not just the wording of a privacy policy.
• Where you spend real build time matters more than how much you build. Simulating calendar data and fully building the reasoning-and-approval loop produced a stronger demo than a shallower version of everything.

What's next for Wellbeing Agent

• Wire up live Calendar and Microsoft Teams Call Records API integration, replacing the simulated behavioral data — the reasoning pipeline already consumes that data in exactly the shape the real API would provide it.
• Build the structured action-logging UI for HR and the wellness team, so the "what did you actually do" remarks that already flow through the accountability ladder have a real interface, not just a data shape.
• Run a small pilot with a real team to calibrate severity thresholds against real response patterns instead of synthetic test data, before touching anything closer to production scale.

Built With

• claude
• claudeapi
• figma
• n8n