WorkBuddy Practical: 10a - Reading: AI Work Systems Explained

LLM: the base model that predicts content from context

LLM means Large Language Model. It learns patterns of language and knowledge from large volumes of data and generates the most likely continuation from the current input.

It is an engine for “predicting the next content,” not a database and not a person who assumes responsibility for you.

What it does well

• Understand, summarize, and rewrite text;
• Extract structure from source material;
• Generate drafts, plans, and code;
• Imitate formats and styles from examples;
• Continue analyzing after a tool returns results.

What it does not guarantee by itself

• That every fact is correct;
• Knowledge of a company's latest internal state unless materials or a connected system are provided;
• Real evidence merely because the language sounds confident;
• Automatic access to files, accounts, databases, or the network;
• Business or legal responsibility.

Why do hallucinations happen?

The model's objective is coherent generation, not consulting an internal fact database. When material is missing, a question is ambiguous, or a definite answer is demanded, it may fill the gap with content that sounds reasonable but is not true.

This is a side effect of probabilistic completion, not necessarily a software bug. Once this is understood, “it sounded so certain—why was it wrong?” becomes easier to answer: confidence and correctness are separate properties.

Ways to reduce hallucinations

• Provide reliable source material;
• Require citation locations and state which passage supports a conclusion;
• Allow the answer “cannot confirm”;
• Separate fact extraction from recommendation generation;
• Manually review high-impact conclusions.

Tokens and the context window: how much can the model see?

A token is a basic unit the model processes and is not exactly the same as a character count. In Chinese, one character may correspond to one or more tokens; code and punctuation can also be counted separately. A context window is the total amount of input, conversation history, and output that one inference can process.

Think of tokens as short-term memory capacity: the model can see what fits, while content that does not fit must be dropped or compressed.

Longer context is not always better

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

• Old requirements to conflict with new ones;
• Important material to be buried under irrelevant content;
• Higher cost and longer waiting time;
• The model to cite an outdated version.

A larger window can make important information harder to see when it is drowned in irrelevant context.

A safer approach

Organize each project around current rules, confirmed facts, decision records, and the current input. For long projects, use files and project memory instead of relying on an infinite conversation.

In short, do not treat the entire chat history as a database. Persist what should persist and separate what belongs to different projects.

Prompt: a task specification, not a magic spell

A Prompt is the input given to a model or Agent. It includes goals, background, materials, constraints, examples, and output requirements. A good prompt is not judged by length; it is judged by whether it contains enough information to execute and accept the result.

Writing a prompt is writing a task card that a colleague could execute, not reciting an incantation.

Six elements

Acceptance is the element people most often omit. Without an acceptance standard, the model can only satisfy its own interpretation, leaving no precise way to say what is wrong.

Prompt, task card, SOP, and Skill

• Prompt: what to say this time;
• Task card: a fillable structure for a recurring task;
• SOP: fixed steps, roles, checkpoints, and exception handling;
• Skill: an executable package containing a stable SOP, scripts, and resources.

These are successive levels of consolidation, from a one-off explanation to a reusable capability.

Not every prompt deserves to become a Skill. Repeat a task successfully first, then consolidate it. A task completed once can start with a good prompt; after three to five successful runs with a stable pattern, consider turning it into a Skill.

Agent: an executor that can act in a loop around a goal

An Agent does more than answer once. It continuously understands the goal, observes the environment, decides the next step, calls a tool, reads the result, adjusts the plan, and continues until delivery or a stop condition.

A chat model is “you ask, it answers.” An Agent is “you give it a goal; it advances step by step, checks results, and changes course when needed.”

Agent versus chat model

The last row is the hard distinction. A chat model that is wrong may mislead you; an Agent that is wrong may delete a file, send an email, or change a database. Agents therefore need stronger guardrails, not merely smarter prompts.

Agent stop conditions

A good Agent should not “find a way to continue forever.” It should pause and ask a person when:

• A critical input is missing;
• Goals conflict;
• Permissions are insufficient;
• The cost exceeds the budget;
• The action is irreversible;
• The result cannot be accepted.

Knowing when to stop and ask is more professional than forcing every task through. An Agent that never stops can be more dangerous than one that is simply less capable.

Tool: letting an Agent actually do things

A Tool is a concrete capability an Agent can call, such as reading files, searching, generating a spreadsheet, or sending a message. A Connector is usually a productized connection to a third-party service that can be used after authorization.

Knowing is not the same as being able to do

The model can explain how to send an email, but it can create a draft or send it only if it has an email tool and account permission. It can write SQL, but it can query a database only when the database tool, network, and account allow it.

This is the most common misunderstanding: a model “knowing” how to do something does not mean it “can” do it. Ability depends on the tool, permission, and connection. When a task fails, first ask whether the tool and permission are working rather than assuming the model is incapable.

Five questions for every tool

1. Under whose identity does it run?
2. What can it read?
3. What can it modify?
4. Where will the data be sent?
5. How does it stop and roll back after failure?

Skill: a reusable professional method

A Skill organizes the instructions, scripts, knowledge, and templates needed for a category of work so the Agent can execute it more consistently.

The value of a Skill is not making the model “smarter,” but fixing steps that are easy to miss or get wrong. If invoice processing is improvised every time, ten runs may produce three different methods; a Skill can make all ten follow a validated path.

A Skill may contain

invoice-skill/
├── SKILL.md          # Triggers, steps, boundaries, and output
├── references/       # Fields, categories, and business rules
├── scripts/          # OCR, validation, and spreadsheet processing
├── templates/        # Excel and report templates
└── tests/            # Normal and exceptional examples

SKILL.md is the entry point. It tells the Agent when to use the Skill, how to use it, and where its limits are. references contains business knowledge, scripts contains executable code, templates keeps output consistent, and tests covers exceptional cases.

Skill versus Prompt

A Prompt usually affects one conversation. A Skill can be called by different tasks and carry scripts, resources, and a stable process. A Skill can still fail and may request local, network, or third-party permissions.

A Skill is a method package, not a capability guarantee. Installing one makes the Agent more likely to follow the right path; it does not make errors impossible.

Risks of installing a third-party Skill

• Reading unnecessary local directories;
• Sending source material outside the workspace;
• Requesting API keys or account access;
• Executing system commands;
• Including malicious prompts or code;
• Depending on outdated or unmaintained components.

Check the source, code, permissions, network access, credentials, cost, and disable method, then test in an isolated directory. A third-party Skill is like a browser extension: useful, but its requested permissions should be reviewed first.

MCP: a standard interface for connecting AI to tools and data

MCP means Model Context Protocol. It defines how an AI client discovers and calls external tools, reads resources, or obtains prompt templates. It can be understood as one standard interface in the AI-tool ecosystem.

Think of MCP as a USB interface for the AI world: providers expose capabilities in one standard way, and AI clients use the same standard rather than implementing a separate adapter for every provider.

What does MCP solve?

If each AI product needs a dedicated connection for every system, integration is expensive. MCP lets providers and clients describe capabilities in a common way and reduces repeated adaptation.

Without MCP, a CRM and a database each require a separate adapter. With MCP, a provider exposes its tool once and every MCP-compatible client can use it.

What MCP does not solve

• It does not automatically decide whether data is compliant;
• It does not securely manage every secret for you;
• It does not guarantee correct tool results;
• It does not automatically implement identity and least privilege;
• A connection does not mean production writes should be open.

MCP solves “how to connect,” not whether the connection is safe or correct. That layer remains your responsibility.

User-level and project-level configuration

• User-level is for shared capabilities reused across projects;
• Project-level is for customer-, database-, or business-specific tools.

Prefer project isolation for sensitive connections. A company's production database should be connected only in the relevant project, not exposed globally where an unrelated task could reach it.

The relationship between APIs and MCP

An API is an interface for software-to-software interaction, such as querying data or creating records over HTTP. An MCP Server can call one or more APIs internally and expose them as tools that an Agent can use more easily.

In one sentence: the API is the foundation; MCP is the door built on that foundation for an Agent to enter and use. An Agent usually does not talk to many raw APIs directly; it calls them indirectly through an MCP Server.

Direct API or MCP?

• Direct API use is more flexible but requires understanding authentication, parameters, errors, and rate limits;
• A mature MCP is more convenient, but its wrapped requests and permissions still need review.

Convenience is not exemption from review. MCP saves adapter work, but you still need to know which APIs it calls and which permissions it uses.

Knowledge bases, RAG, and memory

All three relate to what an AI relies on, but they store different things and fail in different ways.

Knowledge base

A knowledge base stores searchable policies, products, cases, SOPs, and other materials. It answers “what should the AI rely on?” It does not mean the AI remembers everything forever.

A knowledge base is an external reading room. The model consults it when needed, and consulting it once does not guarantee permanent memory.

RAG

RAG means Retrieval-Augmented Generation. The system first finds relevant passages in a source library and then provides them to the model. Results depend on source quality, chunking, metadata, retrieval, and citations.

RAG is not “connect a knowledge base and become smart.” It is a chain: weak sources, poor chunking, or biased retrieval produce a weak answer. Citations matter because they show which passage supports a conclusion.

Memory

Memory stores preferences, long-term rules, project decisions, or historical state. An incorrect memory can be amplified repeatedly, so important information needs a source, date, owner, and update process.

The dangerous part of memory is that it does not notice expiration by itself. An incorrect rule from six months ago can be reused as truth by an Agent.

The difference

In one line: context is short-term memory for this chat, a knowledge base is a searchable reading room, and memory is a long-term setting retained across tasks.

Workflow versus Agent

One term is often mixed up with Agent: Workflow. The two are different ways of organizing action; neither simply replaces the other.

The one-line distinction

• A Workflow is a standardized production line: steps are fixed during design and run in sequence or branches.
• An Agent is an executor that can think and choose: it receives a goal and decides how to proceed during execution.

A Workflow is an SOP that says “do A, then B; if B passes, do C, otherwise D.” An Agent is a person hired to finish a batch of invoices who decides which one to inspect first and asks when blocked.

The core difference: where is decision power?

In a Workflow, the route is fixed at design time. In an Agent, the model chooses the next action during execution according to the environment. This is the fundamental difference; the other differences follow from it.

Comparison

When to use a Workflow

• A fixed SOP, such as “receive ticket → classify → assign”;
• Batch processing, such as compressing and watermarking 100 images;
• Compliance approval in which every step must be recorded and auditable;
• Repeatable report generation.

These tasks have a clear path, so a Workflow is more stable, cheaper, and easier to inspect.

When to use an Agent

• The goal is clear but the path is not, such as researching competitors and producing a comparison report;
• Multiple tools must be explored and the next step depends on results;
• The environment changes during execution;
• The task is open-ended and difficult to express as fixed steps.

Common misconceptions

• “An Agent is always stronger than a Workflow.” Not correct. A known task is more stable and cheaper as a Workflow; forcing an Agent into it makes drift and auditing harder.
• “A Workflow cannot contain intelligence.” Wrong. A Workflow node can call a model for summarization, classification, or extraction; the flow still decides which path to take.
• “Fully autonomous Agent execution is always best.” Too much autonomy makes failures harder to locate. Complex systems often let an Agent make high-level decisions while stable parts remain Workflows.

How can they work together?

They can be nested rather than treated as mutually exclusive:

• Workflow inside an Agent: the Agent turns a stable subtask into a fixed process, such as a Skill backed by a Workflow, and makes decisions only where the path is uncertain;
• Agent at a Workflow node: a production line delegates one non-structured judgment to an Agent.