Your agents write the code. Muster keeps the queue, the gates and the receipts.
Muster runs a fleet of coding agents against a ticket tracker and a code forge. Every input is written to an append-only event log, and a pure function turns that log into orders. It is built by Rootline Digital.
Four ports keep the core free of any one vendor. Swap a tracker, a forge, a model provider or an agent runtime by writing one adapter.
Modular by design: four ports
Small interfaces
Each port is named for what the core needs, not for what the vendor offers. Adapters translate a call and its result and decide nothing.
Safe to retry
Every write takes an idempotency key. Errors are typed values, so a caller can tell a rate limit from a missing item from a refused request.
A fake for each
Each adapter ships with an in memory fake that satisfies the same interface, so tests run fast, offline and the same way every time.
Four adapters today
Linear for the tracker, GitHub for the forge, OpenRouter for the model provider and a process runtime for the agent. More plug in through the same contract: a new adapter is one package and a fake.
The problem
One agent on one task is easy to watch. A fleet of agents working a ticket tracker needs something that decides who works on what, checks what comes in, and keeps a record of why.
Muster is that part. It does not write the code. It decides, supervises and records.
The loop in one diagram
Six parts, one truth each
An event log
Every input is appended to the roll, an append-only log. Database triggers refuse an update or a delete.
A pure decision core
The bridge turns events and state into orders. It does no input or output, reads no clock and draws no random number.
Gates that fail closed
The sentry checks every tool call. A host off the egress list is refused, and an empty list allows none.
A review and a queue
A reviewer run approves the head commit, and only then does the merge queue test a draft on current main.
Roles in plain files
The files that direct an agent are embedded in the binary. An install and a project add layers and cannot weaken the safety rules.
Shadow mode first
Muster records every order it would give and sends nothing, so each decision can be audited before it acts.
Read how each part works, how the ports work, or what gates a change.
How it fits
Quick start
You need a Postgres database and the server program. The first run guide takes you from nothing to a running Muster in shadow mode. These are its three core commands, with placeholder paths:
muster check -secrets-dir /run/secrets --database
muster migrate -secrets-dir /run/secrets
muster serve -secrets-dir /run/secretsWhere Muster is going
Direction, from designs the owner has approved. None of this is shipped yet.
- Ports with a conformance suite. One contract for every port, a contract suite run against every adapter and fake, and a second forge adapter as the proof.
- Webhooks with API fallback. Each port that receives vendor events can run on webhooks, on polling, or on both, switching on its own when a webhook goes quiet.
- A secrets port, with files as the default store and Vault as the first remote store.
- Pluggable skiff backends, so runs can start on local hosts, Kubernetes and, through a driver protocol, clouds.
- A studio for roles and rulesets, compiled into reviewed pull requests, and health meters that notify, hold or brake a slice of work.
Status today
Working today: the event log, the pure decision core, webhook intake, shadow mode, the ops pages, the helm controls, layered roles, the skiff image assembler with the seat loop, and the four port adapters. The package layout, import rules, budgets and pipeline are enforced by ordinary Go tests.
The order executor is built and stays off until an owner turns it on, so a new install starts in shadow mode and records every order it would give.