Soapbox's Sheila: an open-source accounting agent built from small scripts and an AGENTS.md, running in OpenCode with Claude

In two sentences

Soapbox, a small, donation-funded open-source software company, built an agent called Sheila that now handles its contractor invoices, payments in dollars and Bitcoin, bookkeeping and monthly bank reconciliation, using the OpenCode coding agent with Claude Opus 4.6, a set of more than 50 single-purpose scripts and one long AGENTS.md file of instructions. It is a first-hand account without figures, but the whole thing is published as open source, so you can read exactly how the controls work, and where they are only instructions.

Who does it and why it is interesting

Alex Gleason announced Sheila on the Soapbox blog on 6 March 2026 and in a Show HN post the same day. Soapbox builds open-source tools for decentralised social media, fundraising and app building, and its About page says it is “entirely supported by grants and donations”. Its expenses run through OpenCollective, so paying a contractor is a two-sided job: pay the person, then claim the money back from the collective with the right invoice.

The case is interesting for three reasons:

• It is a small company’s real back office, not a vendor demo. Contractor invoices, ACH and wire transfers, Bitcoin payouts, 1099 reports and month-end reconciliation are ordinary finance work for many small firms.
• The design is unusual and transferable. Instead of a workflow engine or an “agent platform”, it is a coding agent reading a plain-English procedure manual and calling small scripts.
• Everything is public. The repository (AGPL-3.0) contains the scripts, the example configuration and the full AGENTS.md, and its history shows how the procedure changed after launch.

Two caveats from the start: Soapbox gives no numbers, and it makes AI app-building tools of its own, so it has some interest in the “build your own agent” message, although it does not sell Sheila or OpenCode.

What Sheila does

According to the post and the README, Sheila covers the full contractor-payment lifecycle:

1. Reads invoices from email over IMAP, with the whole thread when it is about to act.
2. Records them first: a numbered folder in Google Drive with the invoice PDF, and a row in that month’s tab of a Google Sheets payment tracker with status PENDING, plus an entry in a separate log tab.
3. Acknowledges receipt to the sender (a mandatory step in the instructions).
4. Pays by ACH or wire through the Mercury bank API, or in Bitcoin through Kraken, a Lightning wallet or a Lightning-to-on-chain swap.
5. Claims reimbursement by generating Soapbox’s own invoice PDF and submitting the expense to OpenCollective, then follows it until it is approved and paid.
6. Closes the row as COMPLETE and emails the contractor with details they can verify.

On top of that it keeps a separate finance workbook with income, expenses, a P&L and a 1099 summary, and, since late March 2026, a monthly reconciliation of Mercury transactions against the spreadsheet. Gleason says he opens a terminal and asks “what’s the status?” and Sheila reports what is done, pending and blocked.

Tools and architecture

The README draws the architecture as one agent calling a list of npm run commands. In practice there are three layers:

• The agent: OpenCode, an open-source (MIT) coding agent that runs in the terminal and automatically reads an AGENTS.md file in the project folder. Soapbox says Sheila was “developed and tested with Claude Opus 4.6” and warns that other models “may skip steps, fabricate transaction IDs, or send payments to the wrong recipients”.
• The procedure: AGENTS.md, about 600 lines at launch and roughly 960 when we read it. It defines the spreadsheet columns and status values, the three payment paths, how to write emails to contractors, the Bitcoin address policy, the status check and the reconciliation steps.
• The tools: 56 TypeScript scripts, each doing one thing (check a balance, list bank transactions, send a payment, append a row, upload a file, submit an expense). All support --json and --dry-run. Configuration and credentials live in a sheila.yaml file that is not committed. There is no database: “all state lives in Google Sheets, email, and Google Drive”.

Gleason’s main lesson is about this split. His first version tried to code complex multi-step flows and was “fragile and inflexible”; the second used granular scripts, each tested on its own, plus plain-English workflows the agent chains together. He argues a human-in-the-loop coding agent beats autonomous agent platforms because reliability comes from “hundreds of cycles” of testing, finding an edge case and fixing a script or an instruction.

The controls written into the procedure

Reading AGENTS.md and the code, these are the safeguards:

• Sender allowlist. Email output flags any sender not listed as a contractor or admin with a “PHISHING RISK” warning, and the instructions call this a “hard stop” for anything payment-related; display names never count as identity.
• Record before paying, so an interrupted session leaves a trace.
• Saved recipients only. Bank payments go to Mercury recipient IDs that already exist; Bitcoin contractors must use one static address already saved in Kraken, and a new address needs a human.
• Limits. The configuration has a global maximum per invoice and optional per-contractor invoice and monthly limits.
• Bank-side approval for international wires, which go through a Mercury endpoint that requires approval in the Mercury dashboard.
• Human confirmation in reconciliation. The agent presents unexplained bank charges grouped by type and must not continue until the user confirms which ones to claim.
• A person in the terminal. “She can draft an email or prepare a payment, but I see what she’s doing before it goes out.”

One nuance from our reading of the code: the limits and allowlist are surfaced as warnings in the email scripts and enforced by the instructions; we did not find a check in the Mercury payment script itself that refuses an amount above the limit. That is acceptable with a person watching, but it is the first thing to harden if you want the agent to run unattended.

How to replicate it, step by step

1. Pick one flow and draw it. Supplier invoice to payment to claim or posting. Write down the statuses (received, recorded, paid, claimed, closed) and the columns you need.
2. Check which systems have usable APIs. Sheila only works because Mercury, Kraken, Google and OpenCollective have APIs; the README notes most banks offer nothing comparable. If your bank has none, stop at a payment file for a human to upload.
3. Write one script per action, each with a dry-run and JSON output, and test each one on its own with tiny amounts or a sandbox.
4. Write the procedure in AGENTS.md: the order of steps, the hard stops, the wording of emails, what to log, and when to stop and ask.
5. Put limits in code, not only in prose. Make the payment script refuse unknown recipients and over-limit amounts, whatever the agent says.
6. Set agent permissions. OpenCode’s permission settings can allow, ask or deny each shell command pattern; for example, allow read-only scripts and set every payment command to ask (our suggestion; Sheila’s repository does not ship such a file).
7. Run it supervised for weeks, fix scripts and instructions after each surprise, and only then consider less supervision.
8. Add a monthly reconciliation of bank transactions against your tracker, with the agent proposing and a person confirming.

A worked example (illustrative)

Suppose a regular contractor emails an invoice for $4,800 on 3 November. You type “process invoices”. The agent reads the thread, sees the sender is on the allowlist and the amount is under the $10,000 per-invoice limit, creates the Drive folder, uploads the PDF, adds a PENDING row and logs it, and replies to confirm receipt. It then runs the Mercury payment script with --dry-run, shows you the saved recipient, amount and balance, and, once you approve the real run, sends the ACH, sets the row to PAID, emails the contractor and prepares the OpenCollective claim with Soapbox’s own invoice. If the same email had come from an unknown address, or with new bank or Bitcoin details, it would stop and tell you. These amounts and the date are ours, not Soapbox’s.

Results stated by the source

Soapbox states only qualitative results: Sheila “replaced our entire accounting flow” and is “a drastic time-saver” even though it is supervised. There are no figures for invoices per month, hours saved, cost of model usage or errors avoided. What can be checked is activity: the public repository has commits from March to August 2026, including a monthly reconciliation workflow, fixes for missed emails and false matches, and a correction for international wires, which suggests continued real use. The evidence level is therefore experience, not a measured result.

Limitations and risks

• It moves real money. The README’s own warning says it can send ACH, wire, Bitcoin and Lightning payments and that you are responsible for every transaction.
• Model dependence. Only Claude Opus 4.6 was tested; other models may fabricate IDs or pay the wrong person, in the authors’ words.
• Instructions are not controls. Several safeguards depend on the agent following AGENTS.md, which is why the person in the terminal matters.
• Phishing and prompt injection. Email is untrusted input that the agent reads; the allowlist helps, but a compromised contractor mailbox would pass it.
• Spreadsheet as ledger. Fine for a small company, but there is no double-entry general ledger, period lock or segregation of duties; the ERPNext connector is optional and not part of the described workflow.
• Context-specific. OpenCollective, Bitcoin payouts and US 1099s are particular to Soapbox. Outside the US, tax reporting and e-invoicing rules differ.
• Credentials. One configuration file holds keys to the bank, exchange, email and Google; protect it and use the narrowest API scopes.

Common mistakes

• Building one big “do everything” script or workflow instead of small, testable steps (Soapbox’s version 1).
• Letting the agent pay first and record later.
• Trusting a display name or a new bank account in an email.
• Writing limits only in the prompt, with no check in the payment code.
• Running unattended before many supervised cycles.
• Skipping the monthly reconciliation that catches what the flow missed.

Conclusions

Sheila is a good example of what a small finance team can do now: not a platform, but a coding agent with a clear written procedure and a set of boring, single-purpose scripts against systems that have APIs. The value of the case is less in the stated time savings, which are not quantified, than in the published design: record before paying, saved recipients only, hard stops on unknown senders, human confirmation in reconciliation and a person watching. If you copy it, keep that structure and move the critical limits from the instructions into the code.