Custom AI agent development, RAG and data systems

It depends on four things more than on the AI itself. How many of your systems the agent has to act on, since each tool it can call needs its own permissions, tests and failure handling. How much data it answers from, and how messy that data is. Whether it works in text or on the phone, because voice adds speech, latency and call handling. And how high the accuracy bar is, which sets how much evaluation work goes in before launch. THWorks prices the job rather than the hours: you get a fixed price for the agreed scope before the work starts, and if a new feature comes up midway, it is priced and agreed with you before it is built. Running costs are separate, since the model provider bills by usage, so we estimate them with you during scoping and build a cost ceiling into the agent.

Workflow automation follows a path someone has drawn in advance: when a form arrives, copy it here, notify them there. It is predictable and cheap, and for most repetitive work it is the right answer. An AI agent decides its own next step. It reads a request written in plain language, chooses which tool to use, checks the result, and tries something else if the first attempt fails. That flexibility is useful when requests vary too much to map out, such as customer questions, messy documents or triage, and it is what makes an agent harder to test. A lot of good systems combine the two: an automation moves the work around, and an agent handles the one step that needs judgement. If a drawn path would do, we will tell you, and our automation team builds that instead.

RAG, short for retrieval-augmented generation, makes a language model answer from your own documents and data rather than from what it absorbed in training. When a question comes in, the system first searches your content for the passages that matter, then gives only those to the model with an instruction to answer from them and cite them. You need it when the AI has to know things that are specific to you, such as your products, policies, contracts or support history, and when an answer that sounds right but is not would cost you something. You probably do not need it for drafting, summarising text someone pastes in, or general questions. Most of the quality of a RAG system comes from the retrieval half, which is where we spend most of the build.

By narrowing what it is allowed to say and checking it constantly. The agent answers from passages retrieved from your sources, cites them, and is instructed to say it does not know when the sources do not cover a question. Before launch we build an evaluation set: real questions from your business, each with a known good answer, and every change to prompts, models or retrieval is run against it so a regression shows up in testing rather than in front of a customer. Guardrails then catch the categories of answer it must never give. None of this makes a language model perfect, and nobody honest will promise that. What it does is make errors rare, visible and fixable, with the agent filling a gap with an admission instead of an invention.

Reliability is mostly ordinary software engineering around the model. Calls to the model and to your tools retry when they fail, slow responses fall back to a simpler path, and every step is logged so a bad answer can be traced to its cause. Spend has a ceiling per conversation and per day, so a loop cannot run up a bill overnight. For anything consequential, such as a refund, a booking or a message to a customer, the agent can be set to hand over to a person instead of acting alone. After launch, monitoring tracks answer quality against the evaluation set, because models and data change and a system that was right in March can drift by June.

Yes. We have built voice agents that answer inbound calls and hand the caller to a person with the context attached, that call a property lead back while their enquiry is still fresh, and that book dental appointments by procedure into a real calendar. Voice is harder than chat in ways that matter for the build. The agent has to respond fast enough that a pause does not feel broken, and it has to cope with interruptions, accents and the moment it should stop and transfer to a person. Each of those is designed and tested rather than left to the model. The case studies linked on this page show how each of them works.

Whichever fits the job. We work with current Claude and OpenAI models and with open-weight models that can run in your own environment, and we choose per task on quality, speed and cost rather than by loyalty. A support agent might use a fast, cheap model for routing and a stronger one only for the hard questions. The agent is built so that swapping the model is a configuration change tested against the same evaluation set, which matters because the best option changes every few months and you should not be locked into last year’s choice.

Yes. Retrieval runs with access controls, so the agent only sees the documents the person asking is allowed to see, and nothing from your data is used to train a public model. Where data cannot leave your environment, the agent, the vector database and an open-weight model can all run inside it. These are mechanisms rather than certifications: THWorks holds no SOC 2, ISO 27001 or HIPAA attestation, so if your industry requires one, your compliance team decides what is acceptable and we build to their requirements.

Often, yes. If you want a chatbot for common questions or a one-off script, an off-the-shelf tool is cheaper, and we will say so on the call. A custom agent earns its cost when the AI has to be right, runs without someone watching it, answers from data that is yours, or has to act inside your own systems. If only part of that is true, the usual answer is a small agent for one job, built so it can grow.