AI Agents.

An AI agent is an LLM given a goal, a set of tools, and permission to take several steps on its own. A single LLM call is one turn: text in, text out, then it is over.

The real difference is control. You trade a predictable path for the ability to handle tasks whose steps are unknown up front. That is why every agent needs step limits, spend budgets, and logs.

An agentic system runs a loop: the model reasons about what to do next, acts by calling a tool, then observes the real result. The observation is appended to the context, so the next reason step is better informed. The loop repeats until the model replies with an answer instead of a tool call.

while True:
    step = model(messages)              # reason: decide the next action
    if not step.tool_calls:
        return step.text                # model answers -> loop ends
    result = run_tool(step.tool_calls)  # act
    messages += [step, result]          # observe: real output back into context

Two things make this agentic. The observation is ground truth from a live system, not the model's guess. And the model, not your code, picks each next step. An error is just another observation, so the model can retry with different arguments.

Tool use, also called function calling, lets you hand the model a list of typed function definitions. The model never runs code. It returns a structured request that names one tool and its arguments. Your code runs it and passes the result back.

{ "type": "tool_use", "name": "get_order", "input": { "order_id": "A-1187" } }

It is the foundation because a raw model can only produce text from what it learned in training. Tools give it fresh reads of the world and real writes to it. Almost every other agent capability ships as just another tool: retrieval, memory, even calling another agent.

The tradeoff is that the model decides but your code executes. Tool selection is probabilistic, so validation, permissions and rate limits belong in your handler, never in the prompt.

One function call takes two API calls, not one. The model never runs your code. It only asks you to run it, and you send the result back.

1. Your app sends the messages plus the tool schemas
2. Model replies with a tool_use block: name, input, and an id
   (stop_reason "tool_use" - no final text yet)
3. Your app runs the real function
4. Your app appends that assistant turn, then a user turn holding a
   tool_result block whose tool_use_id matches the same id
5. Resend the whole message list; the model reads the result and answers

Two details prove you have built this. The API is stateless and remembers nothing between calls, so step 5 resends every earlier turn, including the tool_use one. And the ids must pair exactly, or the request is rejected.

OpenAI names the same pieces tool_calls and role: "tool" with tool_call_id. The loop can repeat: the model may ask for another call before it stops.

A deterministic workflow has its steps fixed in code, so every run follows the same path. An agentic workflow lets the model pick the next step at runtime, so the path changes with the input.

The trade-off is control versus flexibility. Fixed steps buy repeatable runs, cheap debugging, and a predictable bill. Agency handles cases you never listed.

Most production systems mix both: a fixed pipeline with one agentic step where the branching is unknown. Start deterministic, and add agency only where fixed logic keeps failing.

ReAct, short for Reasoning and Acting, is a prompting pattern from a 2022 paper by Yao et al. It makes one model interleave short reasoning steps with tool actions in a single trace.

Thought: I need Acme's current CEO.
Action: search("Acme CEO")
Observation: Jane Doe, since 2024.
Thought: That answers it.
Answer: Jane Doe.

It was influential because it joined two things that were separate. Chain-of-thought, where the model writes its reasoning out loud, could plan but not check facts. Tool-using systems could act but not plan. ReAct grounds each reasoning step in a real observation, so wrong turns get caught mid-task.

Today most agents run this shape through native tool-calling APIs instead of parsing Thought: and Action: text.

The system prompt is the agent's standing instructions. It is the one block of context that stays fixed while the reason-act-observe loop rewrites everything else.

It sets the role and scope, the policy for using tools, and the rule for when to stop and answer.

Role and scope:   what you are; what you must refuse
Tool policy:      search before answering; never write without approval
Stopping rule:    stop when the task is done; ask if inputs are missing
Output format:    short markdown; cite the file you read

Two things matter in practice. Keep it stable, because a fixed prefix is what prompt caching can reuse. Keep it small: durable policy belongs here, and per-task detail belongs in the user message.

It steers the model but enforces nothing. Text arriving from a tool can still argue against it.