Solutions

AI inside the product, only where it changes the outcome.

Language-model features built into the system you already run. With measured evaluation, written boundaries, and a person accountable for what comes out.

When it makes sense

Problems where a model contributes something real.

The useful question is not "where do we add AI?" but where reading and sorting work is eating hours today:

  • Someone reads, classifies and forwards the same kind of message dozens of times a day.
  • There is a document archive nobody uses because you cannot search it by what it says.
  • Data arrives in documents of varying formats and gets typed in by hand.
  • Support answers the same questions with information that is already written down.
  • The same kind of document gets drafted over and over, with a few fields changed.
  • An internal knowledge base exists and nobody uses it, because finding something costs more than asking.

What we build

Features, not an AI product.

  • Search over your own documents

    Retrieval with context over company information, citing the source document so the answer can be verified.

  • Structured extraction

    Turning invoices, contracts, forms or emails into structured fields, ready to enter the system.

  • Classification and routing

    Sorting incoming items by type, priority or owning team, with a confidence threshold and an exit to human review.

  • Scoped assistants

    Conversation limited to one domain and a defined set of sources, with what it may and may not answer written down.

  • Drafts with review

    Generating the first version of a document or reply, which a person approves before it goes out.

  • Evaluation

    A set of cases with expected answers, run on every change. Without it, "it got better" is an opinion.

How it is built

Rules we do not trade away to ship sooner.

Rules we do not trade away to ship sooner.

An AI feature is easy to demo and hard to sustain: what looks brilliant in a trial fails in production in ways nobody anticipated, on a real client’s data. These rules exist so the gap between the demo and the operation is not something the client discovers.

  • No decision with consequences for a person is made without human review.
  • Evaluation against real cases before launch and after every model change.
  • Traceability: what was asked, with what context, and what the model returned.
  • Client data does not feed third-party training without a written agreement.
  • Cost per operation measured from day one, not discovered on the first invoice.
  • The model provider is replaceable: it sits behind an interface of our own.
  • LLM
  • RAG
  • Embeddings
  • Google Cloud
  • Firebase

How it is delivered

From use case to operation.

  1. Use case

    Which specific task, who does it today, and how we will know the system does it better.

  2. Proof of concept

    With the client’s real data, not with a demo example.

  3. Evaluation

    Cases with expected answers and a threshold agreed before going further.

  4. Integration

    Inside the system already running, with permissions, limits and logging.

  5. Operation

    Quality and cost tracking, and a review whenever the model changes.

Two things are worth separating. We have used generative AI inside our own delivery process for some time, and that part is demonstrable: it shows up in our timelines. As a product line for clients, it is a declared capability with no published case yet. If what you need is a vendor with years of AI systems in production, that is not us today, and we would rather say so here.

Is there one concrete task worth testing?

Tell us which one and who does it today. If it adds nothing, we will say that too.