Eight Questions on Agents
What each component solves, what state it owns, and what breaks when you remove it.
Contents
PART 01
What exactly is an agent?
Answer
An agent is not a model or a chat window. It is a running system that repeatedly reads context, decides what to do next, uses available capabilities, observes the result, and continues until it completes, fails, or reaches a stop condition.
Formula A — auditable
Agent=
Model+
Agent Loop+
Context / State+
Capabilities+
Runtime Controls
Breaks the agent into parts that can each answer “what state does it own, who calls it.” Use this one for architecture review.
Formula B — engineering shorthand
Agent=
Model+
Harness
Shorter but more abstract. A harness is broader than one agent — it is the engineering system that supports agent execution, and it often manages the loop, tool access, context, memory, permissions, logs, retries, and recovery.
Model ≠ AgentSo: the model is the reasoning core of an agent, but the model alone is not an agent. An agent exists when the model operates inside a continuing runtime that can manage state, take action, and process results.
PART 02
How should the components of an agent system be classified?
Answer
Use three questions: What capability does it provide? How does it move the task forward? What part of execution does it manage?
Layer 01 · Capability
What can the system do?
Answers what the system is able to provide or perform.
- Model
Understands, generates, judges, plans, produces structured output - Skill
Domain knowledge, rules, methods, and checklists - Tool
Performs one specific, verifiable action - MCP server
Exposes tools, resources, or prompt templates over a standard protocol - API server
Stable business functions or data interfaces - Memory
Stores and retrieves past facts, preferences, experience, state
Layer 02 · Procedure
What happens next?
Answers how the task moves forward.
- Agent loop
Repeats decision, action, and observation during one task - Workflow
Fixed steps, branches, parallel work, approvals, retries, compensation - Cron / Trigger
Decides when, or on what event, execution starts
Layer 03 · Runtime
What runs and controls the system?
Answers who is responsible for execution and control.
- Harness
Assembles context, models, loops, capabilities, and controls - Session
Defines the state boundary of one continuous task or interaction - Bot / Channel
Receives user or platform events and returns results
The groups are not completely separateMemory is both a capability and state infrastructure; a harness is a runtime that also controls parts of the execution procedure. The point of the classification is to identify each component’s main responsibility, not to draw artificial boundaries.
What the three layers look like at runtime
PART 03
What problem does each of the twelve core components solve?
Answer
For each component, ask six things: what problem it solves, what it receives, what it produces, what state it owns, who calls it, and what it calls.
← table scrolls horizontally · left stripe = layer
| Component | Layer | What problem does it solve? | Input | Output | What state does it own or manage? | Call relationship |
|---|---|---|---|---|---|---|
| Model | Capability | How does the system understand, reason, generate, and plan? | Prompt, context, tool definitions, output constraints | Text, structured results, tool-call intent, stop signals | Usually temporary inference state only; it should not own persistent business state by default | The harness or loop calls it; it proposes tool calls but does not execute them directly |
| Agent loop | Procedure | How does the task continue? | Goal, current context, model output, tool results | Next action, final answer, failure or stop state | Current step, attempt count, stop reason, step limit | The harness starts it; it calls models, tools, or workflows |
| Skill | Capability | How should this type of task be done? | Current task, trigger conditions, existing context | Knowledge, rules, templates, instructions, checklists | Skill definition, version, metadata; usually not live task state | The harness or loop loads it; it guides the model’s method and tool choice |
| Tool | Capability | How does the system perform one clear action? | Parameters, credential context, execution options | Return value, error, external state change, artifact | Configuration and connection state; business state belongs to an external system | The model proposes the call, the harness executes it; it calls an API, database, or file system |
| MCP server | Capability | How are external capabilities connected in a standard way? | MCP initialization, discovery requests, call requests, arguments | Tool definitions, resources, call results, errors | Server configuration, connections, cache, backend sessions | An MCP client in the harness calls it; it calls APIs, SDKs, or local systems |
| API server | Capability | How are business functions and data provided reliably? | HTTP/RPC requests, authentication, business parameters | JSON, files, events, error codes | Business records, permissions, task state, cache, queues | Tools, MCP servers, or workflows call it; it calls databases and downstream services |
| Bot / Channel | Runtime | How do requests enter and results return? | Messages, attachments, commands, webhooks, platform events | Replies, cards, streams, status updates | Conversation mappings, platform message IDs, user identity, channel configuration | A user or platform calls it; it calls the harness and delivers the result |
| Cron / Trigger | Procedure | When does execution start? | Time, event, webhook, queue message, condition | An execution request or job | Schedule, deduplication key, last-run time, trigger configuration | A scheduler or event system calls it; it starts a harness, workflow, or API request |
| Workflow | Procedure | How should a fixed business process run? | Trigger input, variables, previous-step results | Step results, branch results, state, artifacts | Step state, retries, approvals, compensation, overall execution state | A trigger, harness, or workflow calls it; it calls agents, tools, APIs, or human approval |
| Session | Runtime | What is the boundary of one continuous task? | User messages, events, recovery requests | Current response, session state, pause or end state | History, working context, session ID, permissions, execution state | A channel or harness creates and restores it; a loop runs inside it and accesses memory |
| Memory | Capability | How is useful information kept across steps or tasks? | Content to store, queries, namespace, user or project ID | Relevant facts, summaries, preferences, historical state | Persistent records, indexes, metadata, retention period, source, confidence | The harness or loop calls it; it uses a database, vector store, or knowledge base |
| Harness | Runtime | How are separate parts assembled into a controlled, recoverable agent? | Requests, events, configuration, credentials, policies | Final responses, event streams, task state, logs, artifacts | Runtime configuration, permissions, context assembly, checkpoints, traces | Channels, triggers, or workflows call it; it coordinates models, loops, skills, tools, memory, and MCP |
PART 04
Where are the boundaries between the concepts people confuse most often?
Answer
The key questions are who makes the decision, who performs the action, and who manages the state. Seven distinctions matter most.
4.1
How is a model different from an agent?
A model receives input and produces output. An agent continues to act.
A model can produce text, structured data, or a request to call a tool. It normally does not execute the tool itself or persist task state. An agent adds an execution loop, tool execution, result feedback, context management, stop conditions, error handling, permissions, and — when needed — memory and recovery.
4.2
How is an agent different from an application?
An agent is a decision and execution unit inside a product. An application is the complete product.
Agent — one unit inside the product
Application — the complete product
A decision and execution unit that can be embedded or run on its own.
Application =
UI + Backend + Data + Auth
+ Agent + Workflow + Operations
The word “agent” should not stand in for the whole product.
An e-commerce operations application may also include:
- User interface and backend
- Data and authentication
- Organization permissions
- Reports and billing
- Audit logs
- Human approval
4.3
How is a harness different from an agent?
An agent is the running behavioral entity. A harness is the engineering infrastructure that lets such entities run reliably.
Agent — the behavioral entity
Harness — the infrastructure
- Has a goal
- Reads context
- Decides through a loop
- Takes action
- Assembles prompts, loads skills
- Exposes and executes tools
- Manages sessions and memory
- Enforces permissions and approvals
- Supports retries and recovery
- Records cost, latency, and traces
One to manyOne harness can run several agents. The same agent design can also run in different harnesses for chat, command line, background jobs, or test environments.
4.4
How is a skill different from a tool?
A skill explains how a type of task should be done. A tool performs a specific action now.
Skill — knowledge and procedural guidance
Tool — action interface
A product-content skill may define:
- Title structure
- Prohibited terms
- Localization rules
- A quality checklist
- When human review is required
Its tools:
get_product(product_id)
update_product_title(product_id, title)
send_for_approval(content_id)
Neither is optionalWithout a skill, the tool can still run, but the method may be inconsistent. Without a tool, the skill can guide the model but cannot change an external system.
4.5
How is MCP different from a tool implementation?
MCP is a standard connection protocol. It is not the business action itself.
MCP standardizes capability discovery, descriptions, call requests, and result delivery. The real business logic still runs in the MCP server or its backend: validate identity, obtain a token, call a business API, handle rate limits, write an audit log, normalize errors. An MCP server may expose a tool named update_inventory, but the inventory update is usually implemented in an API client, business service, or database layer.
4.6
How is an agent loop different from a workflow?
An agent loop makes dynamic decisions from runtime results. A workflow follows a predefined process.
| Question | Agent loop | Workflow |
|---|---|---|
| Who decides the next step? | Usually the model, within runtime policy | Usually the process definition |
| How predictable is it? | Lower | Higher |
| What is it best for? | Open-ended problems, exploration, diagnosis, complex planning | Approval, settlement, synchronization, reporting, compliance |
| What state does it track? | Current reasoning and tool-call context | Execution, retry, and approval state for every step |
| How does it handle failure? | The agent decides whether to retry or change methods | Retry, compensation, or rollback is defined in advance |
Nested, not competingA workflow can contain an agent step: fetch data deterministically, ask an agent to explain anomalies, validate the output format, then request human approval.
4.7
How is a cron or trigger different from a workflow?
A cron or trigger decides when to start. A workflow decides what happens after the start.
Trigger — when it starts
Workflow — what happens after
Every day at 09:00
A trigger can start:
- An agent
- A workflow
- A queue message
- An API request
Fetch yesterday’s data
→ Calculate metrics
→ Check anomalies
→ Agent generates analysis
→ Send the report
A workflow does not require a cron — a button, webhook, or business event can start it.
PART 05
Who should own each type of state?
Answer
State ownership should follow the meaning and lifetime of the state. It should not all be placed in the model’s context window.
Model
Temporary information for one inference only; no persistent business state
Agent loop
Current step, attempts, and stop state
Session
Working context for the current conversation or task
Memory
Useful information across sessions
Workflow
Steps, retries, approvals, compensation, overall execution state
API server
Business facts such as orders, products, and inventory
Harness
Runtime checkpoints, permissions, traces, context assembly
Bot / Channel
Platform message mappings and delivery state
This information should not exist only in the model’s context window
- Final order status
- Long-term user preferences
- Approval records
- External side effects that already happened
- Checkpoints required to recover a task
The context window is suitable for short-term working information. Anything that must persist, recover accurately, or support audits belongs in a session, memory system, workflow store, or business data layer.
PART 06
Can the system still run if one component is removed?
Answer
There are three different outcomes: another implementation can replace it, the system runs with reduced capability, or it is no longer the same kind of system.
Level 01
Replaceable implementation
Swap in another implementation; the capability itself survives.
Level 02
Reduced capability
The system still runs but loses a class of capability.
Level 03
No longer the same system
The code may run, but it is not the same kind of system.
| What is removed? | Severity | What happens? |
|---|---|---|
| Model | Not the same system | Loses model-driven understanding and reasoning; cannot perform typical agent tasks |
| Agent loop | Not the same system | Becomes a one-shot call and cannot continue acting from results |
| Harness | Not the same system | Separate parts may still exist, but there is no unified context, execution, and control system |
| Tool | Reduced capability | Can still generate answers but cannot reliably perform external actions |
| Skill | Reduced capability | Still runs, but domain quality, consistency, and method reuse decline |
| API server | Reduced capability | The related business capability disappears unless another backend provides it |
| Bot / Channel | Reduced capability | Background execution may continue, but that user entry point and result channel disappear |
| Workflow | Reduced capability | The agent still handles open-ended tasks, but fixed business processes become less reliable |
| Session | Reduced capability | Stateless requests remain possible, but continuity, pause, and recovery become difficult |
| Memory | Reduced capability | One task can still run, but long-term personalization and cross-task continuity disappear |
| MCP server | Replaceable | A direct API or built-in adapter can replace it, but standardized connection and composition are lost |
| Cron / Trigger | Replaceable | Manual execution remains possible, but automatic time- or event-based starts disappear |
The key point“The code still runs” does not mean “the system still works as a reliable agent product.”
PART 07
What does a minimum working agent require?
Answer
A minimum agent does not need all twelve components, but it needs at least these four things.
01
Model
Decides what to do next
02
Agent loop
Keeps the task moving
03
Tool
At least one, to perform an external action
04
Session / Context
Holds the current working state
This minimum system is already an agent, but it is not production-ready. It will usually lack:
SkillsLong-term memoryPermissions and approvalsIdempotency controlsWorkflow stateObservabilityCheckpoint recoveryUser channelsAutomatic triggersStandardized tool connections
PART 08
How should a production agent be defined and reviewed?
Answer
Settle the definition in one sentence, then run a fixed set of questions over every component.
An agent is a running decision entity. It is driven by a model, advanced by an agent loop, and uses tools to read or change the external world. A session holds its current task state, memory supplies cross-task context, and a harness controls context, permissions, execution, and recovery.
Each component in one sentence
ModelMakes judgments and generates output
Agent loopKeeps the task moving
SkillDefines how a type of task should be done
ToolPerforms one specific action
MCP serverExposes external capabilities over a standard protocol
API serverProvides real business functions and data
Bot / ChannelLets requests enter and results return
Cron / TriggerDecides when execution starts
WorkflowDefines how a fixed process runs
SessionHolds the current task
MemoryKeeps useful information across tasks
HarnessAssembles the components and controls execution
Architecture Review Checklist
Do not review a system by counting how many agent terms it uses. Ask these eight questions about every component. If every one has a clear answer, the system boundaries are usually clear.
- What problem does it solve?
- What does it receive?
- What does it produce?
- What state does it own?
- Who calls it?
- What does it call?
- What happens when it fails?
- If removed, does the system lose a core capability, runtime reliability, or one replaceable implementation?
This is Week 1 of a 26-week series on agent systems from first principles: capability maps, skills vs. tools, memory and context, loops, harnesses, and the patterns that separate a demo from production.
Happy learning, happy building.
Tao
Also in the newsletter.