Skip to content

Custom Software

AI-native applications: the task decides how the AI shows up

AI can appear in an application in different ways: a suggestion inside a form, a tool you aim, a conversation, or work handed off and checked later. Each gives people a different kind of control. Choosing by fashion, usually a chat box, puts the wrong kind of control on the task. We choose by the task, then build the state, checks and history around it.
Write up a finished joba suggestion in the formyou keep: every word, before it's savedFind a past job like this onea tool you aimyou keep: the filters, and which resultCheck what a warranty coversa conversation, with its sourceyou keep: the source, to checkSort the overnight requestswork handed off, then checkedyou keep: anything it wasn't sure ofwork doneReplaced ignitor IGN-4, cleaned flame sensorAcceptEditno heat · 2009 furnaceEastsidelast 3 yearsJ-312 · ignitorJ-288 · flame sensorJ-401 · control boardIs the ignitor covered after 6 years?Parts are covered for 10 yearsif the unit was registered.Manufacturer A terms · section 49 sorted into today's queue2 held for you

Four ways AI can show up

Each one fits some tasks and not others. Most applications use more than one.
A suggestionthe person is already doing the taskthe final say on every word
A toolthe person knows what they're looking forthe aim: filters, scope and which result
A conversationthe question is open and good sources existthe sources, to check
Delegated workthere are many small items, each low-riskreview of anything it was unsure of, and an undo

What's built around the model

The model is one part. These are the parts that make it dependable.
  1. 01

    State

    The application knows where things are

    Jobs, requests and their states live in the application's records, not in the model's memory.

  2. 02

    Checks

    Before anything is used

    Outputs are checked against your records: the part is on the truck, the code is in the catalogue.

  3. 03

    Fallback

    The task still gets done

    When the model is unsure or unavailable, the person does the task by hand with nothing lost.

  4. 04

    History

    Suggested, and chosen

    What the model proposed and what the person decided are both kept.

  5. 05

    Evaluation

    Tested before every change

    A fixed set of your own examples is run before a prompt or model changes.

When it goes wrong

It will. The design decides what the person sees and whether the work carries on.

Not sure

What happens
an overnight request, “noise from the unit, and a smell?”, can't be sorted with confidence
The person sees
it under “held for you”, with the reason
The task
sorted by the office first thing
Kept
the request, the model's guess and the final choice

What an AI-native application hands off

In

The task
and who's doing it
Records
jobs, parts, terms
Model output
a proposal, never final
AI-native application
shown, checked, decided

Out

Work done
with the person's decision
Checks
kept with every output
Examples
for the next evaluation

Worth building when AI changes how the task is done

Good fit

  • A task means reading, writing or sorting language, a lot of it.
  • Outputs can be checked against your records.
  • People need to stay in control of the result.

Not the right fit

  • A rule can do it reliably. Use the rule.
  • Nobody can check the output, and mistakes are costly.

Questions about AI-native applications

Why not just add a chat assistant?

Chat suits open questions. For a structured task, a suggestion or a tool gives people more control with less typing.

Which model do you use?

Whichever fits the task, chosen by testing on your examples. The application is built so the model can be changed.

What happens when the model is wrong?

Its output is checked against your records before it's used, people confirm anything that matters, and every suggestion and decision is kept.

Is our data used to train the model?

We choose providers and settings that keep your data out of training, and send only what each task needs.