I am asking hospitals to let AI agents keep memory under a policy and an audit log. It would be odd if our own agents did not. So Inhold the company is tenant zero: the agents that help run it are Inhold principals, reading and writing memory through the same MCP server a customer would use.
This post says what that looks like in the repo, what is switched on and what is still a plan. The code is in plugins/inhold-employees, which merged on 31 October 2026.
The roster
There are 13 roles. Five work on the repo itself: a coder, a verifier that runs on every PR, a red-teamer, a CI babysitter and a docs curator. Those do not touch Inhold memory.
The other eight are in roster.json and run through a small runner on a Mac mini. Each one is a principal with one purpose:
| Employee | Inhold purpose | Inhold tools |
|---|---|---|
| Chief of staff | ops | search, get, skill list |
| Lead researcher | gtm | write, skill list |
| Outreach drafter | gtm | search, get, skill list |
| Call analyst | calls | search, get, write, skill list |
| Questionnaire answerer | security_answers | search, get, write, skill list |
| Community monitor | community | search, write, skill list |
| Investor helper | investor | search, get, skill list |
| Evidence builder | none, auditor export only | none |
The roster turns all of them on from 2 November. Some only run when something happens. The call analyst waits for a call to be booked. The community monitor starts hourly on 9 November, the day the repo goes public, and checks every 10 minutes around the Show HN post on 17 November.
Our own policy bundle
The policy is in examples/dogfood/inhold_company.json, the same format a hospital would write. A few rules from it:
Anything written under gtm, calls or community is PII by default, and any item about a named subject gets PII too. Real prospect and call notes exist only inside Inhold under those purposes. The repo and every file in the plugin use synthetic examples.
The chief of staff, under ops, can read from the other purposes but only items labelled internal or public. It writes the daily brief from counts and summaries. It never sees a prospect's details.
The questionnaire answerer reads only security_answers, internal and public. It drafts answers from the repo and cannot read anything about who asked.
Nobody can delete except a records admin role. That is how I want hospitals to set theirs up too: narrow purposes, PII and PHI by default where people are involved, and deletion held by one role.
Limits in code, prompts second
Each employee's limits are allowlists in roster.json, enforced by the runner whatever the prompt says. Built-in tools are limited to the employee's list, and a hook denies any call outside it. File reads and writes are allowed only under that employee's folders, checked after resolving ... Bash runs only commands that fully match an allowed pattern, with shell metacharacters refused, so nothing can be chained or redirected. Web fetches go only over https to allowed hosts, with no IP literals, ports or localhost. Each task has a turn cap and a dollar cap, mostly $0.50, and writes one spend row.
The first version of this guard was a denylist. An adversarial review found 15 ways around it. I rebuilt it as allowlists, and each of those 15 bypasses is now a test.
The Inhold side is separate. Each employee gets its own agent token and is bound to one purpose for the whole session. Even if fetched web text talks the model into wanting another purpose, the MCP tools have no purpose argument to change.
Nothing leaves without a founder
No employee holds a tool that sends, posts, pays, deploys or touches credentials. Anything meant for someone outside the company goes into an outbox as a file. The top of each file lists every factual claim with its source. A claim with no source gets removed. A founder reads it and sends it by hand.
To check that approvals are real, the chief of staff plants one flawed item a week with a hidden marker. If it ever reaches the sent folder, we are skimming, and the first fix is to cut volume.
Corrections work as they do for a customer. Only a founder can record one, through Inhold. A correction can turn into a skill, and a skill reaches an agent only after a founder approves it.
What is still a plan
Some of this is written down and not running yet, and I would rather list it than let the README imply otherwise.
The nightly improvement job is a skill file. It is meant to read the day's run logs, denials and rejected drafts, and open one pull request with proposed skill changes behind each employee's golden-task evals. Those eval sets do not exist in the repo yet, so the job has nothing to gate on.
The runner's docstring describes a second layer: each employee as its own macOS user that cannot read the Inhold database or other employees' folders, with network limited to the model API. That setup is not in the repo, and I have not verified it.
Inhold itself runs here as v0 on one machine with SQLite, the same as the public demo. Our anchors sit on the same host, so the audit chain on our own install shows the mechanism and gives no outside guarantee.
Why bother
Partly because it keeps me honest. If a deny row annoys our own chief of staff, a hospital's agents will hit it too. I want to find that before a customer does. And when a reviewer asks whether we use this ourselves, I can show them our bundle and our own deny rows.
I do not have numbers from our own install to share yet. When I do, they will come from the audit export, and I will say which day they are from.