There is a moment, early in most AI projects, where someone produces a forty page document describing how the business works and asks us to feed the whole thing to the model. The instinct is good. The model should understand the business. But more context is not the same as better context, and the difference shows up fast once real work starts flowing through.
The problem is overfitting. If you hand a model every special case, every quiet workaround, every "well, except when it is a Tuesday and the client is in Rotterdam," it stops reasoning and starts pattern matching against your edge cases. It becomes brittle. The first situation that does not match one of your stored exceptions throws it, and you are left wondering why something that looked clever in the demo falls over in week three.
Brief the shape, not every case
The better approach is to teach the model the shape of how you operate, then let it reason from there. Tell it what a good outcome looks like. Tell it the few rules that genuinely never bend, the ones your most experienced person would never break. Tell it what to do when it is unsure, which is usually to flag and stop rather than guess. That is a far smaller brief than the forty pager, and it holds up under pressure because it is built on principles instead of a catalogue of one off incidents.
Your real exceptions still matter. They just do not belong baked into the model's instructions. They belong in the data and the process around it, where they can be checked, updated, and audited without anyone retraining anything. A model that knows the general rule and can read the current state of the business will outperform a model stuffed with frozen specifics, because the business keeps moving and the frozen specifics do not.
This is why we start every engagement with a Discovery Sprint rather than a prompt. In two to four weeks we are not writing clever instructions, we are watching how decisions actually get made, separating the durable logic from the noise. The durable logic is what the model needs. The noise is what makes it overfit.
Across the workflows we have helped put AI into, the useful brief turns out to be surprisingly short. The work is in getting the underlying data clean enough that the model can see the real situation, then giving it a tight definition of what counts as an exception worth raising. Once that is right, the instructions almost write themselves.
A good test is this. Read your brief back and ask whether it would still make sense if your business grew thirty percent or opened a new office. If half of it would need rewriting, you have described this month rather than the business. Trim it back to what stays true, put the rest where it can change, and you will have a model that gets sharper over time instead of more confused.
Facing something similar in your business?
Talk it through with our AI guide, or send the team a note. We will tell you straight whether and how we can help.