Explain the LLM vs runtime split in an agent and why the distinction matters for debugging

Every agent has two parts that people often blur together: the **brain** and the harness around it. The brain is the LLM. The harness is the runtime, which is plain code you wrote or imported. The LLM's only job is to think and produce text. Given the conversation so far, it decides what to do next and writes that decision out, either as a final answer or as a tool-call request. Crucially, it cannot actually run anything. When the model emits a tool call, it is just producing characters that describe a call. It has not searched the web or read a file. The runtime does everything physical. It reads the model's text, finds the tool-call request, validates the arguments, runs the real function, and catches any error. Then it takes the result and writes it back into the context so the model can see it on the next turn. This split matters most when something breaks. If a tool returns garbage, the model may not be at fault. The runtime might have passed bad arguments or swallowed an exception. Knowing which side owns the failure tells you where to look.

An agent is an **LLM** wrapped in a runtime, and the two have sharply different jobs. The LLM is the decision maker. The runtime is the execution layer. The LLM reads the current context and produces text. That text is either a final answer or a structured tool-call object naming a tool and its arguments. The model cannot invoke a function, open a socket, or read a file. A tool call in the model's output is a request, not an action. The runtime closes the gap to the real world. It parses the model's output, validates the arguments against the tool schema, executes the actual function, and catches errors. It then injects the result back into context, which is the step that closes the loop. The runtime also owns stopping conditions, retries, and budgets. The split matters because it tells you where a bug lives. If the agent picked a wrong tool, that is a model or prompt problem. If the tool ran but got bad inputs, that is a runtime parsing problem. A common trap is assuming the model executed something. It only emitted text. The runtime may have silently failed to parse it, so nothing ran at all.