---
theme: seriph
title: "Chapter 1 · Lesson 1 — What Turns an LLM into an Agent?"
info: "English video course for AI Agents in Depth"
author: Bojie Li
transition: slide-left
mdc: true
lineNumbers: false
monaco: false
aspectRatio: 16/9
canvasWidth: 980
layout: cover
class: chapter-formula-cover
---
BUILD · CHAPTER 1 · AGENT FUNDAMENTALS
# What Turns an LLM into an Agent?
LLMReasoning engineUnderstand · plan · decide
+
ContextWorking setObserve · remember · retrieve
+
ToolsAction interfacesSearch · execute · communicate
Agent = Reasoning Engine + Working Context + Action Interfaces
---
class: chapter-dense
---
# You Have Already Used an AI Agent
Chapter 1 begins with products that have crossed the boundary from answering to acting.
| Product | What it observes | What it does | How it adapts |
|---|
| Cursor | Requirements, codebase, terminal | Searches, edits, runs tests | Debugs until tests pass |
| Deep Research | Web, papers, local files | Searches, reads, synthesizes | Changes the research direction |
| Manus | Browser, files, screen | Clicks, types, executes code | Replans from interface feedback |
| Doubao | Phone screen and apps | Opens, swipes, types, confirms | Responds to the app state |
| Pine AI | Accounts, bills, provider knowledge | Calls, emails, negotiates | Adjusts strategy during the task |
Shared trait: they plan execution steps, call the tools a task requires, and revise their strategy as results arrive.
---
class: chapter-dense
---
# One Formula, Three Levels of Description
| Intuition | Agent component | RL term (optional) | Responsibility |
|---|
| Reasoning engine | LLM | Policy | Given current information, choose what to do next. |
| Working context | Context | Observation space | Everything the Agent can observe, read, remember, and retrieve. |
| Action interfaces | Tools | Action space | Everything the Agent can do—from messages and APIs to code and GUI control. |
The minimal system: LLM + context + tools is enough to demonstrate an Agent loop.
The production question: later in the chapter, Harness Engineering adds constraints, verification, and correction.
---
class: chapter-dense
---
# Observation + Action Spaces Are the Agent's ISA
Hennessy and Patterson use the instruction set architecture as the interface between software and hardware. Chapter 1 applies the same idea to Agents.
External worldWeb · files · apps · people
Observation space→
LLMReasons over what enters context
Action space→
External worldChanged by tool execution
Outside the observation space: information effectively does not exist for the model.
Outside the action space: the model can recommend an operation, but it cannot perform it.
With the model held constant, expanding the right context or tool can make a previously unsolvable task solvable—without retraining.
---
class: chapter-dense
---
# Generality Often Comes from Expanding the Interface Boundary
Manus: unite previously separate spaces
- Deep Research: the web enlarges observation.
- Coding: files and code execution enlarge action.
- Computer Use: screen perception and clicking enter both spaces.
Its generality did not come merely from swapping in a stronger model; it took the union of three earlier Agent categories.
OpenClaw: extend into the user's digital life
- Messaging channels make the Agent reachable from almost anywhere.
- A local-first Gateway reaches authorized local files and cloud applications.
- Plugins and Skills enlarge the action interface on demand.
The product boundary moves outward—but authorization, relevance, and verification must move with it.
Expansion is not “include everything.” Irrelevant context adds noise; too many tools increase selection cost and security risk. Useful expansion is on-demand, relevant, and controlled.
---
class: chapter-dense
---
# Five Agent Products, Compared on the Same Three Dimensions
| Agent type | Working context | Action interfaces | Execution strategy |
|---|
| Coding | Requirements, repository, terminal | Search, read/write files, commands | Understand → edit → test → debug |
| Search | Web, academic databases, local files | Queries, web reading, synthesis | Iteratively deepen and redirect research |
| Computer control | Screen, browser, file system | Click, type, scroll, screenshot, code | Observe interface → act → verify |
| Phone assistant | Phone screen, installed applications | Click, swipe, type, open apps | Understand intent → operate → confirm |
| Personal task | Accounts, bills, provider knowledge | Calls, email, forms, user confirmation | Gather → plan → contact → negotiate → report |
Open-ended actionGenerate language and code—not select only from fixed buttons.
Internal reasoningPlan before changing the environment.
Continuous interactionUse environmental feedback to choose the next step.
---
class: chapter-dense
---
# Tools Are More Than Callable APIs
1 · Perception
Bring information into the Agent: search, files, APIs, databases.
2 · Execution
Change external systems: code, files, commands, service APIs.
3 · Collaboration
Delegate to sub-agents, request human confirmation, coordinate work.
4 · Event triggers
Email, schedules, and Webhooks activate the Agent; the Agent does not call them.
5 · User communication
Report progress or ask questions by message, voice, or email.
Tool quality defines what the Agent can accomplish reliably: vague interfaces cause misuse, weak error handling causes stalls, and broad permissions turn mistakes into irreversible actions.
---
class: chapter-dense
---
# Tool Calling Is a Four-Step Context Update
1 · Declare the interface
{
"name": "get_weather",
"parameters": {"city": "string"}
}
2 · The model decides
{
"tool_calls": [{
"name": "get_weather",
"arguments": {"city": "Beijing"}
}]
}
3 · Execute and append the result
{
"role": "tool",
"tool_call_id": "call_1",
"content": "{\"temp\":28,\"sky\":\"clear\"}"
}
4 · Decide again from the new context
{
"role": "assistant",
"content": "Today in Beijing: 28°C, sunny."
}
Division of responsibility: the developer declares and executes tools; the model decides whether to call one, which one, and with what arguments.
---
class: chapter-dense
---
# General Tools Compose; Specialized Tools Constrain
General-purpose foundations
- A calculator is enough for basic arithmetic.
- A constrained Python interpreter combines spreadsheet reading, cleaning, statistics, and plotting.
- A controlled working directory preserves plans, logs, intermediate results, and artifacts across long tasks.
Use for composition and exploration
Specialized high-risk operations
- Payments, deletion, email, and production deployment need explicit parameters.
- Restrict permissions and make the complete operation auditable.
- Add preview and human confirmation when an action is sensitive or irreversible.
Use to enforce business rules
Code sandbox minimums: network disabled by default; authorized working directory only; path-traversal prevention; execution-time, CPU, memory, storage, file-type, and output limits.
---
class: chapter-dense
---
# The LLM Supplies Reasoning Before It Supplies Action
The reasoning engine must infer intent, decompose a vague task, and repeatedly decide what to do next, whether to call a tool, and which arguments to use.
Zero-shot generalization
Solve a task with no demonstrations by recombining knowledge and reasoning patterns acquired during pre-training.
Example: produce a reasonable poem about quantum physics without being trained on that exact request.
Few-shot adaptation
Infer a new task pattern from two or three examples placed in the current context.
Example: learn a new user-comment → sentiment-label format from a handful of demonstrations.
Why this matters for Agents: the next action is not blind trial and error. The model draws on learned causal relationships, decomposition strategies, and world knowledge before acting.
---
class: chapter-dense
---
# “Model as Agent” Internalizes the Decision Policy—not the Tools
What post-training can write into weights
- When a tool call is useful.
- Which tool to choose.
- What arguments to pass.
- Whether to continue after a result.
- How to chain many calls coherently.
What remains outside the model
- The search engine and code sandbox.
- Tool declarations and provider infrastructure.
- Execution, permissions, and returned results.
- The server-side or client-side orchestration loop.
The orchestration loop has not disappeared: decision-making may move into the model while execution moves to the API server.
Chapter 1 clarification prompted by GitHub Issue #30.
---
class: chapter-dense
---
# Agents Learn on Three Timescales
Contextual adaptationInference-time, immediate, temporary, bounded by the context window.
Externalized learningKnowledge, prompts, Skills, programs, and Harnesses persist across tasks and remain auditable.
Parameter updatesTraining-time, costly, persistent, useful for high-dimensional capabilities and implicit policies.
Pragmatic Bitter Lesson: models will absorb parts of today’s Harness, but training moves more slowly than real business requirements. The Harness covers the current capability boundary and moves when that boundary moves.
---
class: chapter-dense
---
# Experiment 1-2: Can Kimi K3 Sustain Native Tool Use?
Canonical task
Verify ASEAN membership and the legal status of Jakarta versus Nusantara from official sources. Search once, inspect what evidence is missing, then perform distinct follow-up searches.
Exact provider route
- Fetch Moonshot’s authoritative
web_search declaration.
- Kimi decides when and how to call it.
- Each call runs through a Formula Fiber.
- The result returns as the next observation.
Acceptance requires real provider receipts: direct Moonshot API, exact kimi-k3 model, multiple distinct successful Fibers, sequential search rounds, reasoning, final answer, retrieval date, and official-source links.
---
class: course-terminal chapter-terminal
---
LIVE DEMO · EXPERIMENT 1-2 · REAL API
# Switching to the terminal
~~~bash
$ uv run --extra ch1 python chapter1/web-search-agent/run_experiment_1_2.py --attempts 1 --timeout 120
~~~
Watch the policySearch queries change as missing evidence becomes visible.
Watch the interfaceEvery action is a standard web_search call executed by a Formula Fiber.
Watch the receiptsResponse IDs, Fiber IDs, sources, token usage, and acceptance checks are retained.
Requires MOONSHOT_API_KEY. If the provider is unavailable during recording, inspect the accepted credential-free artifact on the next slide and label it retained evidence.
---
class: chapter-dense
---
# What the Accepted Run Actually Demonstrated
5reasoning iterations
15successful Formula Fibers
58,123total tokens
29,952cached prompt tokens
Observed in retained real-API evidence
- Different searches occurred over multiple sequential rounds.
- Every model action matched a provider-side Fiber request.
- The final answer cited ASEAN and Indonesian official sources.
- All acceptance checks passed on 2026-07-29.
What this does—and does not—show
- Shows: the model controls a long search policy and revises it from observations.
- Does not show: that the search engine or execution infrastructure lives in the weights.
- Cost: autonomy can require many calls and a large cumulative context.
Evidence: chapter1/web-search-agent/validation/latest.json · evidence mode: real_api
---
class: chapter-dense
---
# The Capability Boundary Is Often the Interface Boundary
Reasoning engine
The LLM supplies world knowledge, planning, judgment, zero-shot generalization, and a learned tool-use policy.
Working context
The observation space determines which task state, evidence, memory, and environmental feedback can influence a decision.
Action interfaces
Tools determine which operations can affect the world; broader interfaces require stronger permissions and verification.
When an Agent cannot solve a task, first locate the missing capability: model policy, observable information, or executable action.
