Homeward: AI agents that get patients home, and what I learned wiring them into Switch

Sarvagya Sharma — Sat, 07 Nov 2026 12:06:08 +0000

Built for the Flip the Switch hackathon (WeMakeDevs × DevTools Academy × Switch), Track 01. Team RE:SET. #HowISwitch

Here's a scenario I kept thinking about while building this: Margaret is 82. At 10:00 her doctor tells her she's well enough to go home. She actually leaves the ward at 19:10. Nine hours, and not one minute of that gap was medical. It was just... admin. Nobody's fault, exactly — just nobody's job to chase it either.

That gap is what I spent the hackathon on. This post is part build-log, part "here's what I wish I'd known," for anyone picking up Switch for the first time — especially on Windows, where I hit a few things the docs don't quite cover.

Demo video : https://youtu.be/MH0GedCY1M0

Replay it in your browser, no install needed: https://butterfingers7498.github.io/SWITCHAI/

Code (MIT): https://github.com/BUTTERFINGERS7498/SWITCHAI

The problem: it's coordination, not medicine

In England, roughly 13,000 people a day are medically fit to leave hospital but are still sitting in a bed — about 1 in 10 beds, nationwide (NHS England delayed-discharge data, as summarised in our research). And once you dig into why, it's rarely medical. It's a chain of small handoffs that nobody owns end-to-end: discharge medicines get requested late, transport shows up before the meds are actually ready, a letter sits waiting for a signature, and everyone ends up chasing everyone else over calls and group chats. Dashboards are great at showing you who's stuck. They don't actually work the queue for you.

What Homeward does about it

The core idea is pretty simple: give each patient their own Switch room, in Slack, with agents who actually chase the work instead of just displaying it.

@‌lead owns the plan for that patient and can tell you "what's left for bed 12?" at any point

@‌meds requests the discharge medicines and tracks where they're up to

@‌transport books the pickup for after the medicines and letter will actually be ready — not just "as soon as possible" — and rebooks automatically if the provider cancels on you

a small deterministic "ward clerk" (no LLM involved, just a plain agent connected through the Switch agent protocol) posts into the room whenever something happens on the hospital side

The one rule I didn't want to bend: a nurse approves every outward action, on Switch's own approval card. Doctors keep every clinical call, full stop. And since I obviously don't have access to a real hospital's EPR or pharmacy system, the hospital side of all this is simulated — more on that later, because it matters for how you should read the results.

Setting up Switch on Windows: what actually worked

I'll save you some trial and error here, because this is the part where I lost the most time to nothing-really-being-wrong.

Install Switch Console (I used v0.40.1) and start a local server from it. On Windows this runs natively with its own bundled Postgres — no Docker needed. My very first attempt to start it just said "switch-core stopped during startup," with no further explanation. I almost went down a rabbit hole debugging it. Turns out: just retry. It started fine the second time.

Connect Slack. Don't build this from scratch — grab Switch's manifest and create the Slack app from that instead. It already has Socket Mode baked in, which quietly saves you from needing a public URL. From there you'll need two tokens: an app-level one (scope connections:write) and a bot token from installing the app. Grab your workspace ID too, and drop all three into the Console under Messaging apps → Connect → Slack. One thing that bit me: my workspace is on Slack's free plan, and agent name autocomplete just throws an error unless you switch it off first.

Turn a channel into a room with /invite @‌Agent Switch. Pretty immediate — the room shows up in the Console right away, and /agents-status will answer you from inside the channel.

Create your agents (I used Claude Code) and add each one with !invite-agent @‌name.

What I'd tell the next person trying Switch

A few things weren't obvious to me at first, but once I understood them, they turned out to be good design, not bugs. Figured I'd save you the "wait, why isn't this working" moment:

Your agent's Directory is permanent. This one stung a little. I spun up two agents and left the Directory field on its default, which is just an empty folder — didn't think twice about it. Then spent a good while confused about why neither agent could see my scripts, my role files, none of it. Turns out that field is locked in at creation; there's no editing it afterward. So I deleted both agents and started over, this time actually pointing Directory at the repo. Learn from me: set it right before you hit create, because "fix it later" isn't an option here.

An agent can only hold one job across the whole server, not per room. I'd made the mistake of defining @‌lead as a job in two places — the ward-hub room and the patient room — assuming they'd be independent. They're not. The instant the agent took the role in one room, Switch quietly pulled it from the other, and when I tried to force it, I got a pretty blunt error back: "You already hold a role lease; release it before assuming another." Made sense once I thought about it, though. Jobs should live in the room where the work actually happens. The hub room just needs an alias pointing at it instead — !set-alias @‌discharge-lead @‌lead — and suddenly handoffs between rooms stopped breaking.

Local native mode doesn't serve the Gateway web UI. I spent a frustrating few minutes hunting for a webpage that simply doesn't exist when you're running locally. I needed to register a custom agent and generate a key for it, and kept expecting a form somewhere in the browser. There isn't one. What actually works is going straight at the Gateway API: log in with a POST to /gateway/auth/login, mint a key via /gateway/api-keys, register your agent with a POST to /agents (you'll need an integration_profile in the body), then send messages into rooms with POST /agents/{id}/message. Honestly? Once I got past the initial confusion, I preferred this — it's everything the Console UI does, just scriptable. Small trap along the way: calls like list_rooms hand you back {"result": [...]} rather than a plain array, which cost me a confused minute the first time.

Agents are deaf to anyone outside their addressing policy, by design. A freshly registered agent listens only to its own owner — not other people, not other agents, nobody. I had to explicitly widen mine to "Me and my agents" before @‌lead could hand work to @‌meds, or before messages from my ward-clerk agent could even reach @‌lead in the first place (I'd registered the clerk under my own account, which is what made that connection possible). Once it clicked why this exists, I actually came around on it — it's the thing stopping some other agent you don't control from walking in and giving yours orders.

And a few things that had nothing to do with Switch

In the interest of being fair to the platform — these next three bit me too, but none of them are Switch's fault:

Claude Code's auto mode will just run things without asking. Switch's approval card only shows up when the agent asks for permission first, and by default Claude Code's agents don't always bother asking. The fix was a project .claude/settings.json that allows read-only commands outright and forces an ask on anything that changes state. After I reset the agent (/reset @‌agent) so it picked up the new rules, every write started raising a proper Allow once / Decline card in Slack, with reads staying free. (Worth remembering: resetting is necessary after you change an agent's tools or permissions — it holds onto old context otherwise.)

Slack auto-corrects straight quotes into curly ones. Which, if you've ever tried to have a human type JSON into a chat box, you'll know is a disaster. Lesson learned fast: never ask a person to type structured data in Slack. Let the agent build the command itself.

Git Bash on Windows has a weird habit of rewriting paths that start with a slash. I typed /health and somewhere along the way it turned into C:/Program Files/Git/health — which, the first time I saw it, made zero sense to me. My agents all run inside Git Bash, so any CLI command expecting a URL-style path just silently broke. Ended up writing around it: accept paths without the leading slash on my side, and undo whatever Git Bash did to them before using them.

The moment the agents argued back with my own design

This was honestly my favorite part of the whole build. Early on, I had an agent record the doctor's "medically fit" decision straight from a chat message — seemed harmless, just capturing what someone typed. The lead agent refused to do it. Flat out said no: that would be a clinical decision, recorded under a doctor's name, that it had no way to actually verify. So I changed the design — fitness now has to be entered in the hospital system itself, never by an agent relaying a message.

Then it did it again. I asked it to mark a task done "as a nurse," and it pushed back because it wasn't a nurse, and it wanted to know who had actually told the family before it would write anything down. At that point I stopped arguing with it and just built both rules into the engine: agents only ever act as themselves ({"type": "agent", "role": "coordinator"}), and if a person told them something, that has to be attributed by name — "reported by nurse-amy: daughter told 10:05," that sort of thing. The engine now flatly rejects clinical completions from agents, self-approval, and booking a pickup before the medicines are actually ready. It's a nice feeling, having the thing you built hold you to a higher bar than you set for yourself.

Why there's a boring deterministic engine underneath

LLMs are great at holding a conversation and genuinely bad at doing the exact same thing twice. I didn't want the whole project riding on an agent phrasing something slightly differently one run and breaking the demo. So the actual decisions — not the chatting around them, the real state changes — don't live in the agents at all. They go through a plain Python readiness engine underneath: an explicit clock, a transition table, real dependencies between tasks, the pickup-timing rule. Nothing fancy. It's got 94 tests behind it, and CI runs on both Ubuntu and Windows so I'd actually know if something broke. The nice side effect: since the simulator replays the same day through that same code path every single time, the whole demo is reproducible without even opening Slack. For a hackathon video, that's genuinely saved me more than once.

The result, and where I want to be upfront about the limits

So, does it actually work? In the scripted scenario, yes — Margaret goes home at 12:40 instead of 19:10. That's 6.5 bed-hours handed back, 2 nurse approvals along the way, and zero clinical actions taken by any agent. I also tested what happens if the pharmacy just runs late — 30 minutes, 60 minutes — and the agents replan without me touching anything; she still leaves, just at 13:10 or 13:40 instead. It held up every single time I ran it.

But I want to be upfront about what this isn't. The hospital itself is simulated — I obviously don't have access to a real one. The 19:10 baseline is pulled from research, not from an actual trial. There's exactly one approving nurse in this demo. And the agents' wording genuinely does shift between runs; what stays consistent is the outcome, because that's coming from the engine, not the chat. It also doesn't invent capacity that doesn't exist — Doris, over in bed 7, just stays stuck waiting on a care-home bed all day, on purpose, because that's not the kind of delay this project was ever meant to fix.

One more thing I didn't plan going in: I ended up opening five draft pull requests back to Switch itself while building this (they're linked in the repo README).

If you want to try it yourself

git clone https://github.com/BUTTERFINGERS7498/SWITCHAI.git && cd SWITCHAI
python scripts/homeward.py setup && python scripts/homeward.py test
python scripts/homeward.py demo # board on http://127.0.0.1:8765/board
python scripts/homeward.py scenario margaret --auto

The full Switch setup — Slack app, agents, jobs, approvals, the clerk, all of it — is written up in switch/SETUP.md.

Dashboards show who's stuck. Homeward gets them home.

DEV Community: Sarvagya Sharma

Homeward: AI agents that get patients home, and what I learned wiring them into Switch