The AI parts I build myself
Most of what a build runs on is off the shelf. Anyone can rent the same models and install the same packages I do. This group is the part that is not off the shelf. It is the work I wrote myself and put on top: the search that finds the right passage in your own files even when the words do not match, the layer that keeps a helper answering only from what you approved and hands a hard question to a person, and the checks I run against a build before it goes live. These are the parts behind jobs like "Answer the questions you get asked all day" and "Find anything in your own documents in seconds". They are also the reason a build holds up once it is live, rather than only on the day I demo it.
Hybrid retrieval pipeline
The search that sits under a helper answering from your own material. It looks two ways at once: for your exact words, and for your meaning, so a customer who phrases a question oddly still gets the right passage back. This is what lets the build behind "Find anything in your own documents in seconds" pull the right answer out of years of files, and what keeps a website helper answering from your approved information rather than guessing.
Agent orchestrator
The part that decides what a helper should do next. A customer question is rarely just one step: answer this, look that up, offer a time, or stop and hand it to a person. This is the piece that runs those steps in order and knows when to pass a question to you instead of pushing on. You see it working whenever a helper answers, books a time, and knows the one question it should not try to answer, all in the same conversation.
Guardrail and rate-limit layer
The set of limits that keeps a helper safe to put in front of real customers. It holds the helper to your approved information so it does not make things up, keeps it inside the boundaries you set, and hands anything out of scope to a person. It also caps how fast and how often it can be run, so a busy day or someone poking at it does not turn into a surprise bill. This is the quiet layer behind "Get straight answers about the rules you follow" staying inside its lane.
Pre-launch test suite
The checks I run against a build before it runs on its own. I test it against its rules: what it should handle, what it should leave alone, and when to hand something to a person. It does only what you have approved, and it goes live once it holds up. Most builds skip this step. It is the one that catches a wrong answer while there is still time to fix it.
Document ingestion pipeline
The machine that turns your files into something a build can actually search. Word documents, PDFs and other records that were never tidy get read, cleaned up and broken into pieces small enough to look through quickly. Without this step there is nothing for the search to search. It is the first half of the build behind "Find anything in your own documents in seconds", the part that happens before anyone asks a question.
Funnel instrumentation
The part that watches where your enquiries go and counts what actually happens. It tracks a lead from the moment it lands to the point it becomes a booking or a paid job, and flags the ones going quiet. It is also how I write down where your numbers sit before a build starts, so afterwards you can see the change in your own figures instead of taking my word for it. This sits behind jobs like "Sort and score enquiries the moment they land".
Token cost accounting
A running tally of what a build spends each time it calls an AI model. Every question a model answers, and every document it reads in, has a small cost, and left unwatched those add up in ways that are hard to see. This keeps count operation by operation, so a build can be made cheaper where it is spending too much, and so there are no surprises on the bill.