Building AI Agents with Prompt Engineering Fundamentals

An AI agent is just a prompt loop with a goal, a set of tools, some memory, and the ability to keep going until it decides it is done. Strip the hype and what's left is mostly prompt engineering — the same techniques from the rest of this section, composed into a system that can take multi-step actions on its own.

1. Introduction

"Agent" is the most over-loaded word in modern AI. To some people it means a chatbot. To others it means a self-driving piece of software that can book your flights, refactor your codebase, and renegotiate your bills. For this tutorial we will use a tight, useful definition: an agent is a system in which a language model is given a goal, a set of tools, and a memory, and is allowed to autonomously decide what to do next until the goal is achieved or a stop condition is met.

Almost everything in this definition is something you have seen already in this section — function calling, ReAct loops, memory layers, structured outputs. The agent is the composition. The interesting questions are how to compose them so the system is genuinely useful instead of impressively erratic.

2. The Concept Explained

A workable agent architecture has six parts. None of them are exotic; the craft is in how carefully each one is designed.

• Goal. What the agent is trying to achieve, expressed in the system prompt with explicit success and failure criteria.
• Planner. The prompt pattern that turns a goal into a sequence of intended steps. Often Chain-of-Thought or Tree-of-Thoughts inside the system prompt.
• Tools. The functions the agent can call. Each one has a schema, a description, and a clear safety posture (read vs write).
• Memory. Working memory of recent steps, summary memory of older steps, and optionally a long-term store of facts the agent has learned.
• Runtime loop. The orchestrator: it parses tool calls, executes them, feeds results back, enforces step caps, and detects completion.
• Guardrails. Cost limits, action allow-lists, human-in-the-loop checkpoints for destructive operations. Without guardrails, agents are demos, not products.

3. The Problem Without a Disciplined Design

System: You are an autonomous AI agent. The user will
give you a goal. Use the tools available to achieve it.

Tools: web_search, file_write, send_email, run_shell,
delete_file, transfer_money, ...

User: Plan my parents' 40th anniversary trip.

4. The Solution: Tight Goal, Small Tools, Hard Guardrails

# Role
You are a trip-research agent. You plan but do not book.

# Goal
Produce a single Markdown itinerary for the user's trip
that includes: 3–5 flight options, 3 hotel options, and
a day-by-day plan for the destination.

# Tools (all read-only)
- web_search(query)
- get_flight_options(origin, destination, dates)
- get_hotels(city, dates, max_price_per_night)
- finish(answer)

# Process
1. Restate the user's goal in your own words.
2. List the sub-tasks you will work through.
3. For each sub-task, call at most 3 tools.
4. When you have enough information, call finish() with
   the itinerary as a single Markdown document.

# Hard limits
- Maximum 12 tool calls.
- Maximum 8,000 tokens of total tool output.
- If a tool fails twice, skip that sub-task and continue.
- Never call a tool not in the list above.
- Never claim to have booked anything.

# User goal
{{user_goal}}

5. Step-by-Step Breakdown

1. Define success and failure crisply. "Plan a trip" is a hope. "Produce a single Markdown itinerary with 3–5 flights, 3 hotels, and a day-by-day plan" is a goal. Concrete goals let both you and the agent know when to stop.
2. Make the planning step explicit. Instruct the agent to write a plan before acting. Plans externalise reasoning, make debugging vastly easier, and reduce wasted tool calls.
3. Keep the toolset small and read-biased. The smaller and safer the toolset, the more reliable the agent. Add write tools only when you have built guardrails around them.
4. Layer your memory. Working memory holds the recent loop steps. A summary every few steps prevents the context from exploding. Long-term memory across runs is optional — usually overkill for a single task.
5. Enforce hard limits. Maximum tool calls, maximum tokens, maximum money. The runtime enforces these — never the model. Models cannot reliably bound themselves.
6. Insert human-in-the-loop checkpoints. For any irreversible action (sending money, deleting files, hitting "publish"), the agent proposes the action and a human approves it via your UI. This is the simplest and most effective agent safety lever.
7. Evaluate end-to-end. Build a fixture set of goals with expected outputs. Run the agent against the fixtures on every prompt or tool change. Agents have many failure modes — only end-to-end evals catch them all.

Tip: The single most useful agent design instinct is narrow the scope. A tightly scoped agent that does one job extremely well is dramatically more useful (and safer) than a general-purpose agent that does everything mediocrely. The same applies to humans you hire.

6. Practice Exercises

7. Key Takeaways