Introduction to Foundation Models
A Foundation Model is one component inside an application, and the application surrounds it with the logic that defines the task.
A Question Enters the System
Imagine a user types a question into an application that uses a Foundation Model. Within moments, an answer appears on the screen. It is tempting to think the model received the question and produced the answer on its own. That picture leaves out most of what happened. The request was accepted, prepared, sent onward, and then its result was reshaped before the user saw it.
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
The application. It is responsible for preparing the user's words into an input the model can use.
The model provides a capability, but the surrounding application decides what input that capability receives. Preparing the question is part of the application's job, which is why the application, not the model, owns this step.
The Model as One Component
A Foundation Model is one component inside an application, and the application surrounds it with the logic that defines the task. The model is not the application itself. When someone builds an application around a Foundation Model, the model supplies a capability that the application can use. The surrounding application decides what that capability is used for, what input it receives, and what happens to the result.
The diagram shows the model as one box among several. The application wraps it. The task logic decides what the model is asked to do, while the interface, input preparation, and output shaping handle the parts of the system that face the user and surround the model call.
Tracing a Request Through the Application
A request passes from the user to the application, then to the model, and back through the application before the user sees a result. Tracing this path step by step is the most useful way to understand the system. The sequence below follows one request through the three actors involved.
Read the diagram as a conversation with three participants. The user speaks only to the application. The application speaks to the model, but only after it has prepared the input. When the model answers, the result comes back to the application rather than straight to the user. The application then decides how that result is presented.
A Small Application Around a Stand-In Model
The code below uses a stand-in function in place of a real Foundation Model. The purpose is not to build a working model but to show the division of responsibilities in code. One function represents the model call. A second function represents the application logic that wraps it. The values used here are invented for this example.
def stand_in_model(prompt):
# Stands in for the model call; takes a prepared prompt, returns raw text
return "[model output for: " + prompt + "]"
def application_answer(user_text):
cleaned = user_text.strip() # input preparation
prompt = "Answer briefly: " + cleaned # task logic shapes the request
raw = stand_in_model(prompt) # the only model call
return "Answer -> " + raw # output shaping
print(application_answer(" what is a foundation model? "))- 1
stand_in_modelreceives a prompt and returns raw text. It knows nothing about the user's original message formatting. - 2
application_answerstrips the extra spaces from the user's text. This is input preparation, and it happens before the model is involved. - 3The application adds the instruction 'Answer briefly:' to the cleaned text. This is the task logic deciding what the model is asked to do.
- 4The single call to
stand_in_modelis the only point where the model participates. - 5The application wraps the raw result before returning it. This is output shaping, which happens after the model returns.
stand_in_modelplays the role of the model: it is called once, with a prepared promptapplication_answerholds the surrounding logic: cleaning, prompt construction, and presentation
Answer -> [model output for: Answer briefly: what is a foundation model?]Notice how much of application_answer has nothing to do with the model. Cleaning the input, deciding the instruction, and shaping the output are all application work. If the model were replaced with a different one, most of this code would stay the same. That is the practical benefit of keeping the model as one component.
Responsibilities Outside the Model
Keeping the model and the application distinct changes where you look when something goes wrong or needs improvement. 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 might ask | Where to look | Why |
|---|---|---|
| What did the user actually type? | Application | The request enters through the application |
| Was the question prepared well for the model? | Application | Input preparation belongs to the application |
| Is the answer shown clearly to the user? | Application | Output shaping and presentation belong to the application |
| What raw capability does the model offer? | Model | This is the model's own capability |
Locating a problem by responsibility
When something goes wrong, trace the request step by step to decide whether the issue lies in the application or in the model. The trace tells you which hop of the path is responsible. A poor answer caused by an unclear prepared input points to the application. An answer that fails even with a well-prepared input points toward the model's capability.
Mistakes Beginners Make With the Model-Only View
Common mistake Treating the model as the entire application
What it looks likeDescribing a question-answering product as just 'the model answers questions'.
Why it failsThe model is one component inside a larger application. The application handles input preparation, task logic, and output shaping, which together account for most of the path a request takes.
Do this insteadDescribe the full path: user, application, model, and back through the application to the user.
Common mistake Looking for a bug in the model when the input was poorly prepared
What it looks likeBlaming the model for a confusing answer when the application passed in unclear or unformatted text.
Why it failsA question about how the request was prepared is a question about the application, not the model.
Do this insteadTrace the request to see whether the prepared input was sound before concluding the model is at fault.
Common mistake Ignoring the return trip, so output shaping seems unimportant
Common mistake Assuming the user sees the model's raw result directly
Model-only view: user -> model -> user
The application's preparation and presentation steps are invisible.
Full application view: user -> application -> model -> application -> user
Every responsibility outside the model is visible and can be located.
Building Applications With Foundation Models
This section is about building applications with Foundation Models, which means working with both parts and understanding how they connect. The model provides the capability. The application defines the task, prepares what goes in, and shapes what comes out. Building well means taking ownership of the full path from the user's words to the user's screen, not only the model call in the middle.
Choose a feature you could add to an application that uses a Foundation Model, such as summarizing a document the user uploads. For each step between the user's action and the final display, decide whether it belongs to the application or the model. Which steps are yours to design, and which step is the model call?
Hints
- Start from the user's action and follow the request through the application.
- Ask whether each step deals with the raw capability of the model or with the task around it.
- Most steps should belong to the application.
Key Takeaways
- A Foundation Model is one component inside an application, and the application surrounds it with the logic that defines the task.
- A request passes 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, which together account for most of the path a request takes.
- 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 most of the system's responsibilities.