Building Applications with Foundation Models

A Foundation Model is one component inside an application, and the application surrounds it with the logic that defines the task.

Programming

Why the Model Is Not the Whole Application

Suppose you use a chat-style tool that answers questions. It is tempting to think the answer comes entirely from one component, the Foundation Model, and that the rest of the software is just a thin window for typing. That view leaves out most of what makes the system work. A Foundation Model is one component inside an application. The application surrounds it with the logic that defines the task: it decides what the model is used for, what input the model receives, and what happens to the result afterward.

This article follows one request from start to finish. You will see where the model fits on that path, which responsibilities belong to the application around it, and why confusing the two makes systems harder to build and to fix.

Following One Request Through the System

What do you think happens?

If a user asks an application a question, which part of the system should be responsible for turning that question into something the model can use?

Reveal answer

Answer:

The application. It prepares the input before the model is called.

The source describes a path that runs from the user to the application, then to the model, and back through the application before the user sees a result. The application handles input preparation and output shaping.

Here is the path a request takes. Read it as a sequence: each step hands the request to the next part of the system, and the response travels back along the same route.

What happens to a user's request, step by step, from the moment it arrives until the response is returned, and where does the model fit in that path?

Count the steps and notice what is missing from the middle. The model is involved in only one of these six steps. Most of the work that makes the system useful happens before the model is called and after it returns. The application is responsible for the full path from the user's words to the user's screen, not just the model call in the middle of it.

Splitting Responsibilities Between Model and Application

Definition

A Foundation Model is one component inside an application, and the application surrounds it with the logic that defines the task.

The model provides a capability that the application can use. The model itself offers the raw capability. The application decides what that capability is used for, what input it receives, and what happens to the result. Keeping these two roles separate tells you where to look when something goes wrong or needs improvement.

What does the application contain, and where does the Foundation Model sit within that structure?

The table below sorts common questions into the two areas. The source gives the distinction directly: a question about what the user asked, how the request was prepared, or how the answer is shown is a question about the application. A question about the raw capability the model offers is a question about the model.

Question you are asking	Where it belongs	Why
What did the user actually ask?	Application	The request arrives at the application first.
How was the request prepared before the model saw it?	Application	Input preparation is part of the application's work.
How is the answer displayed to the user?	Application	Output shaping happens after the model returns.
What raw capability does the model offer?	Model	This is the capability the application uses.

Sorting questions between the application and the model

A Stand-In Model Sketch

The sketch below replaces a real Foundation Model with a stand-in function. This is deliberate: the goal is to show the division of responsibilities in code, not to call a real model. One function represents the model call, and a second function represents the application logic that wraps it. The values used are invented for this example.

Code walkthrough

def foundation_model(prompt):
    # Stand-in for the model call: it only echoes the prompt it receives.
    return "Stub reply for: " + prompt

def answer_question(user_text):
    # Application: input preparation
    cleaned = user_text.strip()
    prompt = "Answer briefly: " + cleaned

    # Model: the single model step
    raw = foundation_model(prompt)

    # Application: output shaping
    return "Answer: " + raw.strip()

print(answer_question("   What is a model?   "))

1
foundation_model receives a prompt and returns a stand-in reply; it is the only function that represents the model.
2
answer_question receives the raw user text, which still has extra spaces at both ends.
3
The application trims the spaces and adds an instruction, so the model receives a prepared prompt rather than the raw text.
4
The model call happens once, in the middle of the function.
5
The application shapes the returned text by adding the prefix Answer: before returning it to the user.

foundation_model stands in for the model call
answer_question is the application logic around it
strip() cleans the user's text before the model sees it

Output

Answer: Stub reply for: Answer briefly: What is a model?

Output

Answer: Stub reply for: Answer briefly: What is a model?

Notice what the model function does not do. It does not clean the spaces, decide the instruction wording, or add the Answer label. Those decisions all sit in answer_question. If you wanted to change how the reply looks, you would edit the application function and leave the model call untouched.

Why the Model-Only View Misleads

A model-only view draws the system as a question going directly into the model and an answer coming straight out. The full application view inserts the application's work before and after the model call. The diagram below compares the two views.

What is the difference between a model-only view of a system and the full application view, and what gets missed in the model-only view?

The model-only view hides the two steps that do most of the practical work. Input preparation decides what the model is actually given. Output shaping decides what the user actually sees. When you lose sight of them, you may blame the model for problems that were introduced, or could have been fixed, in the application.

Common mistake
Treating the model as the entire application
What it looks like
Judging a whole system's behavior only by the raw model call, while ignoring how the request was prepared.
Why it fails
The source says the model is involved in only one of the six steps, and most of the work happens before and after it.
Do this instead
Trace the full path from the user's words to the user's screen and assign each step to the application or the model.
Common mistake
Looking in the wrong place when output looks wrong
What it looks like
Rewriting model settings when the answer is correct but displayed with the wrong label or formatting.
Why it fails
How the answer is shown to the user is a question about the application, not the model.
Do this instead
Check output shaping in the application code first.
Common mistake
Putting task-defining logic inside the model call instead of the surrounding application code
Common mistake
Forgetting that the application decides what input the model receives

Debugging by Tracing the Request

When something goes wrong, the source recommends tracing the request step by step to decide whether the issue lies in the application or in the model. Walk the path in order and ask at each step what went in and what came out.

Debugging

Suppose a user reports that an answer is wrong. Trace the path. Did the application receive the correct question? Did input preparation change the meaning of the question? Did the model receive a sensible prompt? Did the returned text get altered during output shaping? Only after confirming the prompt was correct and the raw reply was wrong is the model the likely source of the problem. Checking the application first is a practical habit, because most of the path belongs to the application.

Practice Tracing a Request

EASY

A user types a question into an application that uses a Foundation Model. The application trims extra spaces, adds an instruction, calls the model, and then adds a label to the reply before showing it. Name each step, mark which steps belong to the application and which to the model, and say where you would look first if the displayed answer had a wrong label.

Hints

Count how many steps involve the model. The source says it is only one of six in its trace.
Input preparation and output shaping both belong to the application.
A wrong label is a question about how the answer is shown to the user.

Your attempt (not saved)

Key Takeaways

A Foundation Model is one component inside an application; the application surrounds it with the logic that defines the task.
A request travels from the user to the application, then to the model, and back through the application before the user sees a result.
The model is involved in only one step of that path; input preparation and output shaping belong to the application and account for most of the work.
When something goes wrong, trace the request step by step to decide whether the issue lies in the application or in the model.
Treating the model as the entire application hides the steps where most of the useful work happens.

More concepts starting with B