LLM agents in detail

LLMs & agents gave the big picture. Here is what one tool call actually looks like.

Anatomy of a tool call

The model receives tool schemas — name, description, JSON parameters:

{ "name": "drive",
  "description": "Drive the robot.",
  "parameters": { "speed": "number 0..1", "seconds": "number" } }

When it decides to act, it emits a structured call — drive(speed=0.3, seconds=2) — the runtime executes it, and the result text goes back into the conversation as if the world had spoken. The model reads it and continues.

Consequences you can use

• Descriptions are prompts. The model picks tools by reading their descriptions — a vague description means wrong or missed calls. Name tools by what they do.
• Results are the agent's only senses. Return short, information-dense results ("moved 0.5m, obstacle at 0.3m") — a wall of logs drowns the signal.
• Errors are normal input. A good agent reads the error and adapts; a good tool returns errors as readable text instead of crashing.
• Sequencing matters. Calls in one turn run in order — "drive, then capture" is safe to request together.

Multi-turn state

The conversation is the agent's memory: earlier results, your corrections, its own plans. That's why instructions (always present) beat in-chat requests (which scroll away) for standing rules — and why clearing the chat resets behavior.

Practice: make tools · vibe-code an agent app