AI integration without the hype cycle.

The first question is never which model to use. It’s which manual step costs you the most hours, and whether that step tolerates an error rate above zero. Those two filters kill most of the ideas on a whiteboard. A workflow that runs 40 times a day with a human already checking the output is a strong candidate. A workflow that runs twice a month and has to be exactly right isn’t, however good the demo looks. We spend the first week reading your process documents and watching the work happen, then rank the candidates by hours saved against build cost. Two or three usually survive.

On architecture, start with retrieval. Most requests for fine-tuning describe a retrieval problem under a different name. Fine-tuning teaches a model a format or a voice. It won’t teach it facts that change weekly, and it ties you to a model version that already has a deprecation date. Retrieval keeps your knowledge in a database you control, so fixing a wrong answer means updating a row rather than retraining. We reach for fine-tuning in two cases. A small open model that has to hit one narrow, high-volume task cheaply, and outputs where the format matters more than the content. Everything else is a chunking and reranking problem.

Most LLM features ship on vibes. Someone tries ten prompts, it looks convincing, it goes live, and three weeks later support is fielding complaints nobody can reproduce. So we build the evaluation set before we build the feature. 100 to 300 real inputs with graded expected outputs, split by category, running on every commit. When a prompt change lifts accuracy on refunds and drops it on cancellations, you see that in the pull request rather than in a customer email a month later. None of it is interesting work, and it’s the reason you can improve the feature afterwards instead of guessing at it.

Pick the model last, and pick two. Every call goes behind a thin provider interface, so moving from one vendor to another is a config change rather than a rewrite. Prices move, rate limits bite, and a model you depend on will eventually be retired. On cost, the model price is rarely the problem. You’re sending 8,000 tokens of context where 1,200 would do. Trimming retrieval, caching stable prefixes, and routing the easy 70 percent of requests to a cheaper model typically halves a monthly bill with no measurable quality loss. We measure that per feature, per day, so you can check the saving against last month’s invoice.

Consulting and building aren’t separate businesses here. The engineer who scopes your use case writes the code, which is why our advice runs conservative about what a model can be trusted to do unattended. When the work becomes a production pipeline it moves across to our AI automation and workflow builds, and the interface around it comes from the same team that does our Next.js web development work. Look through the projects we have shipped or everything the studio builds.

If you want the long version of what that advice looks like once it ships, the Fiona case study is the clearest one: a voice agent built for a client where the model was the part that already worked, and the audio path, the billing arithmetic and the calling rules were the actual project.