Day 3: Introduction to Agents

What is an Agent?

An Agent is a system that pursues a specific goal by perceiving its environment and autonomously deciding which actions to take to achieve that goal.

Today we’re entering the world of Autonomous Agents. This is a shift from “Predictive AI”—where we ask a model to predict the next word—to “Agentic AI”—where we ask a system to accomplish a goal.

We’ll cover the core architecture, how agents “think”, and the levels of autonomy from simple tools to self-evolving systems.

What You’ll Learn Today

By the end of this session, you will:

• Define an AI Agent and its core components (Model, Tools, Orchestration)
• Understand the 5-step “Think, Act, Observe” loop
• Classify agents using the 5-level taxonomy
• Recognize the importance of “Agent Ops” for production reliability

We’ll start with the definition. You’ll learn that an agent isn’t just a smarter model; it’s a software system.

We’ll dissect the “Think, Act, Observe” loop—the engine that drives every agent.

We’ll look at the taxonomy—how we go from a Level 0 reasoning engine to a Level 4 self-evolving system.

And finally, we’ll talk about the boring but critical stuff: Ops. How do you actually keep these things running without setting money on fire?

The Paradigm Shift: From Predictive to Agentic

Figure 1: A new class of software

• Predictive AI: Passive, discrete tasks (answering, translating).
• Agentic AI: Active, goal-oriented, multi-step execution.
• The Shift: From “User directs every step” to “User sets a goal”.

For years, AI was passive. You give a prompt, you get an answer. If you wanted a complex task done, you had to be the “bricklayer,” prompting for every single step.

Now, we’re building “Agentic AI”. The user is the “director.” You set the scene, give the goal, and the agent figures out the steps. It plans, acts, and corrects itself.

What is an AI Agent?

Agent = Model + Tools + Orchestration + Runtime

Figure 2: An anatomical diagram of an AI Agent

An agent is not just a model. It’s a compound system. It has a Brain (the LM) to reason. It has Hands (Tools) to interact with the world—APIs, databases. It has a Nervous System (Orchestration) to manage memory and planning. And it has a Body (Deployment) to run reliably in production.

Core Architecture

The Model (Brain)

• Selection: Not just benchmarks. Choose for reasoning and tool use.
• Routing: Use “thinking” models for planning, “flash” models for simple tasks.
• Multimodal: Vision/audio vs. reliable text-only pipelines.

Figure 3: Tradeoff between cost/speed and reasoning quality

• Your choice of model matters. Don’t just pick the biggest one.
• For complex planning, you need high reasoning. Use a frontier model.
• For summarizing a retrieved email, a smaller, faster model is cheaper and faster.
• Routing between them is a key optimization.

The Tools (Hands)

• Retrieval (RAG): “Library card” for knowledge.
• Actions: APIs, SQL execution, sending emails.
• Function Calling: Structured contracts (OpenAPI) for reliability.
• Human-in-the-Loop: Tools to ask the user for clarification.

Figure 4: Agent tools as a Swiss Army knife

• Tools define what an agent can do.
• RAG is a tool—it’s how the agent knows things.
• Actions are how it changes things—API calls, SQL queries, sending emails.
• And don’t forget the Human. A tool that asks the user “Did you mean X?” is often the most valuable one.

The Orchestration (Nervous System)

Figure 5: Context Engineering

• Short-term Memory: The current conversation thread.
• Long-term Memory: Vector stores for past sessions.
• Guardrails: Hard-coded rules (e.g., “Spend limit < $100”)

• Orchestration is the code that holds it all together.
• It manages the context window. You can’t fit everything, so you must engineer the context.
• It handles memory—what did we say 5 minutes ago? What did we say 5 days ago?
• And it enforces guardrails. An agent shouldn’t be able to buy a house just because it hallucinated a command.

Levels of Autonomy

Figure 6: Agentic system in 5 levels of complexity

We classify agents into 5 levels.

• Level 0 is just ChatGPT in a box. It knows everything about the past but nothing about the present.
• Level 1 gets Tools. It can Google the score of last night’s game.
• Level 2 gets Strategy. It can plan a trip and find a coffee shop halfway between two points.
• Level 3 gets Teamwork. Multiple agents collaborating—a researcher, a writer, a reviewer.
• Level 4 gets Evolution. The system notices it’s missing a tool and writes code to create it.

Best Practices for Tool Use

Documentation is Critical

Figure 7: A blueprint document with highlighted sections for ‘Name’, ‘Parameters’, and ‘Examples’

• update_jira or get_data (Bad: not descriptive)
• create_critical_bug and fetch_customer_order_history (Good: descriptive)
• Explain type and purpose.
• Show the model how to handle tricky cases.
• Document default values clearly.

If your agent isn’t working, 90% of the time it’s your tool definitions. The documentation is the prompt. Use clear, verbose names. get_data is bad. fetch_customer_order_history is good. Give examples in the docstring. It saves you from fine-tuning.

Describe Actions, Not Implementations

Figure 8: A director chair labeled ‘Action’ vs a mechanic’s manual labeled ‘Implementation’

• “Use the send_message tool” (Bad: dictating tool usage)
• “Send message to John Doe” (Good: describing the action)
• Don’t repeat tool docs in system instructions
• Document side effects: If a tool saves a file, the agent needs to know that file exists for the next step.

When instructing the model, focus on the goal. Tell it what to achieve, not strictly how to call the API. If you dictate the exact workflow, you lose the agent’s ability to handle edge cases. But DO explain side effects. If a tool saves a file, the agent needs to know that file exists for the next step.

Publish Tasks, Not API Calls

Figure 9: A neatly wrapped package labeled ‘Task’ vs a tangled wire labeled ‘Raw API’

• Tools should map to user goals, not raw endpoints.
• One tool = One specific responsibility.
• Don’t chain 10 steps into one black box function.

Don’t just wrap your entire API surface. APIs are for developers. Tools are for agents. An agent needs a tool that says “Book Flight”, not 5 separate tools for “Auth”, “Check Availability”, “Reserve Seat”, “Process Payment”, “Confirm”. Wrap that complexity into a meaningful “Task” for the agent.

Design for Concise Output

Figure 10: A funnel filtering a large database dump into a single concise reference card’

• Use References: Return a table_name or file_path instead of raw data.
• Error Messages: Make them descriptive. Tell the agent how to fix the error.

Output matters. If your tool returns a 5MB JSON file, you just blew your context window/budget (and maybe confused the model). Return summaries or references. And if it fails, don’t just say “Error 500”. Say “Product not found. Try searching by name instead of ID.” Guide the agent to self-correct.

Key Takeaways

1. Documentation is Critical: The documentation is the prompt.
2. Describe Actions, Not Implementations: Tell the model what to achieve, not strictly how to call the API.
3. Publish Tasks, Not API Calls: Wrap your entire API surface. APIs are for developers. Tools are for agents.
4. Design for Concise Output: Return summaries or references.
5. Error Messages: If it fails, don’t just say “Error 500”. Guide the agent to self-correct.