Output quality is a function of context quality. I encode your design system, voice, constraints and prior decisions into files an agent reads first — so work comes back consistent rather than merely plausible. This site runs on exactly that, and the file is published for anyone to read.
Your AI feature works in the demo and falls apart on real questions. It invents things it shouldn't, misses things it should know, or answers confidently from stale information. The prompt has grown to two pages and nobody wants to touch it.
Most AI features fail on context rather than on the model. The model is fine; it hasn't been given the right information, in the right form, at the right moment.
So the work is structural. What the system needs to know, where that knowledge lives, how it's retrieved, and what it should say when the answer isn't there. Instructions get separated from knowledge, because merging them is why prompts become unmaintainable. Then evaluation — a real set of hard cases you can re-run after every change, rather than trying three questions and calling it good.
The talking avatar on this site is a working example. It runs on a structured knowledge file rather than an open-ended prompt, which is why it can answer specifically about work I've done and decline the things it shouldn't speculate on.
Two to five weeks for a first pass on a single feature. Ongoing evaluation and refinement is worth budgeting for — this isn't a set-and-forget layer.
Is this the same as prompt engineering?
It's the larger part of it. Prompt wording matters far less than what information the model can see.
Do you build it or specify it?
Either. I can assemble knowledge files and evaluation sets directly, or specify the structure for your engineers to implement.