TL;DR:Core concepts in the AI landscape include:
- Prompts and Commands issued by humans to Assistants
- Assistants that use LLM technology to provide useful output
- Models (LLM) that Assistants query
- Skills and Tools that augment Assistants with useful capabilities
- Commands issued by humans to Assistants for immediate action
- Agents and Sub Agents that complete tasks autonomously
- Plan mode issued by humans to Assistants for immediate action
So I now seem to be able to lay it down as a general rule that whatever I perceive very clearly and distinctly is true.
– DESCARTES • Third Meditation
I've seen questions of definition come up lately around AI.
What is an agent? What is the difference between skills and agents? How should I decide which to use when?
In this article, I will try to clarify these into "clear and distinct" concepts. To provide a clear definition of each, when they're used and how they relate to eachother.
I'll aim to do all this in an assistant-agnostic way, so you can use them with Claude Code, OpenAI Codex or any other assistant or framework.
Assistant#
An assistant is a piece of software that takes human input and uses LLM technology to provide a useful output, such as a reply, code changes, etc.
Assistants are typically implemented as mass market software applications by major AI firms such as OpenAI, Claude, Google and Microsoft.
Predominant assistants, at the time of writing, are:
Up-and-coming smaller players include:
Model#
A model is, at core, a very big vector database. This is a kind of database in which searches can be done semantically, by similarity. This structure and search interface, at a large scale, is what enables models to take human language as input and provide useful output.
Vector search algorithms and databases have been around since the early days of Google, but it's only more recently that the technology was generalised to widely available database systems and combined with deep learning algorithms to produce large language models (LLMs).
Predominant large language models at the time of writing, include:
- GPT series from OpenAI
- Claude Opus series from Anthropic
- Gemeni from Google
Many assistants allow you to select which model you want them to use. For example, Claude Code allows you to select between various Opus series models, Sonnet and others. You can select the most appropriate model for your use case, based on factors such as performance, cost and specialisation.
An extension of models is RAG (Retrieval Augmented Search), a software pattern by which assistants can look up additional information to supplement that found in models. This can allow assistants to incorporate more up-to-date or detailed information than is found in models, such as weather forecasts or stock prices. New models are published every few months or so, similar to software update cycles, whereas RAG can enable information to be looked up on demand, such as when the assistant is prompted.
Prompt#
Prompts are texts written in human-language and submitted to assistants for processing, either by humans or agents.
Good prompts are specific and carefully structured so as to generate useful results from assistants. Prompt engineering is the art and science of writing effective prompts.
Prompts are typically written by humans (or re-used from shared prompt libraries) and submitted via a web interface, command line interface or IDE extension.
Prompt interfaces:
- Claude
- Web interface: https://claude.ai
- Command-line interface:
claude
- Copilot
- Web interface: https://copilot.microsoft.com
- IDE extension: https://code.visualstudio.com/docs/copilot/overview (VS Code)
Prompt libraries:
Prompts can also be generated on-the-fly by software, including agents. For example, a customer support agent could receive support requests from customers and convert them into prompts which generate a suitable conversational reply from an assistant.
Context#
Context engineering is the ”…delicate art and science of filling the context window with just the right information for the next step.”
Context is information provided in addition to prompts to query a model for useful results. This includes information, rules, memory, and tools that shape how the model interprets the query.
Context information helps to narrow and focus the model search to get a more useful result. In a way, it's analogous to how WHERE/AND clauses add specificity to an SQL query, to get a more precise and correct result from a relational database search.
The total amount of information the system can process at once is called the "context window".
Context can include one or more of the following:
- System prompt
- User prompt
- Long-term memory
- Retrieval Augmented Generation (RAG)
- Output definitions
System prompt#
A prompt that defines the model’s role, boundaries, and behavior. This layer can include rules, examples, guardrails, and style requirements that persist across turns. It's like the instructions to an actor in a play, prior to handing them the script.
Example: You are a senior designer using the Lightning design system.
User prompt#
This is the immediate request — the short-lived, task-specific input that tells the model what to do right now.
Previous prompts can live in context in the sense that they can condition responses to future prompts. Previous prompts forming state or conversation history act as short-term memory, giving the model continuity across turns by including prior dialog, reasoning steps, and decisions.
Long-term memory#
Long-term memory is persistent and spans many sessions. It contains durable preferences, stable facts, project summaries, or information the system is designed to reintroduce later.
Examples of long-term memory are touched on in this article and include:
- Skills
- Agent definitions
- Documentation
Retrieval Augmented Generation (RAG)#
Discussed in a separate heading in this article, RAG involves models being connected to external data sources such as live data feeds or structured data in databases.
RAG can also be considered part of context, as it can make up part of the information provided to the model prior to prompts.
Output definitions#
Structured output definitions tell the model exactly how its response should be formatted — for example, requiring a JSON object, a table, or a specific schema.
Example:
data_json = { "resturant employees" :[
{"name":"Shyam", "email":"shyamjaiswal@gmail.com"},
{"name":"Bob", "email":"bob32@gmail.com"},
{"name":"Jai", "email":"jai87@gmail.com"}
]}
prompt = f"""
Translate the following python dictionary from JSON to an HTML \
table with column headers and title: {data_json}
"""
response = get_completion(prompt)
print(response)Agent#
An agent is a piece of software that take input (human and/or otherwise), runs autonomously and uses LLM technology to make decisions and take actions, likely to produce a useful outcome, such as customer support requests being actioned, code being written and deployed, etc.
Agents can run autonomously – that is, without direct human initiation. For example:
- In a continuous or periodic manner, such as hourly or daily
- In response to an event, such as a customer request or online order
Agents are typically implemented as customised software programs, written by software engineers in languages such as Python, Typescript, etc. They are structured as a loop, referred to as an "agent loop", where the application cycles continuously between taking input, making decisions and taking actions.
Agents can call APIs provided by assistants, such as Claude Agent SDK, to utilise LLM capabilities and perform certain actions.
Sub Agent#
A sub agent is an agent that is called by an assistant or another agent, to perform a more specialised role autonomously. Sub agent can be used to break down complex tasks into smaller, more manageable pieces, and to allow for more specialised agents to handle them in the background.
Sub agents run in a separate execution context from the main agent context. For this reason, assistants such as Claude Code may require context (such as skills, etc) to be defined for each sub-agent.
A key benefit of sub agents is that they allow context to reduced to only as much as the sub agent needs rather than the whole context. This helps us to keep context minimal, which is good for accuracy, performance and cost (by reducing token usage).
Sub agents can be implemented as customized software programs (possibly containerized), code libraries and/or configuration for assistants, such as in an agents folder. Sub agents might run as separate instances of the same assistant as with Claude Code.
Sub agents, being modular, can:
- Be re-used across multiple agents
- Be scaled independently for high demand, cost reduction, performance, etc.
- Be combined with other sub agents to collaborate in multi-agent workflows
For example, sub agent could be run in parallel as serverless functions, which could be scaled horizontally to a handle large number of requests, scaled elastically to minimise costs, etc.
Examples:
Skill#
A skill is a capability that an agent or assistant can be augmented with and applied to some relevant task.
A skills is typically made up of:
- Brief written description
- "When to use" written guidance
- Resources, if needed, such as code files, images, etc.
When it first loads up, an assistant can index its library of skills by description and written guidance. Subsequently, when a performing a task, the assistant can use the "when to use" guidance to determine which skill(s) are relevant and apply those that match. When a relevant skill is found, then its resources can be loaded.
For example, a skill for "designing a front end interface" might include:
- Description: "Create distinctive, production-grade, brand-aware frontend interfaces with high design quality."
- When to use: "Use this skill when the user asks to build web components or views in the frontend application."
- General guidance: "Use this skill to design the frontend interface, including layout, color scheme, typography, and overall visual aesthetics. Ensure that the design is distinctive, production-grade, and brand-aware."
- Packaged resources:
- PDF file containing branding guidelines, color palette, typography rules, etc.
An assistant will read the skill description and "When to use" instructions to determine when to apply the skill, such as when the task involves building a front end interface, such as a dashboard. If the skill matches, the assistant will then access the files inside the skill package in order to apply the skill and perform the task. In this example, it will access the PDF file and use the information to design the front end interface of the dashboard.
I have heard skills referred to as the "arms and legs" of an agent. Similarly to how humans arms and legs allow us to perform a wide variety of tasks, skills allow agents to perform a wide variety of tasks by augmenting them them with specific capabilities and functions. Just as arms and legs can be used for different purposes (e.g., walking, running, grasping objects), skills can be used for different purposes (e.g., summarizing text, generating code, answering questions).
A key benefit of skills is that they allow context to added on an as-needed basis rather than in every prompt. This helps us to keep context minimal, which is good for accuracy and performance and cost (by reducing token usage).
Skills, being modular, can:
- Be re-used across multiple agents and assistants
- Be shared across teams and the community, for example via private or public repositories of skills
- Can reduce the burden of loading everything into the main context file, instead loading their context only when matched, thus reducing token cost
Examples:
- https://github.com/anthropics/skills
- https://github.com/forrestchang/andrej-karpathy-skills
- https://skills.sh
Tool#
Similar to a skill, a tool augments an assistant.
The difference between a skill and a tool is that a tool is integrated more directly into an assistant via purpose-built software.
For example, MCPs (Model Context Protocol) are a category of AI tool, built by developers, allow assistants to connect to external data sources or perform actions via a web (HTTP) interface.
Comparison of skill vs tool:
| Skill | Tool |
|---|---|
| Augments an agent with additional capabilities | Augments an agent with additional capabilities |
| Is implemented or applied by an end-user or application developer | Is implemented by software engineers at a product vendor, such as a cloud service, hosting provider, etc |
| May be written in a more human format, such as a SKILL.md file | Is typically written in a programming language (such as Typescript, Python, Java, etc) with a software interface (such as HTTP for MCPs) |
Command#
A command is a specific instruction for an assistant to run immediately, typically provided by a human in real time.
Commands could be considered an AI equivalent of system commands, scripts, macros, etc.
They are typically signalled with a / (slash) prefix. For example: /review to perform a code review.
Examples:
/checks- run checks such as linters, unit tests, etc./setup- setup the development environment/review- perform code review
Plan mode#
This refers to the ability of an assistant to provide a plan for completing an action, rather than immediately performing the action. For example, to provide an implementation plan prior to implementing a code change or a design sketch prior to producing a full fledged design. When interacting with an assistant directly, plan mode allows the human the opportunity to review and perhaps request changes to the plan. When used in an agent, plan mode allows the agent to refine the assistant's output using the same (or another) assistant. This fits in to the "making decisions" part of the decide-act loop in agents.
Plugins#
Selected pieces of context – such as skills, commands, etc. – can be packaged together, published on a market place and consumed by other projects, either within an organization or publicly. These packages are referred to as plugins and are the AI equivalent of packages in open-source. Claude Code plugins are one implementation.
Hooks#
Hooks are instructions for an agent that run at specific points in the lifecycle of an agent session.
Different from a skill (which is matched by its description) a hook is triggered when a specific lifecycle event occurs.
(In this respect, they are conceptually similar to hooks in React or VueJS, which run at specific points in the component lifecycle.)
Examples of Claude Code agent session events:
- SessionStart - When a session begins or resumes
- UserPromptSubmit - When you submit a prompt, before Claude processes it
- PreToolUse - Before a tool call executes. Can block it
- Notification - When Claude Code sends a notification
- Stop - When Claude finishes responding
- SessionEnd - When a session terminates
Relationships between concepts#
The following diagram roughly maps out how the concepts relate to eachother.
🤖 Assistant-based:
- Humans issue prompts and commands to assistants
- Assistants query models and use the results to return useful outputs back to humans
- Assistants are augmented by skills, helping them complete tasks they would otherwise struggle with
🖥️ Agent-based:
- Humans set up agents in order to complete tasks autonomously
- Agents delegate work to sub agents
- Agents call assistant APIs for AI capabilities
- Assistants query models and use the results to return useful outputs back to agents
When to use#
| Concept | Where to use |
|---|---|
| Assistant |
|
| Model |
|
| Agent |
|
| Sub Agents |
|
| Skills |
|
| Commands |
|
Further reading#
- Agentic Coding • Missing Semester
- ChatGPT Prompt Engineering for Developers
- Claude Code docs
- Claude Code tutorial (NetNinja)
- How I use Claude Code
- OpenAI Codex tutorial (NetNinja)
- A Guide to Which AI to Use in the Agentic Era (Ethan MOLLICK)
- AI as Exoskeleton
- From Weeks to Hours: Building My Website with Agentic AI Pair Programming • Sam SWERCZEK
