AI Development

Three things, mostly: find information in your own content, generate text or structure from it, and take a routine action on it — routing a ticket, filling a record. Everything else is a variation. The useful question is which repetitive step in your product costs the most time.

A chatbot answers. An agent does something — books the slot, updates the record, escalates the ticket. The difference isn't intelligence, it's permission: an agent is connected to systems it can change, which is why the limits and the audit log matter more than the model.

RAG means the model answers from your documents instead of its training data — it retrieves the relevant passages first, then writes the answer using them. You need it when the answer has to be current, specific to your company, or traceable to a source. You don't when the task is generic writing or classification.

It depends on the shape of the work. Connecting a model to an existing product is a different order of cost from building search over ten years of documents. We scope after the use-case check, so the estimate is tied to something specific — and if the data isn't there, we say so before you spend on a build.

That's a separate number from the build, and usually the one people forget. It depends on how many requests, how long the prompts are and which model. We set caps and per-feature metering so the bill is bounded, and give you a projected monthly range before launch.

By default, no. OpenAI and Anthropic exclude API data from training in their terms. Beyond that, we keep personal and sensitive fields out of prompts in the first place — the less that leaves your systems, the smaller the question becomes.

You can't remove the risk, so you design around it. Answers are grounded in your own content and cite the source, the model is instructed to refuse rather than guess when it isn't confident, and anything with consequences goes through a person. Where a wrong answer is expensive, the feature suggests instead of acting.

We build a test set from real cases before development and agree a threshold with you. The feature has to clear it. That number stays in place after launch too — it's how you notice when a model update has changed the answers.

We work with OpenAI and Anthropic, chosen per use case rather than by default. The integration sits behind an interface, so switching providers is a configuration change and a re-run of the test set, not a rebuild.

A prototype on your real data usually takes weeks, not months — that's the point of doing it early. The distance from prototype to something users can rely on is the longer part, and it depends on how wrong an answer is allowed to be.

Then we say so. The use-case and data check exists to find that out first, and it's the cheapest step in the project. Sometimes the honest answer is a rule, a better search index, or fixing the process — and none of those need a model.