LLM Systems

What 'Agentic' Actually Means

When an LLM 'calls a tool,' it never touches a filesystem, a network socket, or an API. It writes one blob of structured JSON and stops. Everything you'd call 'agentic' happens in the code around it. Walk the real request/response cycle, one message at a time.

agentstool-usefunction-callingllm-systems

LiveInteractive · drag, toggle, run it

LLM Systems

What “Agentic” Actually Means

Ask an LLM to check the weather and something in your head pictures it reaching out and querying an API. It never does. Its entire contribution is one blob of JSON describing which function to call and with what arguments, and then it stops and waits. The rest, running the function, sending the answer back, deciding to try again, is five plain messages bouncing between the model and the code that hosts it. Step through the exact cycle below, one real Messages API payload at a time.

“Agentic” is not new model tech. It's a label for a loop wrapped around an ordinary model call: look at the conversation so far, decide on one action, get a result, decide the next action, repeat until there's nothing left to do. The model was already capable of the “decide” part. What changed is that people started writing the loop.

step 1 of 5

You

You send a question, plus a tool the model is allowed to use

The request has two parts: the conversation, and a `tools` array describing what get_weather takes as input. Nothing has been called yet — this is just a menu the model can read.

POST /v1/messages
{
  "model": "claude-opus-5",
  "max_tokens": 1024,
  "tools": [
    {
      "name": "get_weather",
      "description": "Get the current weather for a location",
      "input_schema": {
        "type": "object",
        "properties": {
          "location": { "type": "string" },
          "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
        },
        "required": ["location"]
      }
    }
  ],
  "messages": [
    { "role": "user", "content": "What's the weather in Lisbon right now?" }
  ]
}

what the harness owns

Everything with side effects: parsing the JSON, matching "get_weather" against a dictionary of functions you wrote and registered, actually calling that function, catching its errors, and re-serializing the return value into the message the model reads next. The model's tool definition is a description it was shown, not a live connection to anything. If the harness never runs step 3, the “call” stays a string sitting in a JSON blob forever.

what the model still owns

Owning zero execution doesn't mean owning zero judgment. Three things sit entirely on the model's side of the fence, and a harness can't paper over a bad call in any of them:

Picking the right tool. With a dozen registered functions instead of one, choosing correctly, and not inventing a thirteenth that was never registered, is a judgment call made from the tool descriptions alone.

Knowing when to stop. Call again for more information, or answer with what's already in hand? Loop forever and the harness eventually has to cut it off; stop too early and the answer is wrong.

Staying inside the schema. Emit malformed or slightly-off-schema JSON at scale and the harness's parser rejects the call before it ever reaches step 3. Reliability here is a property of the model, not the plumbing.

brain and body

The model is a brain with no hands: it can want the weather checked, but it cannot reach out and check it. The harness is the body, arms that fetch, eyes that read the result back. A brain with better judgment picks the right hand for the job and knows when to stop reaching; it still never touches the world directly. That separation is also why a harness can hand a model a brand-new tool it has never seen before, described only by a schema, and get a reasonable first attempt back: the judgment generalizes even when the specific hand is new.