The memo is the product.

Most AI projects we are asked to rescue are not broken in the way the team thinks they are. The model is fine. The vector store is fine. The eval harness, where one exists, is fine. What is broken is the sentence at the top of the document that is supposed to say what the thing is for.

When we sit down with a new client, the first artifact we ask for is not the codebase. It is the memo. Sometimes it exists, buried in a Notion page nobody has opened in three months. More often it does not exist at all, and the team has been navigating by a shared, slightly different hallucination of what they are building.

This is the bottleneck. Models have become cheap. Compute has become cheap. Talented engineers who can wire an agent together in an afternoon are no longer rare. The scarce resource is a clear, written account of what the system is supposed to do, for whom, under what constraints, and how you will know it is working.

A good memo is short. It is opinionated. It survives contact with a skeptical reader. It does not hide behind diagrams. It names the user, the job, the failure mode, and the next decision. If you cannot write it, you cannot build it, and no model release is going to fix that for you.

The work, then, is mostly writing. The code follows.