AI agents for business

We start with one workflow and a set of real cases. Before writing any prompts, we collect examples from your work, such as documents, emails or questions, each with the answer a careful person would give. Cases with known answers are more useful than a long specification, because they become the test the AI has to pass.

From you we need those examples, a person who can say what a correct answer looks like, and access to the systems the workflow reads from and writes to. We also agree what the AI must never do on its own, such as sending an email, paying an invoice or changing a customer record. Those steps wait for a person's approval.

The first stage builds the workflow and an evaluation set from your examples. Each week you see results on that set: which cases it gets right, which it gets wrong and why, and the cost per case at current model prices. The workflow goes live only when its results are good enough for the agreed use, and you decide what good enough means.

It will be wrong sometimes. Models are probabilistic: the same input can give different outputs, and a confident answer can be false. The design question is not how to make the model perfect, but how to catch a wrong answer before it costs money.

We use several layers. The model returns data in a fixed schema, and anything that does not fit is rejected. Your business rules run as normal code on the output: totals must add up, dates must be valid, a supplier must already exist. Values the model is unsure about are marked, and a case with a doubtful field goes to a person. Every call is traced with its input, output, model version and cost, so a bad result can be found, explained and added to the evaluation set.

Before a prompt or model change goes live, it runs against the evaluation set, and a drop in accuracy blocks the release. The same set lets us compare models and move to a cheaper one when it does the job just as well.

Our AI document checks product is built this way. Documents are classified and their fields extracted with Claude, and values the model was unsure about are shown as such. The checks are deterministic code, not another model call. Classifications, extractions, corrections and check runs are append-only, so history is never overwritten. In the AI product generator, generated SVG is sanitised before it is stored, and the first version priced each product from a fixed markup plus the model cost of making it.

The workflow runs in your accounts, with model usage billed to your own API key. You get the code, the prompts under version control, the evaluation set and the script that runs it, and the tracing dashboard. The runbook covers how to review flagged cases, add an example when the AI gets something wrong, change a rule and check the cost per case.

Models change and providers retire versions. Because the evaluation set is yours, you or your developer can test a new model against your own cases before switching, instead of trusting a provider's announcement. Monthly support covers model updates, new examples and monitoring, or your team takes them over.

AI is not always the answer:

• The steps follow clear rules with no reading or judgement? Business process automation is simpler and cheaper to run.
• The real problem is data that never reaches the right system? Start with API & system integrations.
• AI is the core of a new product rather than a step in your operations? See MVP development.