You provision an API key, write a system prompt, and receive a remarkably fluent response. For a moment, it feels like you have deployed a finished product. Then you ask a follow-up question, and the model has completely forgotten the context. You ask it to update a customer record, and it confidently fabricates a success message while touching exactly zero databases.
This initial friction comes from a category error: treating a language model as a complete software solution rather than a raw computational component.
An LLM is fundamentally stateless. On its own, it predicts the next most likely token based on its training weights and the text in its context window. It has no persistent memory, no concept of time, and no native agency. It cannot verify its own logic. It cannot natively execute code, trigger webhooks, or read your internal documentation.
When you call a raw model API, you are interacting with a bare reasoning engine. Every function that makes a model useful in production is a layer of software wrapped around it. If you want it to remember user preferences, you build the state management that injects history into every request. If you want it to answer questions about proprietary data, you build the retrieval pipeline. If you want it to take action in the real world, you expose strict tools, parse the model’s output, and execute the requests on its behalf.
Moving from a script that calls an endpoint to a reliable agentic system requires extensive structural scaffolding. Before designing that architecture, it helps to understand how the core component processes text, counts tokens, and produces structured data.
- From LLMs to agents: the complete journey — the shape of the whole climb, from raw model to system.
- Working with LLM APIs: first calls, tokens, and structured output — how the component actually behaves when you call it.