Skip to content
CAPSOLTECHNOLOGIES
MenuClose
06Service line

AI features & automation

LLM features inside products, and automation of the workflows around them. Narrow, evaluated, and honest about what it cannot do.

At a glance
Disciplines
Engineering · Design · Quality
Stages
5 in sequence
Duration
Quoted after scoping
AFraming

Narrow beats impressive.

The useful version of this work is specific: one task, in one product, done faster or done at all. Retrieval over your own documents. An assistant that actually knows your data instead of guessing at it. A support queue that classifies and routes itself.

We do not train or fine-tune models. What we build is the product around one — the retrieval, the prompts, the evaluation, the permissions, the cost controls, the failure handling and the interface. That is where nearly all of the work and nearly all of the risk actually sits, and it is ordinary product engineering wearing a new hat.

BScope

What is in scope

LLM features in products
Chat and assistant interfaces, retrieval over your own documents and data, summarisation and extraction — built as features with states and edge cases, not as demos.
AI integration
Wiring model APIs into an existing product and its data, with cost, latency and rate limits treated as design constraints rather than surprises.
Workflow automation
Document processing, classification, routing and back-office work that currently costs somebody a morning every day.
Prompt and evaluation work
Prompts kept in version control with a test set behind them, so a change can be measured instead of argued about.
Failure and fallback design
What the product does when the model is wrong, slow, or down — which it will be. Designed up front, not patched after the first incident.
CSequence

The order the work runs in

Stages, not a schedule. We do not publish durations we have not agreed with you — the sequence is fixed, the length depends on what we find in scoping.

  1. 01

    Find the task

    One specific job, narrow enough that we can tell whether it worked. Vague AI briefs produce impressive demos and nothing shippable.

  2. 02

    Evaluation set

    Real examples with known-good answers, agreed before anything is built. Without one there is no way to know whether a change helped or just felt better.

  3. 03

    Prototype

    The narrowest thing that produces a real signal, scored against that set.

  4. 04

    Build

    The product around the model: retrieval, interface, permissions, cost controls and fallbacks.

  5. 05

    Measure and tune

    Against the same set, in the open — including the run where the honest answer is that it is not good enough yet.

DDeliverables

What you have at the end

  • A written evaluation set, and the measured results against it
  • The feature, in your product, with cost and latency instrumented
  • Prompts and retrieval logic in version control, not pasted into a console
  • Fallback behaviour specified and tested
  • An honest note on what the model gets wrong, and how often
ESpecific to this line

What we will tell you not to build

Most AI briefs that reach us are a technology looking for a task. If the honest answer is that a form, a filter or a database query would do the job better and cheaper, we will say so at the start rather than eight weeks in, when it becomes obvious anyway.

We also will not quote accuracy figures we cannot reproduce on your data, and we do not train models. What we commit to is the evaluation set: agreed up front, run in the open, and shown to you whether or not the numbers flatter us.

FNext

Where to go from here

Start a project briefHow we work

Next line — 07 Growth, marketing & optimisation