Extra Reading — AI Work Systems in One Chapter

The Big Picture: What Happens Inside One AI Task

flowchart LR
    U[User goal & materials] --> A[Agent planning]
    A --> L[LLM understanding & generation]
    A --> S[Skill methods & scripts]
    A --> T[Tool / Connector]
    T --> M[MCP / API]
    M --> X[Files, knowledge base & business systems]
    L --> R[Intermediate results]
    S --> R
    X --> R
    R --> C[Checkpoints & acceptance]
    C --> O[Final deliverable]

This diagram in one sentence: the model handles understanding and generation, the Agent organizes actions around the goal, Skills provide professional methods, tools and MCP/API let those actions reach the real world, and the human owns boundaries and acceptance.

Break a real task open and information flows roughly like this:

You state a goal → the Agent breaks it into steps → for specialized subtasks it loads the right Skill, for touching external systems it calls tools → tools actually read/write databases, send messages, change files via MCP or API → results come back to the model, which decides the next step → you do boundary control and final acceptance.

Among the five roles, the model is the brain, the Agent is the dispatcher, the Skill is the expert manual, the tools and interfaces are the hands and feet, and the human is the referee. Each following section explains one role and marks what it can and can't do.

LLM: The Base Model That Predicts Content From Context

LLM is Large Language Model. It learns language and knowledge patterns from large amounts of data and generates the most likely next content given the current input.

It's essentially a "predict the next content" engine — not a database, and not a person that takes responsibility for you.

What It's Good At

• Understanding, summarizing and rewriting text;
• Extracting structure from material;
• Generating drafts, plans and code;
• Imitating format and style from examples;
• Continuing analysis after tools return results.

What It Doesn't Guarantee By Itself

• Doesn't guarantee every fact is correct;
• Doesn't know a company's latest internal state unless you provide material or connect systems;
• Doesn't gain real evidence just because the language is confident;
• Doesn't automatically have file, account, database or network permissions;
• Doesn't bear business or legal liability.

Why It "Hallucinates"

The model's goal is to generate coherent content, not to be a built-in fact database. When material is missing, the question is vague, or it's pushed to give a definite answer, it may fill the gap with plausible-but-untrue content.

This isn't a bug — it's a side effect of "completing by probability". Once you get this, you stop asking "it sounded so sure, why is it wrong" — confidence and correctness are two different things.

How to Reduce Hallucination

• Provide reliable material;
• Require citations (state which passage a conclusion comes from);
• Allow the answer "can't confirm";
• Separate fact extraction from suggestion generation;
• Human-review high-impact conclusions.

Token & Context Window: How Much the Model Sees at Once

A Token is the basic unit a model uses to process text; it's not exactly one word/character. In Chinese one character may be one or several tokens; code and punctuation are also billed separately. The context window is the total amount of input, conversation history and output the model can handle in one inference.

Think of tokens as the model's short-term memory capacity: what fits is visible; what doesn't must be dropped or compressed.

A Longer Context Isn't Always Better

Stuffing every file and months of conversation into one task can cause:

• Old requirements conflicting with new ones;
• Key material drowning in irrelevant content;
• Rising cost and wait time;
• The model citing a stale version.

The bigger the window, the easier it is to "flood the castle" — the important stuff gets diluted.

A Safer Approach

Organize "current rules, confirmed facts, decision records and this run's inputs" per project. For long projects, use files and project memory instead of relying on endless conversation.

In short: don't treat all chat history as a database. Persist what should be persisted; separate what should be separated by project.

Prompt: A Task Description, Not a Magic Spell

A prompt is the input to the model or Agent — goal, background, material, constraints, examples and output requirements. A good prompt wins by having enough info to execute and accept, not by length.

Writing a prompt isn't "chanting a spell"; it's writing a task slip a colleague could execute.

Six Elements

Element	Question to answer
Goal	What problem to ultimately solve
Input	Which materials or systems to use
Action	Analyze, organize, generate or write
Constraint	What not to do; what rules to follow
Output	What file or structure to deliver
Acceptance	How to judge it correct and usable

The most-neglected element is "acceptance": without acceptance criteria, the model just delivers against its own understanding, and you can't even say what's wrong.

Prompt, Task Card and SOP

• Prompt: what you say this time;
• Task card: a structure for filling in similar tasks;
• SOP: fixed steps, roles, checkpoints and exception handling;
• Skill: packages a stable SOP, scripts and resources into an executable capability.

These four are progressive hardening from "one-off description" to "reusable capability".

Not every prompt deserves to become a Skill. First repeat success, then harden gradually. For a task done only once, write a good prompt and get it working; once it's run smoothly three to five times and the pattern is stable, consider distilling it into a Skill.

Agent: An Executor That Loops Around a Goal

An Agent doesn't just "answer once"; it keeps running a loop: understand the goal, observe the environment, decide the next step, call a tool, read the result, revise the plan, until delivery or a stop condition.

flowchart TD
    A[Receive goal] --> B[Observe materials & state]
    B --> C[Plan next step]
    C --> D[Call tool to execute]
    D --> E[Read result & errors]
    E --> F{Done or should pause?}
    F -->|Continue| B
    F -->|Pause| G[Request human confirmation]
    F -->|Done| H[Deliver and accept]

A chat model is "you ask, it answers"; an Agent is "you give a goal, it advances step by step on its own, watching results and changing course mid-way".

Agent vs. Chat Model

Dimension	Chat model	Agent
Core action	Generate an answer	Plan, call tools, execute and deliver
Works on	Current conversation	Files, tools, systems and task state
Process	Usually one-shot generation	Multi-round observation & action
Risk	Wrong content	Wrong content + real-world side effects
Control	Prompts & review	Permissions, checkpoints, logs, rollback

The key difference is the last row: a chat model being wrong just misleads you; an Agent being wrong may actually delete files, send emails, alter a database. So an Agent doesn't need a smarter prompt — it needs harder guardrails.

An Agent's Stop Conditions

A good Agent shouldn't "always find a way to keep going". It should pause and ask a human when:

• A key input is missing;
• Goals conflict;
• Permissions are insufficient;
• Cost exceeds budget;
• An action is irreversible;
• The result can't be accepted.

Knowing when to stop and ask is more professional than always powering through alone. An Agent that won't stop is more dangerous than a dumb one.

Tool: Letting the Agent Actually Do Things

A tool is a concrete capability the Agent can call — read a file, run a search, generate a table, send a message. A connector is usually a pre-packaged third-party service connection in the product, emphasizing "use directly after authorization".

The Model Knowing ≠ the Model Doing

The model can explain "how to send an email", but only with an email tool and account permission can it actually create a draft or send. The model can write SQL, but only with the database tool, network and account allowed can it query.

This is what ordinary users most easily misunderstand: the model "knows" something doesn't mean it "can" do it. Whether it can depends on whether the corresponding tool, permission and connection exist. When a task fails, first ask "is the tool connected, is the permission granted", not "is the model no good".

Five Questions for Every Tool

1. Whose identity it uses;
2. What it can read;
3. What it can modify;
4. Where the data goes;
5. How to stop and roll back on failure.

Skill: Reusable Professional Working Methods

A Skill isn't a smarter model; it organizes the instructions, scripts, knowledge and templates a class of tasks needs, so the Agent completes actions more stably.

A Skill's value isn't "making the model stronger", it's "locking down steps that are easy to get wrong or skip". For the same invoice handling, letting the model write it fresh each time may produce three different approaches in ten runs; written as a Skill, ten runs take one verified path.

A Skill May Contain

invoice-skill/
├── SKILL.md          # trigger conditions, steps, boundaries, output
├── references/       # fields, categories, business rules
├── scripts/          # OCR, validation, table processing
├── templates/        # Excel and report templates
└── tests/            # normal and exception samples

SKILL.md is the entry, telling the Agent "when to use me, how, where the boundary is"; references holds business knowledge; scripts holds the code that actually executes; templates keeps output formats consistent; tests makes sure exceptions are covered too.

Skill vs. Prompt

A prompt usually only affects this conversation; a Skill can be called by different tasks and can carry scripts, resources and a stable flow. But a Skill can still be wrong, and may still request local, network or third-party permissions.

Remember: a Skill is "method packaging", not a "capability guarantee". Installing a Skill makes the Agent more likely to take the right path, not immune to error forever.

Risks of Installing Third-Party Skills

• Reading unnecessary local directories;
• Sending input material out;
• Grabbing API keys or accounts;
• Running system commands;
• Holding malicious prompts or code;
• Depending on stale, unmaintained code.

So check the source, code, permissions, network, credentials, cost and how to disable it, and test first in an isolated directory. Third-party Skills are like browser extensions: convenient, but first see what permissions they want.

MCP: The Standard Interface Letting AI Plug Into Tools and Data

MCP is Model Context Protocol. It specifies how an AI client discovers and calls external tools, reads resources, or gets prompt templates — you can think of it as a class of standard interface for the AI tool ecosystem.

Think of MCP as "the USB port of the AI world": tool providers expose capabilities by one standard, AI clients use them by the same standard, no per-vendor rework.

What MCP Solves

If every AI product had to build a dedicated connection for every system, integration cost would be high. MCP lets tool providers and AI clients describe capabilities in a unified way, cutting repeat adaptation.

Without MCP, connecting a CRM means one adapter, a database means another; with MCP, the tool side exposes once by the standard, and all MCP-supporting clients can use it directly.

What MCP Doesn't Solve

• Doesn't auto-judge whether data is compliant;
• Doesn't keep all your keys safe for you;
• Doesn't guarantee tool results are correct;
• Doesn't auto-implement identity and least privilege;
• Doesn't mean you can open up production writes once connected.

MCP solves "how to connect", not "whether it's safe or right after connecting". The safety layer is still your job.

User-Level vs. Project-Level

• User-level suits public capabilities reused across projects;
• Project-level suits client-, database- or business-specific tools.

For sensitive connections, prefer project isolation to avoid cross-project mis-calls. For example, the company's production database should only be connected inside the corresponding project, not as a global user-level item — otherwise an unrelated task might reach it too.

The Relationship Between API and MCP

An API is an interface for software to interact — e.g. querying data or creating records over HTTP. An MCP Server can internally call one or more APIs, then expose tools in a way that's easier for an Agent to use.

In one line: the API is the foundation, MCP is the door built on the foundation that the Agent can walk through directly. Agents usually don't deal with a pile of raw APIs directly; they call them indirectly through one MCP Server.

Use the API Directly or Use MCP

• Using the API directly is more flexible, but you must understand auth, params, errors and rate limits;
• Using a mature MCP is more convenient, but you still must review what requests and permissions it wraps.

Convenient isn't exempt from review. MCP saves you the adapter work, but "which APIs it calls behind the scenes and what permissions it uses" — you must keep that in mind.

Knowledge Base, RAG and Memory

These three all relate to "what the AI relies on", but what they store and how they go stale differ completely.

Knowledge Base

Stores retrievable policies, products, cases, SOPs and other material. It solves "what the AI relies on", not "the AI remembers everything forever".

The knowledge base is an external reference room; the model flips through it only when used, and doesn't guarantee it remembers next time.

RAG

RAG is Retrieval-Augmented Generation. The system first finds relevant chunks in the material library, then feeds them to the model to answer. Quality depends on the material, chunking, metadata, retrieval and citation.

RAG isn't "connect a knowledge base and it gets smart" — it's a chain: bad material, bad chunking, skewed retrieval, and the answer drifts with it. The citation mechanism matters — being able to point to which passage a conclusion comes from is how you decide whether to trust it.

Memory

Memory stores preferences, long-term rules, project decisions or historical state. Wrong memory gets amplified repeatedly, so important info needs a source, date, owner and update mechanism.

The most dangerous thing about memory is "it doesn't notice its own expiry". A wrong rule from half a year ago will be treated as truth by the Agent, over and over.

How the Three Differ

Concept	What it stores	Main risk
Conversation context	Current task exchange	Too long, conflicting, stale
Knowledge base / RAG	Retrievable facts & material	Bad source, stale version, not retrieved
Memory	Preferences, long-term rules, project state	Errors carried long-term

In one line: context is this chat's short-term memory, the knowledge base is a reference room you can query anytime, memory is the long-term settings kept across tasks.

Workflow vs. Agent

The Agent is clear now, but there's another often-conflated term: Workflow. It and the Agent aren't substitutes; they're two ways to "organize action".

In One Line

• Workflow is a standardized production line: steps are fixed at design time and run in order or by branch.
• Agent is a thinking executor that can make its own calls: you only give a goal, and at runtime it decides the next step.

By analogy, a Workflow is an SOP that says "step 1 do A, step 2 do B, after B passes do C else do D"; an Agent is a person you hire — you only say "process this batch of invoices" and he judges mid-way which to check first and asks you when stuck.

Core Difference: Where the Decision Power Sits

In a Workflow, every "which path" is fixed at design time; in an Agent, the next step is decided by the model at runtime based on the environment. That's the essential difference; other differences grow from it.

Comparison Table

Dimension	Workflow	Agent
In one line	Standardized production line	Thinking executor that makes its own calls
Path preset?	Yes, steps fixed at design	No, decided at runtime by environment
Decision timing	Fixed at design	Dynamic at execution
Who picks next step	The flow definition	The model itself
Controllability	High, easy to predict and roll back	Lower, path may vary
Debug difficulty	Low, steps clear and traceable	High, needs logs and intermediate state
Suited scenes	Clear steps, repeatable, high compliance	Uncertain path, needs env feedback, open goals
Typical failure	Stuck on a step, branch not covered	Drifts, infinite loop, over-permissioned action
Relation to LLM	Pipeline can embed a model, but control flow is human-defined	The model drives control flow

When to Use Workflow

• Fixed SOP, e.g. "receive ticket → classify → assign to the right person";
• Batch processing, e.g. "compress and watermark 100 images uniformly";
• Compliance approval, every step needs a traceable audit record;
• Repeatable report generation.

These have clear paths; Workflow is steadier, cheaper and easier to audit.

When to Use Agent

• Clear goal but unclear path, e.g. "research competitors and produce a comparison report";
• Needs multi-tool exploration, deciding mid-way after seeing results;
• The environment changes, needing to adjust as it goes;
• Strongly open-ended tasks hard to write as fixed steps.

Common Misconceptions

• "An Agent is always stronger than a Workflow": no. For certain tasks, Workflow is steadier and cheaper; forcing an Agent is easier to drift, harder to audit and costlier.
• "A Workflow can't contain intelligence": wrong. A Workflow's nodes can absolutely call a model to summarize, classify or extract; it's just that "which path" is still decided by the flow.
• "Fully-autonomous Agent is best": over-delegating makes failures harder to locate. Truly complex systems often have an Agent doing high-level decisions while handing stable steps to Workflows.

How the Two Cooperate

It's not either-or, but nested:

• Agent contains Workflow: the Agent writes stable subtasks as fixed flows (e.g. a Skill is backed by a Workflow), only judging itself at uncertain points;
• Workflow node calls Agent: on a production line, a decision node hands non-structured input to an Agent.