Skip to content

Custom Business Software

AI applications: the model is one step, not the whole app

Most AI at work happens in a separate window: copy the details in, read the answer, copy it back, hope it's right. An AI application puts the model inside the screen where the work already happens. The model proposes. The application checks every proposal against your real records. A person confirms, and only then does anything change. We build the checks and the confirmation step first, then the model inside your screens.
Talk through where AI fitsSee three notes, three outcomes ↓
J-606 · wrap-up · T3technician's noteReplaced ignitor, cleaned flamesensor. Customer asked abouta humidifier.proposedF-112 · ignitor replacementpart IGN-4F-140 · flame sensor cleaninghumidifier · not work doneConfirmconfirmed by T3code in catalogue✓IGN-4 on Truck 3✓price from cataloguecode in catalogue✓price from catalogue→ follow-up lead2 invoice lineslead L-2291 for the officewhat the application doesnotepermissionscontextmodelcheckstechnicianrecordthe model is 1 of 7 steps

AI next to the work, not in it

When AI lives in a separate chat window, every use is a copy and paste. Nothing it says is checked against your catalogue or your stock, nobody can see what it was asked, and a confident wrong answer looks exactly like a right one.

An AI application turns that into a defined task inside your software. The application decides what the model may see, checks what it returns against your records and rules, and asks a named person to confirm anything that matters. Every step is recorded, so a bad result can be traced and fixed.

Today, and with an AI application

Today

  1. 01A technician types notes into the job, in their own words.
  2. 02The office turns notes into task codes and parts, by hand.
  3. 03Questions the customer asked get lost in the notes.
  4. 04Mistakes surface when the invoice is queried.

Invoices go out late or wrong, and leads the customer handed you are never followed up.

With an AI application

  1. 01The technician types the same note, in their own words.
  2. 02The model proposes task codes and parts from it.
  3. 03The application checks each against the catalogue and the truck's stock.
  4. 04The technician confirms; invoice lines and any follow-up lead are created.

The technician still decides. The office gets clean lines, and the customer's question becomes a lead.

Who decides what

The model is good at reading a note. It isn't trusted with anything a record can answer.
What the note describesThe modelReading free text is what it's for
Whether the code existsThe application, from the catalogueA record answers it exactly
Whether the part was on the truckThe application, from stockSame
The priceThe application, from the catalogueNever generated
What goes on the invoiceThe technicianThey did the work
What happens to a questionThe officeA person follows up a lead

Three notes, three outcomes

What the application does when the model is right, when the records disagree, and when there's nothing safe to propose.

J-606 · “Replaced ignitor, cleaned flame sensor…”

  1. Permissions checked

    T3 is assigned to J-606

    done

  2. Context assembled

    note, catalogue, Truck 3 stock

    done

  3. Model proposed 2 lines and 1 lead

    done

  4. Checks

    both codes in catalogue; IGN-4 on Truck 3

    done

  5. Technician confirmed

    T3

    done

  6. Invoice lines and lead created

    done

Two invoice lines and lead L-2291, with the note, the proposal and the checks kept on the job.

The parts it's built from

Each part is built and tested on its own, so you can start with one and add the rest.

  1. Screen

    Internal Tools

    The wrap-up screen technicians already use.

  2. Context

    AI-Native Applications

    Only the job, the catalogue and the truck's stock.

  3. Model

    LLM Application Development

    • the note
    • the catalogue
    • the truck's stock

    nothing safe to propose → the technician chooses

  4. Record

    API Services

    Invoice lines and leads written after confirmation.

Underneath every stepIdentity & Access ManagementWho can ask, see and confirm.

What changes from one business to the next

The taskWhich piece of work the model proposes, and what a good result looks like
RecordsWhat the application checks each proposal against
Who confirmsWhich person approves which results
When it stopsWhat happens when there's nothing safe to propose

A common starting point is your existing application or a Next.js app, a Postgres database, a hosted language model chosen for the task's quality, speed and cost, and a test set of real notes to measure it against. These are starting candidates, not requirements.

Is an AI application the right system?

Good fit

  • A recurring task involves reading or writing language.
  • The results can be checked against records you already keep.
  • Someone can own the task and review failures.

Avoid when

  • A fixed rule could do the job. Use the rule.
  • Nobody can say what a good result looks like yet.

How we'd approach it

Most of the early work is defining the task, the records it checks against, who confirms and when it must stop.

  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Related systems

The capabilities underneath

For your industry

Questions about AI applications

Which model do you use?

The one that does the task well enough, fast enough, at a cost that makes sense, measured on your own examples. It can be changed later without rebuilding the application.

What if the model is wrong?

The checks catch what records can answer. A person confirms the rest. Every proposal, check and correction is kept, so recurring mistakes show up and get fixed.

Does our data train the model?

It shouldn't, and we choose providers and settings so it doesn't. What the model sees is limited to what the task needs.

Can it act without a person?

Only where you decide the risk is low and the checks are enough. Most applications start with a person confirming everything, then relax it task by task with evidence.

Put AI where the work already happens

Tell us which task your team copies into an AI chat today. We'll show you how it would work inside your own system.

Start a project