ShopEasy’s support chatbot can answer “Where is my order?” by calling a backend function such as lookup_order, then turning the result into a helpful sentence the user can read.
A simple way to say what an Large Language Model (LLM) is, in this course, is that an LLM takes text we send in and predicts the next text to send back, like a very powerful autocomplete that can produce whole paragraphs.
Even in that one order question, ShopEasy already has a few distinct inputs. The system prompt is the private instruction ShopEasy sends with every request, for example “You are ShopEasy Support. Be concise. Ask for an order number if missing.” The conversation history is the running transcript of earlier turns that ShopEasy includes so the model can stay consistent. The user input is the new message, such as “Where is my order?” Tools are server-side functions ShopEasy can run, like lookup_order and request_refund, when the chatbot needs data or needs to perform an action.
Once ShopEasy has those parts, one request follows a repeatable loop. A user message arrives at the ShopEasy API, and the application assembles one prompt for the model by concatenating the system prompt, the conversation history, and the new user input. The application sends that prompt to an LLM provider, and the provider returns a model output that is either a direct text reply or a proposed tool call with arguments.
When the model proposes a tool call, ShopEasy application code decides whether to run it, then executes a concrete function such as lookup_order to fetch shipping status or request_refund to start a refund. ShopEasy then sends the tool result back to the model as another message so the model can write the final user-facing reply, and only that final reply goes back to the user. One detail matters for security and debugging later. The model has no built-in memory between calls, so ShopEasy must resend the conversation history every time or the model responds as if it has never seen the user before. Let’s pin this loop down in one request-path diagram.
This diagram makes the trust boundary visible. The user input is untrusted because any caller can type arbitrary text, and tool results are untrusted because a tool can return surprising content that still gets fed back into the model.
The important safety implication of the loop is that the model does not read the database, issue refunds, or enforce policies. The model only generates text that suggests what to do next, and ShopEasy application code is the component that actually performs actions and returns data through tools.
That separation only stays clear if we keep three identities distinct. The end user is the customer asking about an order, and the end user’s permissions should limit which orders they can see and what actions they can request. The ShopEasy service is our backend itself, which holds broader capabilities like database access and the ability to run request_refund. The LLM provider credential is the API key or service token ShopEasy uses to call the model endpoint, and that credential authorizes only model usage, not customer actions. Mixing these identities creates failures where the backend spends money, reveals data, or performs actions on behalf of a user who should not be able to trigger them. If something goes wrong, which part can truly enforce rules, prompt text, the LLM, or ShopEasy application code.