AI systems that hold up in production, not demos.

Retrieval-augmented generation means the model answers from your documents rather than from what it memorised during training. You need it when answers must reflect your own content — policies, product data, past tickets — and must stay correct as that content changes. You do not need it when the task is classification, extraction or rewriting, where a prompt and a schema are cheaper and more reliable. We will tell you which one you are looking at before proposing a build, because retrieval adds infrastructure that a lot of projects are better off without.

An agent decides its own next step. Instead of one prompt producing one answer, it works in a loop: read the situation, choose a tool, act, check the result, continue or stop. That is useful when a task has genuinely variable steps — researching across sources, reconciling records, triaging and routing. It is the wrong shape when the steps are always the same, where a plain workflow is faster, cheaper and far easier to debug. Most systems we build are mostly workflow with agency at the few points that need it.

Four things, in order of how much they actually help: ground answers in retrieved sources and cite them, so a claim can be checked; validate every model output against a schema before it reaches your database or another system; constrain scope in the system prompt and refuse rather than guess when retrieval returns nothing relevant; and run an evaluation set on every change so a regression shows up before your users find it. Anyone promising elimination rather than measurement and containment is selling something.

Whichever is currently best for the specific task at the price you can sustain, which will change during the build. We put model access behind an interface with the model ID in configuration, so switching provider is a config change rather than a refactor. Task-appropriate matters more than frontier: a small cheap model often does extraction and classification as well as an expensive one, and the saving compounds at volume.

Usage-based, and worth modelling before you build. We estimate token cost per interaction during scoping, then design around it: caching the parts of the prompt that never change, routing simple requests to cheaper models, and putting a hard daily spend cap in front of everything so a loop or an attack cannot produce a surprise invoice. This site's own chat does exactly that — roughly a cent per qualified conversation, with a cap that degrades to a contact form rather than failing open.

Yes, and the boundaries are the design. Credentials stay server-side and never reach the browser. Retrieval is scoped so a user only ever sees documents they already have access to — permissions are enforced at query time, not filtered afterwards. Personal data can be redacted before it reaches a model provider, and where residency or a no-third-party rule applies, we run open-weight models in your own infrastructure instead. Which of those you need is a scoping question, not a default.

An evaluation set, built before the system is finished: real inputs with known-good outputs, scored on every change. Without it, "it seems better" is the only available measure and every prompt change is a gamble. We also instrument production — latency, cost, retrieval hit rate, refusal rate, and the queries that returned nothing — because the failure you care about is usually a question your corpus cannot answer, not a model that is broken.

That is the common case. Most of this work is integration rather than greenfield: an assistant inside an existing app, retrieval over a corpus already in your database, an agent driving tools your team already runs. We start with an audit of where the data lives and what the access model is, because those two answers determine the architecture more than any model choice does.