AI agents · RAG · Workflows

AI development
that survives contact with real users.

We build AI into products and business workflows: answering questions from your documents, processing information, and helping users take action. The work is integrating hosted language models with your data and tools, then engineering the retrieval, evaluation, guardrails and interface that make the result dependable enough to ship.

Discuss your AI project ↗

What we build

Useful intelligence,
inside a real product.

We start with the task and the available data, then assess whether AI is the right tool at all. A prototype measures answer quality, latency and operating cost on your own examples. Production scope adds failure handling, evaluation, access controls and the interface people actually use.

Knowledge assistants (RAG)

Search and question answering grounded in your documents, tickets, policies or product data. Retrieval-augmented generation with source references, and retrieval that respects who is allowed to see what.

AI features in your product

Summarisation, drafting, classification, data extraction from documents, semantic search and conversational interfaces, shaped around one specific user task and integrated into your existing web or mobile app.

Agents and workflow automation

Tool-using agents that read from and act in your business systems through APIs: triaging requests, preparing records, filling in drafts. Narrow permissions, logged actions and human review where an action needs approval.

Evaluation and guardrails

A test set built from real examples, automated scoring, regression checks on every prompt or model change, input and output validation, cost limits and monitoring. This is what separates a demo from a feature you can support.

Who this is for

Teams with a specific task, not a mandate to “add AI”.

AI development with BBR fits:

Software companies adding an AI feature to an existing product and wanting it engineered, measured and cost-controlled.
Founders building an AI-first product, where the model is central and the product around it (accounts, billing, data handling, interface) still has to be built. This usually combines with our SaaS development or MVP work.
Operations teams with repetitive, language-heavy work: reading documents, answering recurring questions, moving information between systems. Often delivered as an internal tool.

What we do and do not do

BBR integrates hosted models from vendors such as Anthropic (Claude) and OpenAI, and open-weight models served through APIs. We build the retrieval layer, the tools an agent can call, the evaluation tooling, the guardrails and the product around them. We do not train foundation models, run bespoke machine-learning research, or build custom computer-vision or forecasting models from raw data. If your problem needs that, a specialist ML team is the right choice and we will say so.

When AI is the wrong tool

Part of the first conversation is checking whether a language model should be involved at all. It often should not be when:

The rule can be written down. Tax calculations, eligibility checks and routing by fixed criteria belong in ordinary code, which is cheaper, faster and always gives the same answer.
Errors are unacceptable and nobody reviews the output. A model that is right most of the time is a poor fit for unsupervised financial, legal or medical decisions.
The answer must be exact and reproducible. Use a database query or a calculation. A model can help phrase the question; it should not do the arithmetic.
There is no data to ground it. An assistant with nothing to retrieve will produce fluent guesses.
Usage cost exceeds the value of the task. Every request has a price. Some features do not earn it.
Plain search or a better form would solve it. Many “chatbot” requests are really a findability problem.

We cover this decision more fully in how to build an AI product.

The process

Prove quality first.
Then build the product.

AI work carries a risk ordinary software does not: nobody knows how good the output will be on your data until it is tried. The process is arranged to find that out cheaply.

How we work in detail ↗

Task and data review · 1–2 weeks

We define the task, collect real examples with expected results, review data sources and access, and agree what “good enough” means as a number. Output: a success metric, an initial evaluation set, a privacy and permissions note, and a prototype scope.

Prototype and evaluation · 2–4 weeks

A working prototype on your data, scored against the evaluation set for quality, latency and cost per request. It ends in a plain recommendation: proceed, narrow the task, or stop. Stopping is a legitimate and inexpensive outcome.

Production build · 4–12 weeks

Retrieval pipeline or tool integrations, permissions, interface, streaming responses, error handling, fallbacks, logging, cost limits and human review steps. Delivered in working increments on a staging environment with a fixed scope.

Launch and monitoring · 1–2 weeks

Gradual rollout, feedback capture, dashboards for quality, latency and spend, and handover of code, prompts, evaluation sets and documentation. Models and usage change over time, so ongoing tuning is scoped separately.

Technology approach

Ordinary engineering around an unusual component.

A language model is a probabilistic component inside a deterministic system. Most of the work, and most of the reliability, comes from the ordinary software around it.

Layer	Typical choice	Why
Models	Hosted APIs (Anthropic, OpenAI) or open-weight models via an inference provider	No infrastructure to run; chosen per task by evaluation, not by brand
Provider abstraction	A thin internal interface	Swap or mix models as prices and quality change, without rewriting the product
Retrieval	PostgreSQL with vector search, combined with keyword search	One database to operate; hybrid search handles names, codes and exact terms that embeddings miss
Orchestration	Node.js / TypeScript, plain code over heavy frameworks	Easier to debug, test and hand over
Agent tools	Typed functions with validated inputs and scoped credentials	The model proposes; your code checks and executes
Output control	Structured outputs validated against a schema	Downstream code never parses free text
Evaluation	Versioned test sets, automated scoring, human spot checks	Every prompt or model change is measured before release
Interface	React / Next.js with streamed responses	Perceived speed matters as much as actual latency
Cost control	Caching, model routing, per-user and per-tenant limits, spend alerts	No surprise invoices from the provider

We decide between prompting, retrieval and fine-tuning case by case; for most business tasks the first two are enough. The reasoning is set out in our guide to integrating an LLM into a product.

Pricing factors

Two budgets: the build, and the meter.

AI features have a build cost like any software, plus a running cost that scales with use. Both should be estimated before committing.

What moves the build cost

Data preparation. Clean, well-structured documents are quick to index. Scanned PDFs, inconsistent spreadsheets and several source systems are not.
Permissions. If different users may see different documents, retrieval has to enforce that, and it has to be tested.
Number of tools and integrations. Each system an agent reads from or writes to is an integration with its own failure modes.
Accuracy bar. Moving from “usually helpful” to “reliably correct on this narrow task” is where evaluation effort goes.
Interface. A feature inside an existing screen is much less work than a full conversational product with history, feedback and an admin view.

What moves the running cost

Model size, the length of the context sent with each request, and the number of model calls per task (agents make many)
Request volume, and how much can be cached or handled by a smaller model

We quote the prototype and the production build as separate fixed scopes, and estimate the running cost per request during the prototype so you can check the unit economics. See what it costs to add AI features for the method.

Common mistakes

Where AI projects go wrong.

Starting from the technology

“We need an AI strategy” produces chatbots nobody uses. “Support agents spend two hours a day searching old tickets” produces a feature with a measurable result. Begin with a task, a user and a number.

Shipping the demo

A prototype that impresses on five hand-picked examples says little about the five hundred real ones. Without an evaluation set there is no way to know whether a prompt change made things better or worse.

Giving an agent too much room

Agents are most dependable on narrow, well-defined tasks with a small number of tools and a clear stopping condition. Open-ended autonomy across many systems multiplies both cost and the ways it can fail. Widen the scope only when measurements justify it.

Fine-tuning first

Fine-tuning is rarely the first answer. It does not reliably teach a model new facts, it adds a training and maintenance cycle, and better prompting with retrieval usually gets further for less.

Ignoring the running cost

A feature that costs a few cents per use is fine at a hundred uses a day and a budget problem at a hundred thousand, particularly on a flat-price plan. Estimate cost per request early and design limits in.

No human in the loop where it matters

Sending an email, issuing a refund or changing a customer record should be proposed by the system and approved by a person until the measured error rate justifies removing that step.

Fit

When BBR is the right team,
and when it is not.

We are product engineers who integrate AI, not an ML research lab. For most business applications that is the skill set the project needs; for some it is not.

Good fit

We are likely a strong match if

You have a specific task and real examples of inputs and good outputs
The feature can be built on hosted language models with your data and APIs
You want the whole product built: backend, interface, permissions, billing, not only prompts
You are willing to run a short prototype and accept its verdict
You want the code, prompts and evaluation sets handed over and owned by you

Not a fit

We will probably point you elsewhere if

You need a custom model trained from scratch, or original ML research
The core problem is computer vision, forecasting or recommendation at scale
The system must make unsupervised safety-critical, medical or legal decisions
You need models hosted entirely on your own hardware with a dedicated MLOps team
The goal is to say the product “has AI”, with no task or metric behind it

Why outsource AI development

The model is the small part.

Calling a model API takes an afternoon. Making the result dependable takes retrieval that finds the right passages, permissions that hold, outputs that validate, an evaluation process, cost controls, and an interface that handles slow and wrong answers gracefully. That is full-stack product engineering with one unfamiliar component, and it is hard to hire for a single feature.

Working with a studio gives you that mix for the length of the project, at a fixed price per stage, without building a permanent AI team before you know the feature is worth having. If it proves its value, the handover includes everything your own engineers need to continue: code, prompts, test sets and documentation. If you expect ongoing tuning and new AI features every month, that fits our product engineering model.

BBR also builds its own products. Nora, an AI companion app, is in development in our studio, and Grow.io shipped with computer-controlled opponents built as conventional game AI. The second example is a useful reminder that plenty of “AI” behaviour is better served by ordinary code than by a language model.

Questions

Frequently asked
questions.

Do you train your own AI models?

No. BBR integrates hosted models from providers such as Anthropic and OpenAI, and open-weight models served through APIs, then builds the retrieval, tools, evaluation, guardrails and product around them. We do not train foundation models or carry out bespoke machine-learning research. For most product features, a well-integrated hosted model is the faster, cheaper and better-performing route.

Can AI connect to our internal tools and data?

Yes, where those tools provide suitable APIs or data access. Before building we define which data the system may read, which actions it may take, whose permissions it acts under and which actions need human approval. Connections to business systems overlap with our API integration work.

Is our data used to train the model?

That depends on the provider and the contract tier, so it has to be checked against the provider’s current terms, not assumed. The major providers offer business API terms under which customer inputs are not used for training by default, along with data retention options. We help you choose a provider and configuration that match your obligations, and we document what is sent where.

How much does it cost to add AI to a product?

There are two costs: the build, and the running cost, which is billed by the model provider per token and scales with usage. A narrow feature such as summarisation or extraction is a few weeks of work. A retrieval-based assistant or an agent that acts in other systems is more. The AI integration cost guide explains both sides with a worked formula.

How do you deal with hallucinations and wrong answers?

By designing for them. We ground answers in retrieved sources and show citations, constrain output formats, validate outputs in code, give the model a way to say it does not know, and keep a human approval step for consequential actions. Most importantly we build an evaluation set of real examples and measure quality against it before launch and after every change. Error rates can be reduced and measured; they cannot be promised away.

How long does an AI project take?

A prototype that answers the question “is this good enough to be useful?” usually takes 2 to 4 weeks. Turning a successful prototype into a production feature typically takes a further 4 to 12 weeks depending on integrations, permissions and interface work. We recommend the prototype stage in almost every case, because quality on your data cannot be predicted from a demo on someone else’s.

Which model or provider should we use?

The one that passes your evaluation set at the lowest cost and latency, under data terms you can accept. We build behind a thin abstraction so that the model can be swapped, and we often use a smaller model for routine steps and a larger one only where it is needed. Our LLM integration guide covers the decision in detail.

Your next move

Have a task AI might handle?
Let’s test it honestly.

Describe the task, the data behind it and what a good result looks like. We reply with questions, a view on whether AI suits it, and a proposed prototype scope.