ai-agent-book/slides/lesson-02.md

theme, title, info, author, transition, mdc, lineNumbers, monaco, aspectRatio, canvasWidth, layout, class

theme	title	info	author	transition	mdc	lineNumbers	monaco	aspectRatio	canvasWidth	layout	class
seriph	Chapter 1 · Lesson 1 — What Turns an LLM into an Agent?	English video course for AI Agents in Depth	Bojie Li	slide-left	true	false	false	16/9	980	cover	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

Bojie Li · AI Agents in DepthCourse Lesson 02 of 42 · 18 minutes

---

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

1. Fetch Moonshot’s authoritative web_search declaration.
2. Kimi decides when and how to call it.
3. Each call runs through a Formula Fiber.
4. 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

$ 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.

Next experimentExperiment 1-3 · GPT-5.6 search + code Book questionWhen would you choose a stronger model, richer context, or more tools?