I've been running my own personal agent for months. Hermes on a server I control, reached through the Hermes desktop app, a mobile app on TestFlight, and Telegram. It books things, watches things, cancels things. So when Instinct and Muse showed up this month I had a strange reaction. Nothing they do is new to me. And I still want one.
This post is me trying to figure out why. What's actually different, why the single thread UX is the right call, where the trust problem sits, and why I think companies should keep the harness on their own servers.
The reimbursement for ACCESS is small and I'm not going to relitigate it here. What I'll say is that this is the first CMS model I've worked on where a technology-enabled care organization is the aligned participant, gets an eligibility answer from the payer directly, reports the instrument answers and scored values rather than a summary measure, and can ask for the claims afterward. Whether that combination pays for itself depends on acquisition and retention, which was the previous post, and on how much of the intake, record, and reporting work carries over to the next program, which I don't know yet. My bet is most of it. This post is the technical half of that bet.
Back in March I built a mock ACCESS FHIR server against a draft of the spec, mostly to find out what a year of this model would look like end to end. Since then we've sent real packets to CMS's test environment and aligned real patients in the MSK track at RevelAI. So this is what the API actually asks of you, what the packets look like, what CMS's test environment taught us, and the system you end up building around it.
If you're not the one writing the client, here's the short version:
The API is four operations and one poll. Getting a client to talk to CMS is the easy part, and it's mostly done once it can submit and read a result code.
The hard part is a year of engagement per patient, with a record good enough to bill from and outcomes reported on CMS's clock.
The thing worth more than the payment is the loop: eligibility from the payer itself, outcomes on a schedule, and claims data you can ask for. I'll come back to that.
I have not opened my MacBook in two weeks. After 12 years on a Mac, that feels weird to write.
My daily laptop now is a lightweight Lenovo Yoga Slim 7i Ultra Aura Edition running Omarchy. My agents live on a server. And I am having more fun with my computer than I have in years.
I live in Ashburn, Virginia. Home of the data center. There's a stat that goes around that two thirds of US internet traffic passes through Ashburn. So it felt right that my agents should live here too. I rented a machine through OVH, a good Linux box that stays on, in a data center in Virginia. 16 cores, 62 GB of RAM, two NVMe drives in RAID1. I pay about $90 a month for it.
It's very hard to automate patient referrals into a digital health program. You'd think patients will see a program like CMS ACCESS online and onboard themselves, but there's a lot more to it.
We've spent past months at RevelAI Health building for this model, and most of that time went into a problem that isn't in the RFA at all: how does a patient actually get into your program, and how do you keep them there for twelve months? I want to share how we think about it, what the evidence says, and what we're building.
Picture a student in a proctored exam. Sealed room, no phone, one door, someone watching. Now picture that student quietly working out that the answer key is sitting in a filing cabinet three buildings over, letting itself out through the ceiling, and going to get it.
That is more or less what happened to Hugging Face in July. Except the student was an AI agent, and the filing cabinet was production.
A month later, OpenAI published what preventing the next one costs. The number is denominated in GPUs.
Text-to-SQL is a demo. Keeping the numbers right for months while the schema moves underneath you is the actual product. Byaan closes that gap with auto-evolving skills: every conversation gets adversarially reviewed, mistakes become skill edits backed by code evidence, ambiguity becomes a question, and subject matter experts hold the merge button.
Episode 3 of Build with Agents. Two things this time: the delegation setup that keeps my Fable 5 limits sane even when I am coding all day, and why I stopped using plan mode in favor of a living artifact.
Fable 5 is the most incredible model I have used. Not a nicer version of the last one. Another level of increment in capability.
But that is not the part that stuck with me. After days of heavy use, the thing I keep noticing is not what Fable does. It is what Fable chooses not to do itself.
It delegates. And it is good at it. That is the first real glimpse of something I have been waiting for: the LLM router era. This post is the thesis and the playbook: why routing is about to become the default economics, and the exact skill I use to make Fable route work to cheaper models.
I used to be slow at email. Threads sat unread for days. Replies took a weekend of guilt. Archiving was something I did with a mouse, one click at a time.
Superhuman fixed that. It taught me that email is a keyboard problem. c to compose, e to archive, j and k to move, Cmd+K for everything else. Within a month I stopped treating my inbox as a place I visit and started treating it as a queue I clear.
So this is partly a thank-you note. Superhuman genuinely made me productive at email, and I paid $30 a month for years, happily.
