AI Agents: Beyond Chat

The difference in one line

A chatbot produces text. An agent produces text and actions — it can call tools, read the results, and decide what to do next.

That loop is the whole idea. Everything else is engineering around it.

The loop

history = [user_request]

while True:
    response = model(history, tools)

    if response.is_final_answer:
        return response.text

    result = execute(response.tool_call)      # your code, not the model's
    history.append(response, result)

Each turn: the model reasons about the state, acts by requesting a tool, observes the returned result, and repeats. This is the ReAct pattern — reason and act — and it underpins essentially every agent framework.

The critical detail, easy to miss and important for everything below:

The model never executes anything. It emits a structured request — a tool name and arguments. Your code decides whether to run it.

That gap is where every safety control lives.

A worked example

“Find my most recent order and tell me if it can still be returned.”

Note what did not happen. The agent did not process a return. It reported a finding and stopped. That boundary was a design decision, and it is the right one.

Tools: descriptions do the work

A tool definition is a name, a description, and a parameter schema. Newcomers polish the name. The model reads the description.

Weak:

{ "name": "search", "description": "Searches" }

Usable:

{
  "name": "search_products",
  "description": "Search the product catalogue by keyword. Returns up to 5 products with name, price in GBP, and stock status. Use for questions about what is available or what something costs. Does NOT return order history — use get_orders for that.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Keywords: product name, category, or description terms" },
      "max_price": { "type": "number", "description": "Optional ceiling in GBP" }
    },
    "required": ["query"]
  }
}

The second version states what it returns, when to reach for it, and what it is not for. That last clause prevents a whole class of wrong-tool errors.

Three practical rules:

• Validate arguments before executing. Models hallucinate parameter values. Never pass them straight into a query.
• Return errors as usable text. "No product found matching 'blue widget'" gives the model something to act on. A stack trace does not.
• Keep the toolset small. Selection accuracy falls as the list grows. Ten focused tools beat forty overlapping ones.

Connecting tools has begun to standardise — the Model Context Protocol is the emerging common interface, so a tool written once can be exposed to different assistants. Worth knowing the name exists.

Memory

Agents need three distinct kinds, and conflating them causes bugs:

• Working memory — the current task’s history. Lives in the context window; disappears at the end.
• Conversation memory — this session’s dialogue, usually summarised as it grows.
• Long-term memory — preferences and facts persisted in a database across sessions, retrieved when relevant.

Only the first is automatic. The other two are systems you build.

The approval boundary

This is the part that matters most, and where the earlier version of this course got it wrong.

The test is reversibility, not risk of error:

A retrieval that returns the wrong row costs one retry. A message sent to the wrong customer cannot be recalled. That asymmetry, not how clever the model is, decides where the gate goes.

So: an agent that finds you the cheapest flight and presents it is a good design. An agent that books it unprompted is a bad one — not because it will often be wrong, but because when it is, nothing can be done.

Three more structural guards, none optional:

• Iteration cap. Loops happen. Bound them.
• Least privilege. Give each agent only the tools its job needs. A support agent has no business holding a database-admin tool.
• Log every call. When something goes wrong you need the sequence of tool calls and results, or you are guessing.

Common failure modes

• Repeating a failing call — expecting a different result. Cap iterations; return descriptive errors.
• Invented arguments — a plausible-looking ID that does not exist. Validate everything.
• Context exhaustion — long runs fill the window and early instructions fall out.
• Error cascade — one bad result poisons every subsequent step.
• Scope creep — the agent finds a way to do something it was never meant to. Least privilege is the answer.

Try this: Take a task you would want an agent to do and list every tool it would need. Mark each one reversible or irreversible. The irreversible ones are your approval gates — and if that list is long, the task may not be a good candidate for automation yet.