Agent Architecture & Tool Use

An agent is a model wrapped in a control loop that gives it access to tools — functions it can call. The classic loop is think → act → observe:

1. The model receives a goal and the current transcript.
2. It reasons about what to do next.
3. It emits a tool call with structured arguments (e.g. JSON).
4. The runtime executes the tool and returns the observation (a string) to the model.
5. The model continues until it emits a stop signal, a max-iteration guard fires, or a budget is exhausted.

Tool calling is the contract that makes this work. The model is trained to produce structured outputs (JSON or XML) that match a tool schema. The runtime parses the call, runs the function, and feeds the result back.

Common patterns:

• Single-tool agent — the model has one tool (e.g. a search API) and decides what to query.
• Multi-tool agent — the model picks among N tools, each with a typed schema.
• Orchestrator + sub-agents — a top-level agent delegates to specialized sub-agents (e.g. "researcher" and "coder") that themselves have tools.
• Reactive vs deliberative — some agents stream a plan first; others interleave thinking and actions.

Failure modes:

• Loops — the model repeats the same tool call. Guardrails: max iterations, idempotency, loop detection.
• Hallucinated tool calls — invalid arguments. Guardrails: schema validation, retries with error feedback.
• Side effects — agents that write to files or send email need human-in-the-loop approval for sensitive actions.

Frameworks (LangGraph, the OpenAI Agents SDK, the Claude Agent SDK) implement these patterns, but the underlying model is the same next-token predictor with a tool-calling format.