What Is an AI Agent? Tools, Memory, Planning and the Agent Loop

A working definition of an AI agent

Anthropic's Agent SDK documentation gives a definition that works well for developers: an agent is an application that completes a task by planning its own steps and calling tools that read files, run commands or edit code. The key words are its own steps. A chatbot answers one message at a time and a human decides what happens next. An agent receives a goal, such as reconcile last month's GST invoices against the bank statement, and the model decides which tool to call, reads the result and chooses the next action until the goal is met or it gives up.

This means an agent is not a new kind of model. It is ordinary software wrapped around a language model. You write the tools, you decide what the agent may touch, and you set the limits. The model contributes judgement about which step to take next. Keeping that split in mind helps you debug agents: when something goes wrong, the cause is usually a vague instruction, a badly described tool or missing context, not a mysterious model failure.

The agent loop, step by step

Every agent framework in this course implements some version of the same loop. The model receives the task, the conversation so far and a list of tools described as names, descriptions and input schemas. It replies either with text, which ends the run, or with one or more tool calls. Your code runs those tools, appends the results to the conversation and calls the model again. The loop continues until the model stops asking for tools or a limit is reached.

The pseudocode below is not any vendor's API. It shows the shape that frameworks such as LangGraph, the OpenAI Agents SDK or Google's ADK hide behind a single run call. Read it slowly, because every later lesson is a variation on these dozen lines. Notice the step limit. Without it, a confused agent can call tools forever and run up a large bill, which is why production frameworks offer a maximum turns or similar setting.

• Observe: the model reads the task, history and tool results.
• Decide: it picks a tool and arguments, or decides it is finished.
• Act: your code executes the tool with real permissions.
• Repeat: results go back into the context for the next decision.

# Illustrative pseudocode of the agent loop, not a real library API
# Check each framework's official docs for its actual run method
def run_agent(task, model, tools, max_steps=10):
    messages = [{"role": "user", "content": task}]
    for step in range(max_steps):
        reply = model.generate(messages, tools=tools.schemas())
        messages.append(reply)
        if not reply.tool_calls:
            return reply.text  # the model decided the task is done
        for call in reply.tool_calls:
            result = tools.run(call.name, call.arguments)
            messages.append({"role": "tool", "id": call.id, "content": result})
    return "Stopped: step limit reached"

Tools: how an agent acts on the world

A tool is a function the model can ask you to run. Most frameworks build the tool description from your code: Google's ADK, for example, reads a plain Python function's type hints and docstring to create the schema the model sees. Because the model only sees that description, writing it well is real engineering work. Say what the tool does, what each argument means, which units it uses and what it returns when nothing is found.

Tools also carry risk. A tool that reads a customer's order status is harmless. A tool that issues a refund, sends an email to a client in Dubai or deletes a file changes the real world. Group your tools into read only and write tools from the start, because later lessons on guardrails and approval gates build on exactly that split. Start every agent with the smallest set of tools that can finish the task.

Memory: short term and long term

Short term memory is simply the conversation and tool results inside one run or thread. It lives in the model's context window, so it is limited and costs tokens every turn. Frameworks give it different names: sessions in the OpenAI and Claude SDKs, threads and checkpoints in LangGraph. When a run must survive a server restart or wait for a human, this state has to be saved to a database rather than kept in memory.

Long term memory is information that should persist across tasks, such as a user's preferred language, a clinic's opening hours or the outcome of last week's ticket. It is usually stored outside the model, in a database or a vector store, and retrieved when relevant. Treat long term memory like any other user data: decide what you store, for how long, and who can read it, especially if you serve customers under India's data protection rules or the UK GDPR.

Planning, and when not to build an agent

Planning is the agent's ability to break a goal into steps. Some systems ask the model to write an explicit plan first; others let the plan emerge from the loop. Either way, longer plans fail more often, because each step has a chance of going wrong. Good designs keep tasks short, check intermediate results and give the agent a clear definition of done.

Not every problem needs an agent. If the steps are always the same, such as extract fields from an invoice and post them to an accounting system, a fixed workflow with one model call per step is cheaper, faster and easier to test. Use an agent when the path genuinely varies, for example a support assistant that must decide whether to look up an order, check a refund policy or hand the case to a person. XDQ Labs teams start most client projects as plain workflows and add agent behaviour only where the path really branches.

Check your understanding

Turn what you learn into monthly income

Resell AI agents and apps under your own brand. Up to 30% off credits, up to 30% recurring share, and apps built by XDQ Labs for your clients. Free to join.