Five decisions that need making, then four phases. The decisions are first because three of them change what gets built, and building the wrong thing first is the expensive mistake here.
Owner: Jake
It sits in Andy's Remix Systems org. Invites are out to Jake (ysacks1) and Davor (orbiusrs) as admins, awaiting acceptance. D'Andrew follows once he creates an account. The open half of this decision is where it lives long term: staying in the Remix Systems org, or transferring to a Remy-owned org, which is one click whenever Jake wants it. Nothing else on this page can start until the invites are accepted.
Owner: Jake, with Davor · Andy's recommendation below
Jake's personal assistant already runs on his Hostinger server against his own vault, in its own container, and it works. Recommendation: the team version runs as a second container on the same server, with only the team vault mounted, its own messaging bot and its own credentials. Not a second job inside the existing one, and not a second server.
| Question | Answer | Why |
|---|---|---|
| Does Jake's existing bot get rebuilt? | No | It already runs as a container. Nothing about his setup changes, and it does not even get restarted to add the team one |
| One container or two? | Two | Two reasons that will hurt if ignored. Data boundary: Jake's personal vault and the Remy team vault are different privacy domains, and one process with both mounted is one mistake away from mixing them. Blast radius: a team bot that crashes should not take Jake's assistant down, and updating one should not mean touching the other |
| Is the current server big enough? | Almost certainly | The heavy thinking happens off the box at the model provider, so each bot is a light process. What actually gets added is a second copy of the vault on disk and a second sync watcher, both small |
| Upgrade the plan now? | No. Measure first | Stand the second one up, watch memory and disk for a week, upgrade only if the numbers say so. Buying a bigger plan before there is evidence is money spent on a guess. Andy will confirm the live numbers on the box before anyone commits |
| What could change the answer? | A third and fourth seat, or heavy transcript storage | Two bots is comfortable. Four bots plus a growing call archive is the point where the plan size is worth revisiting on evidence |
Exactly one process is allowed to sync a vault to GitHub, and it runs on the server rather than inside the bot. The bot writes files only. That one rule is what stops two processes fighting over the same files and losing work, and it is already how Jake's setup runs, so the team bot copies a pattern proven on this exact machine.
One housekeeping item that belongs to this decision: the server plan has a renewal date and must not lapse mid-engagement.
Owner: Andy to recommend, Jake to approve
The agent framework supports both, and the choice is real rather than cosmetic.
| A bot per person | One shared bot | |
|---|---|---|
| Isolation | Complete. Separate memory, history, and credentials | Separate too, routed by who is messaging |
| Setup | One messaging bot per person to create | One bot, a routing table to maintain |
| Failure | One person's breaks, others keep working | Everyone is down together |
| Feels like | Your own assistant | A shared team tool |
Recommendation: a bot per person. Each one gets its own identity file, its own memory, and its own history, so D'Andrew's assistant knows it is his and never surfaces someone else's notes. They all read the same vault, which is the point. Start with D'Andrew alone and add seats once his loop works.
Owner: Jake, and it is now a confirm rather than an invent
D'Andrew opens conversations and qualifies. He is not a clinical or pharmacy expert and said so directly. The question was always which answers are his and which become "let me bring in the person who owns that." The three recorded calls answer most of it, because they show who actually took what.
| Question | Goes to |
|---|---|
| The deal, the fee, anything commercial | Jake |
| "What would the numbers look like for us" | Cash Tidwell |
| "How would this work in our building", timeline, onsite visits | Rick Diaz |
| 340B contract pharmacy, TPAs, specialty pharmacy contracting | Ray Sawaged |
| Clinical questions, drug protocols, nursing | Alyson Contakos |
| Billing and authorisation mechanics | Christine Hall |
What is still genuinely open for Jake: whether D'Andrew may offer these names himself or should route everything through Jake, and whether the Space Coast reference stays Jake's to give. On the recorded calls Jake made that introduction personally and warned the reference it was coming, so the working assumption is Jake-only until he says otherwise.
An incoming board member asked it live: "So are we running the infusion center or are you guys running the infusion center? Because I'm a little confused who's asking that." That is the central confusion in the model and it will come up constantly. The health center owns the center, Remy staffs it, bills it and manages it, and that is exactly why the fee is a share of profit rather than a management fee. If D'Andrew cannot say that in one breath, he is not ready for a live call.
Owner: Jake and Andy, before any build
On 13 August the accounting side asked whether the agent could produce a daily chart-review report, including the names of patients identified, to compare against the infusion tracker. That is a genuinely useful workflow and it is squarely patient data.
This vault is built on a no-PHI boundary, deliberately, and that is what keeps the go-to-market work simple. A patient-level workflow is a different system with different hosting, a different agreement, and a different risk conversation. It should not be bolted onto the outbound vault because that is convenient.
Worth doing, and worth scoping separately. The counts-only version (how many reviews, how many eligible, by client) carries no patient data and could run against this stack today.