Run your loop
A Mulberry pack is a folder of plain text rules that any coding agent can follow. Getting it running takes about a minute.
1Unzip the pack
Download it from the build page and unzip it anywhere. Everything the loop needs is in that folder: plain text files, no executables, no secrets.
2Open your agent in the folder
Claude Code: open a terminal in the folder and run claude. CLAUDE.md and the pack's subagents load automatically. Codex: open it in the folder and AGENTS.md is read automatically. Any other runner: point it at loop.yaml and RUNBOOK.md.
3Paste the kickoff prompt
Open RUNBOOK.md, copy the kickoff prompt, and paste it into the agent. That starts iteration one. The pack never runs itself; you provide the heartbeat.
What runs while you sleep
Every working loop has the same five parts. Your pack ships all of them, already written.
A maker and a checker
The maker does the work. The checker is the verifier: an independent reviewer that must approve the work before the loop can claim success. Medium and high risk loops require one; low risk loops self-validate against the stop condition. Either way, the maker cannot edit the rules it is graded by.
A state file
STATE.md is the loop's memory. Each iteration reads what was already tried and records what happened, so the next iteration resumes instead of starting from zero.
A stop condition and a hard budget
The loop ends when the success criteria in STOP_CONDITION.md are met, or when any limit in BUDGET_POLICY.md is hit: iterations, minutes, dollars, or tokens. Budgets are hard stops, not suggestions.
Human gates
Risky actions listed in HUMAN_GATES.md pause the loop until a person says yes. Merges, deletes, and anything outward-facing wait for you.
An audit trail
Every action becomes one JSON line in audit-log.jsonl, matching AUDIT_SCHEMA.json. In the morning you read what it did, not guess.
Questions
Do I need to be a terminal user?
Honestly, yes. The packs are built for agent tools you run yourself, like Claude Code and Codex. If you do not already run one, the pack has nothing to attach to.
Is a loop the right tool for my task?
A loop pays off when the task repeats, when a machine can verify the result (tests, a type check, a build, a metric), when your budget can absorb retries, and when the agent has real tools to run the work and see what breaks. A one-time task with no automatic check is usually better served by one good prompt.
Can the agent make the check easier instead of doing the work?
No. The pack files are the contract, not the workspace. The only pack files the loop may write are STATE.md and audit-log.jsonl; the checker, stop condition, permissions, budget, and loop.yaml are read-only to it, and any change to them fails the run as a permission violation. Only a human changes the contract, by re-exporting from Mulberry.
How does the loop stop?
Three ways: the stop condition's success criteria are met, a stop-without-success condition is hit (like repeated failures), or a budget limit is reached. There is no fourth way where it just keeps going.
What do I do the morning after?
Paste the audit-log.jsonl your loop wrote into the run debrief. Mulberry shows what it did, how each iteration went, and what it cost. Paste the pack's loop.yaml alongside it to check the run against its permissions, checker, and budget. Everything is read in your browser; nothing is uploaded.
Can I change the rules later?
Yes. Paste loop.yaml back into the build page. Mulberry re-validates the contract and re-renders the whole pack, so the files always match the rules you reviewed.
How do I send feedback or report a bug?
Email [email protected]. During the beta every message is read by the founder, and the fastest way to make a report useful is to attach the loop.yaml and, if the loop ran, the audit-log.jsonl.