Skip to content

AI Systems

LLM application development: the model proposes, the application decides

A language model can read a customer's message and suggest what to do. It can't know who's asking, which records they may change, or what your rules allow. We build that part: the context each request is given, the checks the output must pass, and the record of what happened.
Discuss your systemSee the six parts ↓
whooffice lead, EastsiderecordJ-431, Thu 10:00rulesreschedule policy v3message“Can you come Friday instead?”ModelProposalreschedule J-431to: Fri 08:00–10:00notify: customerschema✓permission✓rule: within 24 h of visitoperations managersaved · trace t-5521 · prompt v12 · 4 context items · 3 checks

A chat window doesn't know who's asking

A model can interpret a request, pull facts out of it, or draft an answer. A business application also has to know who is asking, which records they may see, what actions are allowed, and what happens when the model's answer is unusable. Those responsibilities decide whether an AI feature can support real work.

So the model gets a bounded job inside software that owns everything else. The application assembles the context, the model proposes, and the application checks the proposal against its own rules before anything changes.

A wrapper, or an application

A chat wrapper

  1. 01Sees only what someone pastes into it.
  2. 02Can't tell an office lead from a customer.
  3. 03Answers in prose that someone has to retype.
  4. 04Can suggest anything, including what your rules forbid.
  5. 05Leaves no record of why it said what it said.

The answer sounds right, and nobody can check it.

An application around the model

  1. 01Is given the records and rules this request needs, and nothing more.
  2. 02Knows the user's role and applies their permissions.
  3. 03Returns fields that software can check and use.
  4. 04Proposes; your rules and your people decide what happens.
  5. 05Keeps a trace: prompt version, context, output, checks.

Same model. The difference is everything around it.

Six things the model can't supply

Every LLM feature we build answers these before a prompt is written.

  1. 01

    Task

    What exactly is it for?

    One bounded job, and what a wrong answer would cost. That cost sets how much checking and review the feature needs.

  2. 02

    Context

    What does it see?

    Assembled for each request from the records and sources this user may access. More context isn't better; the right context is.

  3. 03

    Output shape

    What comes back?

    Named fields with types, so software can validate the result instead of parsing prose.

  4. 04

    Checks

    What must be true?

    Schema, permissions and business rules, applied before anything is saved or sent.

  5. 05

    Fallback

    What if it can't?

    A person, a safe default, or a plain “I can't do that”, decided in advance, not improvised.

  6. 06

    Trace

    What happened?

    The prompt version, the context it saw, what it returned and what the checks decided, kept for review and testing.

Every answer leaves a trace

Trace t-5521

request
“Can you come Friday instead?” (SMS)
user
office lead, Eastside
model
provider model, pinned version
prompt
reschedule-assist v12
context
J-431, reschedule policy v3, calendar Fri
output
reschedule J-431 → Fri 08:00–10:00, notify customer
checks
schema ✓ · permission ✓ · 24 h rule → approval
decision
sent to operations manager, approved 09:12

When an answer is wrong, the trace shows why: the wrong record in context, an old prompt version, a rule that didn't fire. Without it, all you can do is try the prompt again and hope.

Traces are also where test cases come from. A reviewed mistake becomes a case the next prompt or model version has to pass.

What an LLM application hands off

In

Request
message, form or event
User
role and permissions
Records
only what's permitted
Model call
context → proposal → checks

Out

Validated result
fields software can use
Action or approval
per your rules
Trace
for review and testing

Worth building when language meets your records

Good fit

  • The input is language: messages, notes, emails, documents.
  • The result has to land in a system with records, roles and rules.
  • A wrong answer would cost something, so it has to be checked.

Not the right fit

  • The task can be written as ordinary rules. A rule is cheaper, faster and never surprising.
  • An existing product already does the job within your access rules.

Where it's built in

Next to LLM application development

Questions about LLM application development

Which model do you use?

The one that passes your task's test cases at an acceptable cost and speed. We keep the provider behind an adapter, so a newer or cheaper model can replace it once it passes the same tests.

Isn't this just prompt engineering?

The prompt is one part. Most of the work is ordinary software: assembling the right context, defining the output, checking it, deciding the fallback and keeping the trace.

Can it use our data without training a model on it?

Yes. Records and documents are given to the model as context for each request, within the user's permissions. We don't fine-tune by default; it's an option when testing shows prompting and retrieval aren't enough.

What happens when the model gets it wrong?

The checks catch what they can: a wrong shape, a forbidden action, a broken rule. Review catches more where the consequence warrants it. Each reviewed mistake becomes a test case, so the next version is checked against it.