I find the work AI should be doing, build it, and get people using it.

The flow

1. Map the market
2. Screen on the numbers
3. Team picks targets
4. Research each target
5. Draft the letter
6. Check every fact
7. Partner edits and signs

SoftwareA person decides

Design choices

• Engines before screens. Each tool was proven from the command line before it got a page, and the page calls that tested engine, so the screen cannot drift from what was tested.
• The right model for each job. Haiku reads websites and filings, Sonnet writes the analysis, Opus writes the letter, all set from one list.
• Source everything. Every claim carries its source and a confidence level. A checker traces every name and number in a letter back to the research before a partner sees it.
• Refuse rather than bluff. Paid services are checked before a run, and a run that cannot succeed will not start. Every call is costed and logged.

How I tested it

• 23 offline checks, each proved by breaking the code on purpose: 150+ deliberate breaks, every one caught.
• A root-cause review of three months of runs: 31 findings, 29 fixed.
• Success reported weekly against a 99% target, where a wrong letter counts as a failure.
• About 49,000 lines of Python, about 8,000 of them tests. Sole builder, working with Claude Code.

Version one

A nine-stage pipeline for a UK search fund, with three human review gates. It took 200 companies through ownership checks, scoring, sourced research and drafted messages in 10 to 12 hours for about £80, against roughly 300 a week by three people by hand. About 61,000 lines of Python, with about 1,360 tests.

The flow

1. Question in plain English
2. Agent searches the index
3. Reads the source file
4. Answers with quote and file name
5. Colleague checks the source

SoftwareA person decides

Design choices

• Read-only by design. The agent works through 12 read-only tools. The firm's library is never copied or changed.
• Read once, ask many times. One client's files were read and summarised into a DuckDB index of about 2,250 documents, so each question is quick and cheap.
• "I don't know" is a feature. It answers only from the documents, quotes them and names the file, and says so when the answer is not there.
• Scoped on purpose. One client's library, because reusing one client's material on another mandate is a confidentiality question before it is a technical one.

Where it stands

• Working proof of concept. The wider archive, about 20,000 documents over 13 years, has been surveyed for the next stage.

The programme

1. Weekly sessions on live work
2. Repeat work into Skills
3. Test each Skill
4. Security review first
5. Firm-wide rollout
6. Founders trained in Munich

What made it stick

• Live work, never toy examples. Sessions always worked on the team's live tasks, across Claude, Cowork, connectors and the Excel, PowerPoint and Word add-ins.
• Repeat work became Skills. Core processes packaged as Claude Skills, each with instructions, scripts, templates and a QA checklist.
• Measured, not assumed. An evaluation harness on the databook Skill: a 100% pass rate with it against 84% without, three runs on each of three tests.
• Security before convenience. Before rolling out an open-source Companies House MCP server (18 tools), I reviewed it, pinned the version, packaged it for one-file install and wrote the risk briefing.

Result

• The whole firm moved onto Claude Enterprise, and a colleague has since brought a tool of his own onto the hub.