What the setup did

Friday morning

On Friday, October 8, Nisha came in early. Lakeshore's owner would call at 6 p.m. Before that, she wanted to understand her own week. What exactly had made it work?

She wrote two lists.

The part	What it did this week	Without it
The project	Gave every run the same rules. Took one new rule on Tuesday, and kept it.	Someone pastes the rules each time, and forgets one
The skill	Wrote both memos in Sana's way. Knew that a returned check is an unrecorded item.	The memo depends on who wrote it
The shared drive, connected	Let every run, and the worker's morning check, read the same files	The files wait on one person's laptop
The folder, through the desktop app	Let Claude read Dana's three files where they were, before the firm copied them into the project. Held the bank's statement for Hamza's own tests.	Hamza uploads files one by one
The borrowed desk	Matched 3,400 lines in minutes, the same way each time: in three runs, two on Tuesday and one on Wednesday	Eight hours, and tired eyes
The artifacts	Held the pack as four pieces that every run updated	New files each time, with old ones left around
The morning check (the worker's routine)	Looked at the bank on a morning when nobody had asked	The firm finds out from the client

No part was new. Each one is taught in an earlier section of this book (Exhibit 1). What was new was the joining.

What people did

The person	What only a person did
Nisha	Decided what the setup may and may not do. Approved Tuesday's pack, by name and figure.
Sana	Wrote the method. Saw what the first run forgot. Stopped a fix by hand. Approved Wednesday's pack. Wrote to Dana herself.
Hamza	Checked the arithmetic, the matching, the leftovers and the pieces, without Claude.
Dana	Recorded the returned check, and called her bank

Nisha looked at the two lists side by side.

"The setup did the work. We did the judgment. Before this week we spent most of our hours on the first list."

Is this better than a document tool?

Hamza asked the question a student would ask. "Dana's old accountant used Google Docs and Slides. Those have AI in them now too. What did we really gain?"

Nisha answered in two parts.

"For writing, nothing. Google's editors are very good. They also keep a better record of earlier versions of slides than ours do. If the job were to write a memo, I would not care which one we used."¹,²

"But the job was never the memo. The job was the bank lines, the matching, the rule about returned checks, the four pieces that must agree, and the morning check. A document editor starts when someone has the figure. Our setup starts with the bank's file and ends with the pack."

She added that the comparison has limits. The firm had not tested Google's AI features. And another firm could join other tools into a setup too.

She drew it as a table (Exhibit 10).

	A document editor, with AI help (Google's, or Claude's own docs)	The firm's setup
Where the work starts	When a person brings the figure	At the bank's file
Who does the matching	A person, perhaps with AI help in a spreadsheet	Claude, with a program
Where the rules are	In people's heads	In the project and the skill
Next month	Start again	Run it again
A late change	Fix each file by hand	Run it again
Who is responsible	People	People

The last row was the same in both columns. She underlined it.

Where it can still go wrong

Sana did not work Fridays. On Thursday evening she had left a list on Nisha's desk: what the setup does not do (Exhibit 12).

Instructions only ask. The project says "never send anything". A rule written in the instructions only asks Claude. A setting in the app really stops it. For example, an Owner decides which connected apps the firm's members may use at all.³ Here a setting does the work: Nisha turned on only the shared drive, so no chat in Claude can send an email.
The worker is different. The worker is set up separately, in its Slack channel. If that channel can still reach reports@, the worker could send. It also runs the morning check. For the worker, "change nothing in the pack" is only a sentence. What protects the firm there is its habit: a named approval before anything leaves.
The pieces are still copies. No piece reads another.⁴ One run writes them all, and a person checks that they agree.
Hamza's tests missed one thing. His statement already showed the returned check on Tuesday. But he took the closing balance from Claude's run note, not from the statement. From now on, his first test compares the two.
A program can match wrongly. Two payments of the same amount on the same day can be paired the wrong way round. Hamza's twenty pairs are a sample, not a proof.
The morning check only looks where it is told to. It saw the returned check because it downloaded the bank's lines again. It would not see a mistake in Lakeshore's ledger.
The first download was too early. Tuesday's run used Friday's file, which was four days old. Sana's note asked for a rule, and on Friday morning Nisha added it to the instructions: "If the newest bank file is more than a day old, stop and say so." Before each run, Hamza now asks the worker in Slack for a fresh download himself.
One person can now do a lot, fast. That is the point of the setup. It is also why the approval must stay with a named person.

At the bottom Sana had written: "It did two days of work in twenty-five minutes. It can do two days of damage in twenty-five minutes too. I will keep reading everything I sign."

What the firm had now

By Friday the firm owned something it had not owned on Monday: a setup that could do Lakeshore's month-end again in October, and in November. Most of it would work for another client with one new project.

Nisha saw that this was worth more than the pack. She also saw the question that Lakeshore's owner was going to ask.

Going further: who changes the method? The project's instructions and Sana's skill are the firm's method. This week two sentences were added to the instructions, and nothing recorded who changed them, when, or who agreed. A change to the method needs the same care as a change to the pack: one person proposes it, another reviews it, and a record keeps both.

Teams that keep their instructions and skills as files can use version control for this. Every change is saved with its author and its date, and nothing is lost. A pull request is a proposed change with a page where it is described, checked, discussed and approved. It is Nisha's approval of one exact pack, applied to the method itself.

You can work this way from the Claude desktop app's Code tab, which works in a folder on your computer, or with a separate app such as GitHub Desktop. Some desktop apps can open the pull request for you. Later in this book, 15.3 GitHub and the pull request teaches how.

What the setup did

Friday morning