The word “harness” has started circulating in discussions of business automation. What is scarce is the specifics: what you actually build, and how.

I currently run harnesses across two operations — roughly 30 scripts and 10,000 lines for business-unit forecasting and results management, and 12 scripts and 6,000 lines for running a newly opened site. Both were written one script at a time, in dialogue with Claude Code. This article is about how to choose your first one and get it finished.

What a harness is

Start with the word.

A harness is a thin layer of scripts sitting between you and your business systems. As the name suggests, it is not a robot — something that runs on its own — but a bridle: a piece of tack that connects a person to a tool and draws out force. It does not run in your place.

So the goal is not “automate everything.” It is to carry the work up to the point of judgment. Collect, reconcile, produce a draft, then stop at dry-run. Beyond that line, a human or an AI decides.

If you do not draw that line first, what you are building expands without limit.

The behavior reduces to four things

After writing 40-odd scripts across two operations, one thing became clear: in every case, the behavior reduces to four categories.

1. Collect — pull deterministically, via API or browser. Attendance and workload figures, approval-request line items, calendars, spreadsheets on shared drives, chat conversations. Reproducibility matters most here; cleverness is not required.

2. Reconcile and post — look before you push. Post workload figures into the management system; check assignment allocations against actual results; diff a joiners-and-leavers list against the org definition; match a photo of key tags against the key register. The default is dry-run, and writes happen only when an explicit flag is passed.

3. Generate — produce the raw material; a human decides and writes. Weekly reports, board-meeting decks, drafting approval requests, org charts. The harness produces material only. The prose is written by an AI reading that material plus a writing brief, and then a machine turns the result back into Word or PPTX.

4. Monitor and notify — run unattended, catch what falls through. Detect unanswered requests and DM the owner; push out only today’s items from a backlog, capped at a fixed number; report on leader activity weekly. Overlapping scheduled runs are prevented with a file lock.

Your first harness will almost certainly be a (1).

The principle running through all of it — always separate collection from judgment

One pillar holds across all four behaviors: collection is deterministic; judgment goes to an AI or a human.

For meeting-material generation, this looks like:

The harness produces material (mechanical, reproducible)
  → An AI reads the material plus a writing brief and drafts (judgment)
    → The harness renders it to Word / PPTX (mechanical)

Monitoring takes the same shape: collect (deterministic) → pre-filter (deterministic) → assess (AI) → suppress duplicates → notify. The scan itself is done deterministically; the AI receives only a narrowed set of candidates and their context.

There are two reasons to split it this way: reproducibility, and being able to tell what broke when something breaks. If collection and judgment are entangled, a bad output leaves you unable to distinguish “it didn’t fetch the data” from “it judged wrongly.” For a harness in production, that is fatal.

Close the Claude Code session in a day

On to how they get built. I run investigate → implement → use in production → record and close it within a single session.

1. Investigate. Dump the structure of the target system first. I give each harness a discovery-only mode — something like --discover — that writes screen structure, HTML, and API responses into output/, screenshots included. I settle the path through the system before writing any real implementation. This is also where I confirm the quirks of the API’s naming conventions and auth scheme.

2. Implement. Write one core script; derivatives become thin wrappers. Default to dry-run. Writes do not happen until an explicit flag is passed.

3. Use it in production. Use it on that day’s real work. This matters, because test data hides an enormous amount. Eyeball the counts and the unmatched items before letting it run, and afterwards re-fetch the state from the server to confirm the intended result actually occurred.

4. Record. Write the pitfalls and the decisions back into HANDOFF.md. The next session starts by reading that file. In my case, 30–40% of commits are documentation only.

One note on pace: normally it’s one to three commits a day, but on the day a problem lands, I build in a burst. In one month, three specific days carried 9, 10, and 19 commits. Trying to make even daily progress produces less usable output than building it out on the day the work actually hurt.

The steps for your first harness

Given all that, here is how to start today. The only real trick is: don’t build big.

1. Pick one repetition. Choose a single transcribe / reconcile / paste task you do every week. And when you choose, pick a “read” operation, not a “send” one. Handling writes in your first harness means that when it goes wrong, you lose your nerve.

2. Decide the connection route. Is there a public API? If not, is it behind SSO? If neither reaches, write down in the docs that this part stays manual. The third option is a legitimate design decision, and refusing to pretend it is automated pays off later.

3. Investigate with Claude Code. Dump the structure; keep the screenshots, HTML, and API responses. Do not throw these away. The next time you touch that system, they are the single most valuable asset you have.

4. Implement with dry-run. Start with reads. Make writes conditional on --commit. Make the output show counts and unmatched items at a glance.

5. Create HANDOFF.md. Write the pitfalls and decisions back. Create it from the first script. Try to add it later, and the most valuable material — why you got stuck the very first time — is already gone.

6. Run it on real work for a day. Use it on that day’s job and record what helped and what didn’t. The next day, add one wrapper.

Why this differs from conventional internal-tool development

Finally, why this way of working holds together at all.

Estimated as “internal tool development” in the conventional sense, none of what I’ve described here would ever get started. Under the assumption of requirements documents, specifications, and a development contract, spending hundreds of thousands of yen to automate a 30-minute task is not a decision anyone makes.

What AI-driven development changed is that break-even point. If one script takes a few hours, then the rule “ask whether this will recur next month, and if so, script it immediately” becomes viable. In my case, somewhere past the thirtieth script in two months, the routine work had become the exception.

There is one more effect, secondary but substantial. Putting work into code surfaces ambiguity in how numbers are defined, and structural errors along with it. Simply moving an aggregation into code turned up several mistakes that had been buried in manual calculation. In monetary terms, that verification effect may matter more than the automation itself.

Building a harness is not building a robot. It is building the tack that carries the work up to the point of judgment. Framed that way, it becomes clear that the first one can be very small indeed.

Which task to start from, and how to spread the practice inside an organization, depend on the situation. I’m happy to go into specifics in a conversation.