AI & Machine Learning for Developers
Building AI Agents
An AI agent, in the sense developers build, is a language model wrapped in a loop that lets it take actions — calling functions or external tools, seeing the result, and deciding what to do next — rather than producing one reply and stopping. This guide covers that mechanism (tool/function calling and the agent loop) from an implementation angle. It complements, rather than repeats, this site's existing Agentic AI hub, which explains what agents are and why they matter for a non-technical reader; this guide is for developers who are actually building one.
Why it matters
- It's the mechanism behind most practical "agent" products
- Whatever the marketing language, most working AI agents are built from the same core pattern — a model that can request a specific function be called, see the result, and continue — rather than something fundamentally more mysterious.
- It multiplies what a language model alone can do
- A model by itself only produces text; giving it the ability to call real functions (search, calculators, database lookups, other APIs) lets it actually retrieve current information or take real actions rather than only guessing from training data.
- It introduces a new category of reliability and safety problem
- A model deciding, sometimes incorrectly, when and how to call a real function with real side effects is a genuinely different risk profile than a model that can only generate text.
- The design of the available tools shapes the agent's behavior as much as the model does
- A poorly described or overly broad tool produces worse agent behavior than a well-scoped one, independent of which underlying model is used.
Tool calling: giving a model a way to act
Tool calling (also called function calling) works by describing a set of functions to the model — typically their names, what they do, and what arguments they take, often using a schema format such as JSON Schema — alongside the user's request. Instead of generating a final answer directly, the model can generate a structured request to call one of those functions with specific arguments. The calling application, not the model itself, actually executes that function — running the real code, hitting the real database or API — and then returns the result back to the model as part of the conversation. The model was never actually running the function; it was only producing a structured description of what it wanted called, and trusting the surrounding code to run it and report back honestly.
# 1. The application describes available tools to the model
tools = [
{
"name": "get_weather",
"description": "Get current weather for a city",
"parameters": {"city": "string"},
}
]
# 2. The model responds asking to call one, instead of a final answer
# (the model never runs this itself — it only requests it)
model_response = {
"tool_call": "get_weather",
"arguments": {"city": "Mumbai"},
}
# 3. The application executes the real function
result = get_weather(city="Mumbai")
# 4. The result is sent back to the model to continue the conversation
# (e.g. to produce a final, natural-language answer for the user)The agent loop
A single tool call rarely finishes the job on its own — the agent loop is what turns one tool call into a working agent. The pattern repeats: send the model the conversation so far and the available tools, let it either answer directly or request a tool call, execute any requested tool and feed the result back in, and repeat until the model produces a final answer instead of another tool request. This is what lets an agent break a task like "find this file, summarize it, and email the summary" into several steps, each informed by the result of the last, without a human manually chaining the calls together. It also means the loop needs a stopping condition — a maximum number of steps, or a specific signal the model is meant to send when it's actually done — because nothing about the pattern itself guarantees the model won't keep requesting tool calls indefinitely.
Mistakes people make here
- Giving a tool too much power with too little oversight
- A tool that can delete data, send messages, or spend money, invoked by a model that occasionally misjudges when it's needed, is a very different risk than a tool that only reads data — the scope of what a tool can do should match how much you trust the model's judgment about when to call it.
- Writing vague tool descriptions
- The model decides when and how to call a tool based only on its name, description, and parameters; an ambiguous description leads directly to the model calling the wrong tool, or the right tool with the wrong arguments.
- Not bounding the agent loop
- Without a maximum step count or a clear stopping signal, a model that gets into an unproductive pattern can keep calling tools indefinitely, which costs real time and money and can also compound the impact of any single tool that has side effects.
- Trusting a tool's result without validating it inside the loop
- If a called function itself returns bad data (a failed lookup, an error message shaped like valid data), the agent will often just continue reasoning from that bad data as if it were correct, since nothing in the loop automatically distinguishes success from failure unless the application code makes that distinction explicit.
- Confusing an agent's fluent explanation of its actions with an accurate one
- A model narrating why it called a tool is generating a plausible-sounding explanation, not necessarily reporting its actual internal process — it's useful for a human to read, but not a guaranteed accurate audit trail on its own.
Strengths and trade-offs
Where it is strong
- Lets a language model take real, current actions — calling an API, querying a database — instead of being limited to what it learned during training.
- The loop pattern is general enough to chain arbitrarily many steps together to complete a multi-part task without hand-written control flow for every case.
- Tool descriptions and scopes are a real point of control: narrowing what a tool can do is a direct, effective way to constrain what the agent can do.
The trade-offs
- A model can call the wrong tool, or the right tool with wrong arguments, and nothing about the pattern prevents that by default — validation has to be built in.
- Each step in the loop is a separate call to the underlying model, so a multi-step agent task is slower and more expensive than a single response.
- Tools with real side effects (sending messages, spending money, modifying data) turn a language model's occasional misjudgment into a real-world consequence, which raises the stakes of getting tool scope and oversight right.
- Debugging an agent that took an unexpected multi-step path is harder than debugging a single request/response call, since the failure could be in any step of the loop.
Who needs this
Developers building an application where a language model needs to take actions, not just produce text — calling internal APIs, querying data, orchestrating multiple steps — need this pattern. If your use case is a single prompt in, single answer out, the plain API mechanics in this section's working-with-LLM-APIs guide are enough on their own.
Questions about building ai agents
- Is an agent just a language model with extra steps?
- In the implementation sense covered here, largely yes — it's a language model, a defined set of callable tools, and a loop that lets the model request tool calls and see their results before producing a final answer. The behavior can look sophisticated, but the mechanism is that specific pattern, not something categorically different.
- How is this different from the site's Agentic AI hub?
- That hub explains what agents are and why they matter, aimed at a non-technical reader. This guide covers how to actually build the tool-calling and loop mechanism behind one, aimed at developers.
- Does the model actually execute the tools itself?
- No. The model only produces a structured request to call a tool with specific arguments; the surrounding application code is what actually runs that function and decides whether to trust and act on the model's request.
- What stops an agent from calling tools forever?
- Nothing, unless the application enforces it — typically a maximum number of loop iterations, and often a specific signal the model is instructed to produce when the task is genuinely finished.