Work Connect
Healthcare shift marketplace · 2026
A product that fills a hospital's open nursing shifts, working inside the scheduling tool its staff already use. I co-lead the app the scheduler works in.
- The problem
- When a nurse calls in sick, covering the shift is slow and expensive.
- What I did
- I co-lead the app and built the shift-fill agent's spec, core and evals.
- The result
- An automated product that manages a hospital's nursing shifts.
A nurse calls in sick, and the shift has to be covered within hours
When a nurse calls in sick, someone has to cover that shift fast, and the usual options are slow and expensive: a round of phone calls, or an outside agency charging a premium. Work Connect spots the gap the moment it opens, gives the facility a window to fill it internally, and only then offers a way to reach outside.
Co-lead of the app the scheduler works in
I co-lead the app the scheduler works in, the screen where a hospital sees its open shifts, its incoming workers and its coverage reporting, and I wrote much of the spec that governs it. Here the written spec outranks the code by policy: when the two disagree, the code is what gets corrected. The app shares one database with a separate backend service, so keeping the two schemas aligned is part of my job. I was also the first here to build this way, with AI directed against a spec rather than prompted feature by feature.
Documents come first, then the AI writes the code.
In this project the documents come first. Before anything gets built there is a product specification, a requirements document per feature with its acceptance criteria, a technical blueprint, the work orders that split it into units, and the interface design. The AI turns those documents into code, and I review three things: the documents, the output and the tests. On one feature the AI ignored the plan and rebuilt the duplicate that plan existed to prevent, so I threw the work away and replanned it.
A team of agents runs the coverage loop.
Covering an open shift by hand is seven steps: notice the gap, apply the agreed rate, send the request to an outside supplier, review the candidates who apply, book one, write the booking back into the scheduling tool, and tell the manager. A team of six specialized agents takes those steps over, including phone calls that chase a credential missing before a shift starts and outreach messages drafted for a person to send. A hospital configures each one by writing a rule in plain language.
A hospital switches on each agent, rule by rule.
Automation inside a hospital cannot guess. Every agent ships paused and acts only on what a coordinator explicitly hands over. The coordinator writes that rule in plain language, and the panel shows what it understood so a person confirms it before it applies. Anything ambiguous means no external action: the shift goes back to the manual queue. Every run is logged, and the rule the shift-fill agent parses is measured against a table of real cases before a model is pinned to it.
What I shipped: the shift-fill agent, reporting and multi-site scope
These are the surfaces I shipped. The reporting the scheduler works from, now broken down and compared facility by facility. The move from one facility per customer to one tenant with many facilities across states, with the scope control, the settings and the rate card that go with it. Multi-customer sign-in where permissions are recalculated on every page request. And the rendering seam that lets one set of components serve another industry as a configuration. I also shipped the first version of the outreach agent that opens the conversation with a worker, and the team has carried it forward since.
I can put automation inside a workflow where a mistake has a real cost, by giving every step a limit, a human confirmation and a record of what it did.