LIN CHIACHENG
KENLIN LAB / FIELD NOTE 006ARTICLE / 006

SYSTEMS PRIMER / 2026

Your AI is more than a model.

The model is only part of the experience. Tools, execution, memory and verification turn answers into work you can actually review.

MODEL·AGENT·HARNESS·TOOLS
Start readingView system map
Concepts / Tools / Practice15 CHAPTERS / 4 PATHS
SYSTEM ARCHITECTURE / SYSTEM OVERVIEW

Start with the whole AI system, then explore the terms.

This is not a ranking. It explains what works together when AI takes on a real task.

01MODELReason
02CONTEXTInformation
03PROMPTGoal
04AGENT + TOOLSAct
05HARNESSRun
06VERIFYCheck

These are conceptual roles, not a single mandatory product architecture.

START HERE / AI FOUNDATIONSThe fundamentals: how an LLM writesNew here? Tokens, training, inference and hallucinations＋
AI FOUNDATIONS / EXPLAINED

The fundamentals: how an LLM writes

Before agents, MCP and harnesses, understand what happens when you type a question.

This is not a product ranking. We'll move from models and tokens to external information, tools, execution and verification.

Four layers to understandAI SYSTEM / READING GUIDE
01 / FoundationsHow does a model respond?LLM, tokens, training and inference
02 / ConnectionsHow does AI use information?Context, RAG, API, MCP and skills
03 / ActionFrom answers to real workPrompt, agent, CLI and harness
04 / QualityHow do we verify the work?Testing, evals, guardrails and proactive AI

How a model produces a response

  1. 01Your input

    For example: Explain MCP.

  2. 02Tokenization: text bricks

    Words, word parts and punctuation become token units that affect usage and cost.

  3. 03Inference: the next token

    The model uses learned weights and context to predict and generate successive tokens; tools may add live information.

  4. 04Answer

    A fluent response is not a guarantee of factual accuracy.

01 / BEFORE USETraining

The model learns patterns from data and updates its parameters, generally before deployment.

02 / WHILE USINGInference

On your question, it uses learned weights plus current context to generate a response.

An LLM is not automatically a live search engine. RAG and tools can supply evidence; agents and runtimes support real work.

01

I asked for a button fix. Why did the layout move too?

A confident completion message is not a test report.

I have asked AI to fix one mobile button and received a confident 'done', only to discover the navigation was now broken. A plausible answer is different from a verified outcome.

The missing piece is often not intelligence alone. We are using a system of models, context, tools, execution loops and checks—not just a model.

Fixed?What about mobile?
FIG 01 / Illustrative scenario: a change is not a verification

02

Model: the brain is only one layer.

The same model can behave differently across tools.

Models such as GPT, Claude and Gemini provide reasoning and generation. Products such as ChatGPT, coding agents and CLIs add interfaces, permissions and runtime behavior.

Within the official API catalog, GPT-6 Astra targets demanding reasoning, GPT-6.1 Sol balances capability and cost, GPT-6.1 Terra favors visual reasoning and computer use, and GPT-6 Luna suits efficient, high-volume tasks. These are models, not interfaces; availability varies by product.

02 / VISUAL NOTEMODEL / PRODUCT / EXECUTION
MODELREASON / GENERATE
CAPABILITY ≠ EXPERIENCE

Same brain, different work environment.

OpenAIClaudeGoogleDeepSeek
CHAT APP+AGENT+TOOLS
Products and models are different layers.
FIG 02 / MODEL FAMILY

Four GPT models, four useful trade-offs

Model capability, speed and cost vary. A model is neither the app nor the harness running it.

01 / MODELAstraGPT-6 Astra

Deep reasoning and difficult professional work

Research and complex architecture
02 / MODELSolGPT-6.1 Sol

Strong capability with balanced cost

Complex coding and document workflows
03 / MODELTerraGPT-6.1 Terra

Visual reasoning and computer use

Screen interactions and clear writing
04 / MODELLunaGPT-6 Luna

Fast, economical, high-volume tasks

Classification, extraction, repetitive work
These are official API model positions. Product availability and names vary by rollout and plan. OPENAI MODEL GUIDE ↗
EVOLUTION / 2022—2026AI did not become an operator overnight.
  1. 2022
    NOV 30Chat-first
    OpenAI

    ChatGPT brought conversational AI to a broad audience.

    WHAT CHANGEDHumans copy and paste answers into work.

    SOURCE ↗
  2. 2023
    JUN 13Function Calling
    OpenAI

    Structured tool integration becomes more accessible.

    WHAT CHANGEDAI gains a route to external actions.

    SOURCE ↗
  3. 2024
    NOV 25MCP released
    Anthropic

    An open protocol to connect AI to tools and data.

    WHAT CHANGEDA shared socket for tool connections.

    SOURCE ↗
  4. 2025
    MAR 11Agent tooling
    OpenAI

    SDK, tracing and guardrails become composable building blocks.

    WHAT CHANGEDMore agents can work inside real projects.

    SOURCE ↗
  5. 2026
    AUG–SEPPersistent agents
    Dots / OpenAI

    Grok Bot, Muse and dots highlight work beyond chat.

    WHAT CHANGEDPersistent help with review; harnesses predate 2026.

    SOURCE ↗
Selected dated milestones from official releases, not the birth date of each technology.

03

Context, Memory, RAG: three different ways to handle knowledge.

Current workspace, saved notes, and the document archive.

The context window is the model's desk. A bigger desk does not help if the entire library hides the relevant page: long contexts can dilute attention (context rot), increase token costs and latency.

Memory is a notebook kept across sessions; RAG fetches relevant pages from the archive as needed. Curated evidence matters more than filling the desk, and retrieved sources can still be wrong.

03 / VISUAL NOTECONTEXT / MEMORY / RAG
● ● ●OPEN TABS / CURRENT CONTEXT
DocsChatCodeTestNotes
CONTEXT WINDOW / LIMITED
MEMORYSaved context
RAGRetrieve on demand

04

Prompt engineering: less incantation, more clarity.

Goals, context, boundaries and acceptance criteria.

Older models often benefited from detailed step-by-step prompts. For stronger agents, redundant micromanagement can become friction.

A useful brief specifies the outcome, context, allowed actions and testable definition of done. High-risk tasks still warrant explicit detail.

FIG 04 / PROMPT / BEFORE & AFTERKENLIN LAB
GOAL / BOUNDARIES

Fix mobile navigation. Keep the visual language, don't touch unrelated features, verify desktop and 375px, show evidence and do not deploy.

The point isn't shorter prompts: specify goals, context, boundaries, and acceptance.

05

Agent: from advice to actions.

Reason, call a tool, observe, continue.

An agent can take action through tools: inspect code, edit files, run tests, and respond to results. Tool calling connects model decisions to external execution.

A subagent is another worker delegated a bounded task; orchestration is the coordination layer. More agents do not automatically mean better outcomes.

05 / VISUAL NOTEAGENT / WORK LOOP
PROJECT / MOBILE NAVLOCAL
$ agent runFix the mobile navigation.
  • 01READsrc/components/Nav.tsx✓
  • 02EDITresponsive styles✓
  • 03TESTPlaywright · 375px✓
  • 04REPORTdiff + screenshots◯

06

API vs MCP: interfaces and conventions.

MCP standardizes discovery, not permission.

An API exposes operations from a service. MCP standardizes how compatible AI clients discover and invoke tools, resources and prompts.

Direct API integration may require each app to maintain service-specific adapters. With MCP, a host uses client connections to compatible servers, which may wrap the same APIs. A shared protocol reduces duplicated connection conventions but does not grant credentials or permissions.

FIG 06 / API × MCP

Same GitHub destination. Different connection design.

01 / DIRECT INTEGRATIONAPI / Custom integration per app

Each app handles the service API, parameters and authentication directly.

App AAI applications / agents
GitHub API ↗Google API ↗Slack API ↗
App BAI applications / agents
GitHub API ↗Google API ↗Slack API ↗
Custom adapters in each appGitHub API · Google API · Slack API

Every app must maintain its own service-specific connection.

02 / STANDARD PROTOCOLMCP / Common tool protocol

Compatible hosts use their own MCP clients to connect to servers through a shared protocol.

CodexMCP Host
Claude CodeMCP Host
OpenCodeMCP Host
An MCP Client per ServerShared MCP protocol
GitHub Server
Google Server
Slack Server

Each server connects to its underlying API

The connection contract is reusable, but credentials and permissions still need configuration.

Conceptual view: hosts typically maintain one client connection per server. MCP does not replace every API or grant access automatically. MCP ARCHITECTURE ↗

07

Skills: reusable ways of working.

Package instructions, references, and scripts.

A skill packages repeatable procedures, references and scripts. In the open Agent Skills format, SKILL.md describes when and how to use it.

Skills provide working methods, whereas MCP provides a connection protocol. Load relevant skills when needed rather than all at once.

07 / VISUAL NOTESKILLS / REUSABLE METHODS
▤ SKILL.md01
---
name: responsive-qa
description: Validate RWD
---

## When to use
After a UI change

## Check
375px · tablet · desktop
TRIGGEROnly when relevant
FOLLOWRules + templates
VERIFYConcrete evidence

08

CLI and coding agents: more than a terminal prompt.

An interface is not the same as its underlying model.

CLI stands for command-line interface. Commands such as codex, claude, opencode, agy and dsh are entry points into different coding-agent products.

Codex CLI, Claude Code, OpenCode, Google Antigravity CLI and DeepSeek Harness differ in runtime design, provider support, permissions and interface—not just the model behind them.

Codex names the coding-agent product: Codex CLI is its terminal interface, the Codex Harness runs the agent loop, and GPT models supply reasoning. A CLI is an interaction surface, not the agent runtime. Codex can reuse its harness across interfaces, while dsh launches a composed profile. Ordinary commands like git or npm are also CLIs, but not AI harnesses.

FIG 08 / CLI · PRODUCT · HARNESS

Is Codex a CLI, or a harness?

Codex is a coding-agent product and workflow. Codex CLI is its terminal entry point; Codex Harness runs the agent; GPT models provide reasoning. These are layers, not rival products.

01 / How do I interact?Codex CLI / IDE / App
02 / What runs the task?Codex Harness
03 / What supplies reasoning?GPT Model + Tools

You interact through the CLI, IDE or app. The harness handles files, tools, task state and approvals, while the model reasons over the task.

Other familiar coding-agent products
Codex CLI / OpenAIClaude Code / AnthropicOpenCode / Open Source
git and npm also have CLIs; a CLI is not automatically an AI agent. Each coding-agent product has its own runtime design, not necessarily the Codex Harness. OPENAI / CODEX HARNESS ↗
FIG 08 / CLI & HARNESSA CLI is not a model. Compare the layers.
OPENAI / TOOL PROFILE

Codex CLI

CLICODING AGENTHARNESS
$ codex

OpenAI's terminal coding agent for inspecting, editing and testing repositories.

● ● ●WORKSPACE / AI AGENT
$ codex "Review this repository"

▸ Read project instructions

▸ Inspect files and propose changes

✓ Report evidence before release

Best for
Scoped changes and validated codebase work.
Key difference
OpenAI Codex workflow; the CLI is not a model name.
Watch out
Check directory scope, write permissions and evidence.
Where it fits
Terminal / Git repository
Official documentation
The symbols are editorial identifiers, not official product logos. Check current product documentation.

09

Harness: the runtime around intelligence.

Tools, state, execution loop, recovery, validation.

A harness coordinates tools, the agent loop, state, permissions and review. A sandbox is a controlled lab, not absolute isolation; host mounts can still create risks. Git history can help reverse tracked changes, but not every uncommitted file or external side effect.

This is one reason the same model can feel different in Codex, Claude Code, OpenCode or another coding environment.

For example, the Codex CLI, IDE extension and app can use the same underlying harness. OpenCode manages its tools and permissions in its runtime, while DeepSeek Harness composes model adapters, tools, sessions and the agent loop through plugins and profiles.

FIG 09 / HARNESS IN PRACTICE

The harness is already inside the tools you use.

These products may have similar command-line entry points, but their execution systems differ.

01 / Interaction surface
Codex CLIIDE ExtensionCodex App
02 / Execution systemCodex Harness / Agent LoopSTATE → TOOL CALL → OBSERVE → NEXT STEP
Model reasoning
Tools, sandbox, approvals
OpenAI / CODING AGENT

The CLI, IDE extension, and app can use the same underlying Codex harness.

What sets it apartDifferent interfaces can share an agent harness.

The CLI is one interface—not the whole execution system.

Official documentation
Conceptual illustration, not a literal source-code diagram or performance ranking.

10

AGENTS.md and DESIGN.md: make decisions reusable.

Repository rules and design rules are different.

AGENTS.md gives coding agents repository instructions: stack, tests, restricted operations and review rules.

DESIGN.md can preserve visual language such as type, spacing and components. It is not a universally enforced file; your tool must actually read and use it.

10 / VISUAL NOTEREPOSITORY / DESIGN LANGUAGE
▤ENGINEERINGAGENTS.md

Next.js / TypeScript

Testing & boundaries

▤VISUAL SYSTEMDESIGN.md

Type scale / color tokens

Spacing & components

11

Computer use: interface actions, not magic.

Choose the most reliable interaction surface.

Computer use lets an agent inspect a graphical interface and interact through clicking, typing and navigation. It is useful where APIs are unavailable, but can misinterpret the screen.

Playwright supports structured, reproducible browser automation. Prefer APIs when available, browser testing for tests, and GUI actions when the interface is the only route.

11 / VISUAL NOTECOMPUTER USE / BROWSER ACTIONS
● ● ● DEMO WEBSITE / DASHBOARD
Overview　　 Settings　　 Reports
↖
01SEEScreenshot / DOM
02ACTClick / type / scroll
03CHECKObserve new state

12

Testing, Evals, Guardrails: require evidence.

Did it work? Was it good? Was it allowed?

Testing verifies software behavior. Evals measure agent performance across tasks; tracing records tool calls and failure paths.

Guardrails and permission checks reduce risky behavior. Human-in-the-loop approval keeps consequential actions under human control. A green test only covers what was tested.

12 / VISUAL NOTETESTING / EVALS / GUARDRAILS
VALIDATION BOARD
BuildPASS
BrowserCHECK
Agent evalREVIEW
ProductionAPPROVAL
Green checks only prove what was tested.

Show coverage, gaps and approval steps.

13

Practical starter kit: which skills and MCPs matter?

A light tool belt: documentation, browser checks and version control.

Start with a light tool belt: Context7 or official docs for current APIs, Playwright for responsive browser checks, and GitHub for issues and PRs. Pick what the task actually needs; three is a starting example, not a magic number.

Build your own skills around repeated QA and publishing work. Grant MCP integrations the least privilege possible—read-only first, then explicit approval for writes or releases. Unnecessary tools can add context overhead, confusion and prompt-injection exposure; reference MCP servers are not production-security guarantees.

13 / VISUAL NOTESTARTER TOOLKIT / LESS IS MORE
01DOCS / CONTEXT7Latest APIs · read first
02PLAYWRIGHT MCPBrowser / mobile QA
03GITHUB MCPIssues / branches / PRs
LEAST PRIVILEGE

Enable only needed tools, begin read-only, and approve consequential changes.

Capture repeatable RWD and localized publishing checks in your own SKILL.md.

14

Proactive AI: work beyond the chat window.

Different products, different execution models.

Proactive agents may use schedules, event triggers, persistent state and tools to pursue long-term goals. The model need not literally run continuously.

Dots, Muse and Grok Bot package persistent cloud-agent experiences in different ways; OpenClaw emphasizes self-managed gateways, tools and runtime.

FIG 14 / PERSISTENT AGENTSFour ways to organize persistent work
01 / OPENAI
Dots

Cloud computer, connected apps and ongoing goals.

2026 / SEP 29
02 / META
Muse

Dedicated secure VM and browser across apps.

2026 / SEP 08
03 / xAI
Grok Bot

Persistent bots with computers and handoffs.

2026 / AUG 11
04 / SELF-MANAGED
OpenClaw

Self-managed gateway, models, tools and permissions.

SELF-HOSTED ROUTE
Always-on work does not mean continuous model inference or unlimited access.

15

My working setup: the parts I actually use.

Start from the task and its proof of completion.

I choose a coding environment according to the task, keep project rules in AGENTS.md and DESIGN.md, and validate browser changes with real tests.

I treat agy and DSH as environments to study, not automatic replacements for tools I already use. For ongoing tasks I use persistent agents selectively, while releases, payments and destructive actions retain an approval step.

FIG 15 / FIELD WORKFLOWMy working workflow
  1. 01
    Define the job

    Set outcome, boundaries and acceptance.

  2. 02
    Choose the agent

    Select Codex, OpenCode or another fit for the task.

  3. 03
    Preserve rules

    Maintain AGENTS.md and DESIGN.md.

  4. 04
    Collect evidence

    Check browser states, tests and diffs.

  5. 05
    Approve

    Keep releases and destructive operations under review.

I care less about the claim of completion and more about evidence of the result I actually wanted.