Private beta · macOS

You can't babysit six agents.

Watching one coding agent works. You read along, notice when it starts going the wrong way, and correct it. Do that for six at once and it's your whole day.

Tallow puts your time at the two ends of the job. You agree a plan before anything runs, and you review the result when it's done. In between, the run is sealed: the agent works on its own, and checks written from the plan decide when it's finished.

Refund idempotency 3 blockers

Goal

A retried charge must never move money twice, under any interleaving.

Approach

Key every refund on the provider reference and settle through the ledger, not the gateway.

Verification

An over-refund is impossible under concurrent retries.

Out of scope

Partial refunds. Chargeback reconciliation.

2 threads · 1 question Create task

Attention

Six runs. Two need you.

Violet runs are working and don't need anything from you. Amber runs are waiting on you, with a report to read or changes to look at. You deal with those and leave the rest alone.

Runs payments-api

refund-idempotency 12m Sealed
webhook-retries 4m Sealed
ledger-race — Report ready
search-indexing 31m Sealed
auth-session-fix — Changes requested
csv-export 2m Sealed

Plan You

Start with a plan you agree with.

A plan in Tallow is a document with prose, tables, diagrams and code. You comment on the specific sentence you disagree with, and each comment becomes a thread. Tallow won't treat the plan as ready while threads are open or questions are unanswered.

When it is ready, you turn it into a task. If the agent thinks the plan is missing something it needs, it says what and declines to start. You can't force it to. A gap is cheaper to fix now than forty minutes into a run.

If you don't know enough to write the plan yet, start a research run. It reads but never changes code, and it reports back as a document with a source for each claim.

Start from BlankLinear ticketNotion pageResearch run

Build Sealed

Then leave it alone.

Before the run starts, Tallow turns the plan into a set of checks, called gates, and shows them to you. Then an agent picks up the work and writes the code. You can stop the run, but you can't redirect it or turn a gate off to get it through. If you could, you'd be back to watching it.

Gate results are kept for every commit, so you can see where a run got stuck and when it recovered.

Gates at 7d83b08 Passing

types
lint
test
arch
An over-refund is impossible under concurrent retries

Repo checks: The type checks, linters and tests your repository already runs. Tallow finds them in the repository, so there's nothing to configure.
Verifications: Checks for this task only, written as statements that must hold. Each links to the part of the plan or the thread it came from.
Principles: Your own standards, checked on every run. They come from calibration, described below.

If a run fails, you get a report: what it tried, what went wrong, and a suggested change to the plan. When ledger-race failed for the third time, the report's first paragraph said the problem was in the plan. You fix the plan and run it again.

Review You

Check what it decided on its own.

No plan covers everything. When a run has to make a choice the plan didn't, it records what it chose and why. You accept or question each one, and Tallow won't open the pull requests until you've been through them all.

Decisions 1 open

Took the advisory lock in the ledger, not the gateway adapter
Accepted

Plan §2 puts settlement in the ledger; the adapter is replaceable
Left the legacy /v1/refunds route untouched
Accepted

Out of scope said partial refunds; this route only serves them
Widened provider_ref to 128 chars
Needs you

Stripe test fixtures exceed 64; no thread covered this

Open 3 pull requests · locked

Each verification comes with the screenshots the run took while checking it, linked to the commit they were taken at, such as 7d83b08.

Teach it how you review.

Calibration shows you a pull request and asks what you'd say about it. From your answers, Tallow writes two documents you can read and edit: your principles, which become gates on every run, and a guide to how you write, used for replies sent on your behalf.

When teammates comment on a pull request Tallow opened, each comment is sorted into one of three kinds before you see it.

Proposed fix: Small and uncontroversial. Tallow prepares the change as a run. Approve it, and it commits, re-runs the gates, replies and resolves the thread.
Drafted reply: Something worth discussing. A reply is drafted for you to send, edit or discard.
Plan conflict: The comment asks for something the plan ruled out. You decide whether to change the plan or explain why it stands.