Making It Repeatable

Kris Van Meter · July 2026 · Guide

The pilot worked. On your own desk, with your own prompts, the drafts got faster and the analysis got sharper and a chunk of the busywork disappeared. So you rolled it out. Twelve people, twelve logins, twelve completely different results.

This is the question owners ask me more than any other right now: it works for me, so why won't it work for the company? The answer is almost never the tool, the model, or the people. The capability you built lives in your chat history, and chat history doesn't transfer.

Why the rollout collapses.

Watch what actually happens after everyone gets a license. Quality starts depending on who ran the task, because the skill lives in each person's private prompting habits. The same mistake gets corrected on Tuesday and comes back on Thursday, because the correction happened inside one conversation and evaporated when the window closed. Formats drift week by week until no two client documents look related. And when your best AI user leaves, the whole capability walks out the door in their head.

None of that is a training problem. You could send all twelve people to a prompt workshop and you'd get back twelve slightly better individual operators, still producing twelve different outputs. What's missing is structure that exists outside any one person's session.

The four pieces of structure.

1. A standing rules file. One document, loaded at the start of every session, that defines what your company means by good: the tone, the required formats, the definitions of your own terms, the hard bans. A rule that lives in someone's memory is a preference. A rule in the file is policy, and every seat inherits it automatically.

2. Templates that carry the standard. Stop asking the model to remember your proposal format and hand it the skeleton instead. The model fills structure; it doesn't invent it. Drift becomes impossible when the container is fixed, and review gets faster because every output lands in the same shape.

3. Checks before anything ships. Every output that leaves the building gets verified against something objective first: totals that reconcile with the source, required sections present, claims your compliance posture forbids flagged and stripped. AI is a probabilistic engine. The checks are what make its output deterministic enough to put your name on.

4. A correction loop. When the model gets something wrong and a person fixes it, the fix gets written into the rules file that same day. A correction made in chat expires when the conversation does. A correction written into the rules outlives the person who made it. Run this loop for three months and the system stops repeating old mistakes entirely; it only makes new ones, once each.

What you're seeing	What's missing
Quality depends on who ran it	The rules file
The same mistake keeps coming back	The correction loop
Formats drift month to month	Templates
An error reached a client	Checks before shipping

What you're actually building.

Notice that all four pieces are documents and procedures, not software purchases. That's the real distinction between adopting a tool and building a system. Adoption takes an afternoon and produces twelve licenses. A system takes discipline and produces an asset: your firm's judgment, written down, enforced on every output, improving every week.

It also changes what onboarding means. A new hire inherits the rules file, the templates, and every correction anyone ever made, on day one. Your standards stop being oral tradition. The pilot that worked on your desk becomes the way the company runs, the same way, at every seat, whether you're in the room or not.

Predictable and structured is buildable. Most owners can stand up the rules file and the first templates themselves in a week. The checks and the correction loop take more discipline, and that's usually where we get the call. If you'd rather build it with someone who has run this loop in production, start with Discovery.