Roster · open source, MIT alpha
Run your org on
AI staff you can read.
Each staff member is a GitHub repo: a charter, a memory, and a morning session that does a day's work and hands it to you as a pull request. You read it, and you merge it.
See it running a real productPip, two months in. Run by a Roster CTO and CMO.
Pip is a free poker web app. Roster agents have run the entire company with zero budget, and everything is built by them. One person oversees it.
The only running cost is the agents themselves.
Read the case studyRuns any coding agent with a command line.
Staff whose brain is a repo. That's the whole database.
An ops repo holds what the business is and how it runs. Each staff member gets a private repo that is their memory, their personality and their schedule. The framework writes templates out, then gets out of the way.
The Roster package itself is never a runtime dependency of your org. A run at 07:00 does not depend on npm.
They work at seven. You read it over coffee.
A session boots, works and hands off in 11 to 55 minutes. Everything it did is a commit, a comment or a pull request you can read.
A GitHub Actions cron calls the session in your ops repo. No server of ours in the path.
Org layer, charter and run kind, composed. Then memory/INDEX.md, one line per fact.
Edit, commit, open pull requests, file asks with a peer. As their own GitHub App, never as you.
Finished work waits for you to merge. Decisions wait in your Inbox. Memory is pruned.
@mention wakes them. Name a staff member in a comment on their tracker and it's a task, not a session: focused, on a shorter ceiling, answered on the thread.
One person, a lot to run. And GitHub already open.
Roster is for people who would rather read a pull request than a dashboard. You stay the one who decides; the staff do the work in between.
- A solo founder, or a small team
- Comfortable with GitHub: issues, pull requests, Actions
- One person who reads what the staff hand off, and merges it
- gh, signed in
- A GitHub organisation
- A credential for a coding agent
- About two hours, most of it writing the business and the charter
- Every repo, file and label listed before it exists
- Doctor says what is proven, and what is not yet
Access to a coding agent. Claude Code, Codex, Nanocoder or your own. On a subscription plan the cost is flat rather than spend per token. More on cost
Every change says what it checked. And what it didn't.
Work arrives as a pull request you can read before it merges. Three of Pip's, from its CTO, lightly shortened.
Every brain, readable. On your machine.
A local app over the checked-out repos. It reads from disk, so it needs no login and no API quota, and it works offline. When it writes, it writes as you.
A staff member's facts, notes and files in one place, because they were always the same thing.
Swipe to look around · tap to open full size
Or never open it. Run the whole org from GitHub.
The portal is a nicer way to read. Everything it shows lives in your repos, so the whole org is manageable straight from GitHub, on the web or your phone.
Read the diff, merge it or leave a review. That is the approval.
Anything that needs you is an issue with the question in it. Answer in a comment.
@ a staff member on any issue or pull request and they get to work on it straight away.
Autonomy you can read. And diff, and undo.
Every behaviour traces back to a file. When someone asks why it did that, the answer is a line in a repo you own.
Composable prompts
Org policy, the charter and the run kind, stacked. A role extends the org without forking it.
The plan, then the apply
Nothing changes anything without --apply. Every file, repo and label is listed before it exists.
Honest health
A workflow that has never run has proved nothing. So doctor says unproven, not fine.
Memory that stays small
One line per fact, and the argument in a note. Deleting is the maintenance, and roster lint holds each memory to a size budget.
Upgrades are merges
The machinery is vendored with a recorded merge base, so framework changes arrive as a three-way merge. An edit to a framework-owned file is reported before it turns into a lost fix.
New in the alpha
Every run in the portal: outcome, duration, cost where known, and a budget warning.
A run or any workflow failing in silence still reaches a person.
org/priorities.md, read by every staff member, named in every pull request.
roster lint names the facts that make a memory too long to boot from.
Turn it on and GitHub requires your review before anything merges.
One credential for the org, the App install pre-selected, example charters, and Run once now.
Bring the agent. Keep the org.
Roster composes a prompt and hands it over. A runner is three facts: how to install it, how to run it, and which secret holds its credential. Presets ship for Claude Code, Codex and Nanocoder.
One word for how much freedom it gets. Each agent hears it in its own flags.
org: your-org
agent:
id: codex
permissions: full
# or anything with a command line
agent:
id: my-agent
install: cargo install my-agent
run: my-agent --headless < "$AGENT_PROMPT_FILE"
token_env: MY_AGENT_TOKENBrowser or terminal. Same files.
Everything the portal does is also a command. Run them with npx @nanocollective/roster@latest, or install it once with npm install -g @nanocollective/roster.
Opinions, written down.
Roster runs daily against a live org. These are the lessons that cost something.
A generated charter produces a generic agent.
CHARTER.md is the one file Roster refuses to write. It decides everything else, so a person writes it.
A run at 07:00 must not depend on npm.
The machinery is vendored into your repos. The framework is never a runtime dependency of your org.
A bot signing itself with a job title is a tell.
Staff post as their own GitHub App on private trackers, and as one shared, anonymous identity in public.
Setup should tell you the truth.
A first hire is a couple of hours of real work, so setup keeps no step counter. It asks doctor what is true every time, and never-run reads unproven, not fine.
Nothing goes out under the company name unread.
Finished work waits as a pull request, and merging is yours. Replies go out as you, through your own gh.
Deleting is the maintenance.
Every line of memory is read at every boot, by every run. So the index stays one line per fact.
Your first hire is one command away.
You need gh, a GitHub organisation and a credential for a coding agent. The rest is a page in your browser.