From Tool to Agent: A Map of Terms for Working with Artificial Intelligence
Written in collaboration with Claude.
Introduction: Same Ideas, Different Names
Behind the abundance of terms in artificial intelligence are a few basic ideas. Each step from a basic tool to an agent adds one component to the previous step. Anyone who understands the components can identify them in any tool, even when their name changes.
The confusion is understandable. Different vendors use different names for the same idea: the workspace is called Project in Claude and in ChatGPT, and in Gemini it is called Notebook. The reverse also happens: the same word is used to describe different things. “Agent” describes, at one vendor, a preconfigured assistant, and at another, a tool that operates independently over time.
The article is built as layers stacked one upon another into an orderly and well-defined foundation:
At the end of the article, an appendix includes a glossary of terms that brings together the component names across the four main tools.
The principle that accompanies the article: Components are stable, and containers change. Instructions, knowledge files, actions, and autonomy exist in all the tools. The names and packaging in which they are presented change rapidly. Anyone who knows the components can understand even terms that have not yet been coined.
The Tool and the Conversation
At the base of all the tools, Claude, ChatGPT, and Gemini, lies a language model (LLM): a system that has learned from an enormous amount of text and can formulate, explain, summarize, and reason. The tool is the interface through which one converses with the model.
Three related basic concepts:
Prompt: what one writes to the model. The answer’s quality depends largely on the prompt’s clarity, the context it provides, and the examples it contains.
Conversation (chat): a sequence of prompts and responses. With each response, the model sees everything that has been said up to that moment. A new conversation starts from zero, unless the tool retains memory between conversations.
Context window: the amount of text that the model can hold in view at once. The window includes the entire conversation: prompts, responses, and attached documents. When it fills up, earlier parts may be dropped.
What the tool does not know: A language model on its own is not familiar with the person, the organization, the procedures, the customers, or the history of the project. Its general knowledge is broad, but its specialized knowledge comes only from what it’s connected to.
In a tool the organization has installed and connected to its systems, such as Microsoft 365 Copilot, this connection already exists: the tool accesses the organization's email, files, and conversations based on each employee's permissions. In the terms of this article, these are tools in which some of the following stages have been assembled in advance.
Even in these cases, the tool knows only what is accessible through the systems. It does not know what exists only in the heads of the role holders, and it does not always know which document is binding. This gap is the starting point of the following stages.
The next chapter deals with ways of retaining context between conversations, so that the tool does not start every conversation from zero.
Context That Persists
The problem: In a regular conversation, every new conversation starts from zero. The tool doesn't know who you are, what you do, or how you like to work, so you have to explain everything anew each time.
All the main tools offer three ways of retaining context between conversations. Each way retains something different:
Standing Instructions
Standing instructions are general guidelines that apply to all conversations: who you are, in what tone to respond, in what format, and in what language. They are similar to a briefing given to a new employee once, and not before every task.
In different tools, ChatGPT and Microsoft 365 Copilot call it Custom Instructions. In Claude, these are personal preferences (Preferences) defined in the settings. In Gemini, you can save instructions and personal information the tool will use.
Memory
Memory is what the tool learns about you from previous conversations: preferences, topics you work on, and details you have shared. Unlike standing instructions, you do not write it yourself. It is built over time, like a personal acquaintance. You can usually see what was saved, correct it, and delete it.
In the different tools: In all four tools, the capability is called Memory, and it can be turned on and off in the settings.
Workspace
A workspace is a permanent place that gathers all the conversations on one topic, for example, a client, a project, or a knowledge domain. You define instructions and knowledge files once, and the tool has access to them in every conversation opened there. Standing instructions apply to all conversations, while workspace instructions apply only to its topic.
In different tools, Claude and ChatGPT call the workspace a Project. In Gemini, it is called Notebook, and in Microsoft 365 Copilot, it is called Copilot Notebook.
Three Types of Input
In every workspace, the tools work with three types of input:
Input type | Essence | Source |
Instructions | Rules for how to work | Defined in advance |
Knowledge files | What the tool knows in the field. Often they are far deeper and richer than the instructions themselves | Defined in advance |
Case input | The information about the case currently being worked on | The user's answers, not the tool's. |
In knowledge management, this distinction is familiar: procedural knowledge (know-how), domain knowledge (know-what), and knowledge about the specific case (context).
The next chapter covers knowledge files and how dedicated knowledge is made accessible to the tool.
Grounding in Dedicated Knowledge
Making the Knowledge Accessible
For the tool to base its answers on specific knowledge, the knowledge must be accessible to it. Knowledge can enter the tool in three ways, which differ in how long the knowledge remains available and how up to date it is:
Loading into the Conversation
The simplest way is to load a file into the conversation itself. The file is accessible to the tool throughout the conversation only, and in a new conversation it must be loaded again. This option exists in all tools and has no distinctive name.
This is the suitable way for case input: the document currently being worked on, in its most up-to-date version.
Anchoring in the Workspace
Files anchored in the workspace become knowledge files. They are accessible to the tool in every conversation opened in the workspace, and there is no need to load them again. However, this is a copy: the file remains in the version that was loaded until it is replaced.
Different tools call them Project knowledge in Claude and Project files in ChatGPT. In Gemini, they are called the Notebook's Sources, and in Microsoft 365 Copilot, they are called the Copilot Notebook's References.
Live Retrieval from the Knowledge Source
The tool connects directly to the organization's knowledge source, such as a knowledge portal, a document management system, or another repository, and retrieves the up-to-date version each time. The tool works against the source itself, and not against a copy.
Across tools, Claude calls these Connectors, and ChatGPT calls them Apps (also called connectors). In Gemini, they are called Connected apps, and in Microsoft 365 Copilot they are called Copilot connectors. In organizational tools such as Microsoft 365 Copilot, the connection to the organization's data exists from the outset: the tool accesses email, files, and conversations according to each employee's permissions.
Considerations in Choosing
Below are the main considerations in choosing the type of retrieval:
Consideration | Loading into the conversation | Anchoring in the workspace | Live retrieval |
Duration of availability | One conversation | All conversations in the workspace | Constant, as needed |
Up-to-dateness | The version that was loaded | The version that was loaded, until it is replaced | Always up to date |
Scope | Individual files | A limited number of files | A repository of any size |
Permissions | Those of the person who loaded it | Those of anyone with access to the workspace | According to the permissions at the source |
Usefulness | Case input | Stable domain knowledge: professional doctrine, background, representative cases | Changing knowledge or a broad repository |
Key Insights on Retrieval
Knowledge Files Are the Heart of the Workspace
They should not be viewed as background material alone. They are often far deeper and richer than the instructions themselves, and contain the accumulated experience, the considerations, the examples, and the exceptions. At this point, knowledge management adds the greatest value. It determines what knowledge deserves to be included, formulates it in a usable way, and ensures that it is kept up to date.
Retrieval: When There Is a Lot of Knowledge
When the knowledge files are limited in scope, the tool reads all of them in full. When their scope exceeds the context window capacity, and likewise when retrieving from a broad repository, the tool does not read everything. It locates passages relevant to the question, retrieves them, and answers based on those passages. This method is called RAG (Retrieval-Augmented Generation), that is, generating an answer with the aid of retrieval.
Retrieval has two practical implications:
A passage that is retrieved separately may be read out of its context. For this reason, short, focused files, each covering a single topic, work better than one long file that contains everything.
The quality of the answer depends on the quality of the repository. Contradictory versions, drafts, and duplicates disrupt retrieval, and the tool may rely on an incorrect passage.
The Source of Truth
In an organization, approved knowledge is kept in the source of truth: a knowledge portal, a document management system, or combinations of these. The tool does not replace the source of truth; it adds a layer on top that lets you ask questions.
The type of system affects the quality of the answers. A knowledge portal usually contains content that has been selected and approved. A document management system also contains drafts, previous versions, and duplicates. When the tool is connected to a document management system, it is recommended to define the places from which it is permitted to retrieve, such as approved libraries or a “Final versions” folder only. Otherwise, it may rely on a draft.
The next chapter deals with the first type of input, instructions, and with the way in which they become a structured way of working.
Procedural Knowledge – How It Is Done
In this chapter, the tool moves from question-and-answer to structured work. The tool receives a playbook: a written description of how to carry out a single task. The playbook determines what to clarify first, what knowledge to base itself on, the order of operations, and the required deliverable. When the tool operates according to a playbook, a guided conversation is created: instead of the user guiding the tool, the tool guides the user, collects from them the case input, and leads them to the deliverable.
The Seven Components of a Playbook
A good playbook is built of seven fixed components:
Component | The question it answers |
Trigger | When is it activated? |
Input | What details need to be clarified with the user? |
Sources | What knowledge is it based on? |
Steps | In what order does one proceed? |
Deliverable | What does the output look like? |
Quality control | What is checked before delivery? |
Boundaries | What must not be done? |
The three types of input from Chapter 2 are integrated into the playbook. The Input component defines how to collect case input, and the Sources component refers to the knowledge files and source of truth. The playbook itself constitutes the instructions.
Three Levels of Playbook
Playbook in a Prompt
The playbook is written or pasted into the conversation anew each time. The method is simple, but it depends on the user's memory and diligence.
Playbook in the Workspace Instructions
The playbook is written in the workspace instructions and applies to every conversation opened in it. It is always available, but limited to a single workspace.
In other tools: In Claude and ChatGPT, these are Project instructions. In Gemini and Microsoft 365 Copilot, these are the Notebook custom instructions.
Portable Playbook: Skill
The playbook is saved as an independent unit, and the tool loads it when the task requires it, in every conversation and in every workspace. A Skill is not limited to instructions alone. You can attach supporting files, examples, and code, and define actions the tool will perform, such as searching email or saving a file. Carrying out the actions themselves requires a connection to systems, as discussed in Chapter 5.
In the different tools, it is called Skills. After a period when each vendor gave the playbook a different name, the tools became more uniform. Availability still varies by tool and by plan type.
Considerations in Choosing
Playbook in a prompt | Playbook in the workspace instructions | Skill | |
Availability | One conversation | All conversations in the workspace | Every conversation, as needed |
Activation | Manual, each time | Automatic, within the workspace | Automatic, according to the task |
Contents | Instructions | Instructions | Instructions, supporting files, code, and a definition of actions |
Usefulness | Initial experimentation | Tasks in a single domain | Recurring tasks across different domains |
The Playbook as Encoded Procedural Knowledge
A playbook is encoded procedural knowledge (know-how). Knowledge-elicitation deliverables, such as professional doctrine, considerations, sensitivities, and priorities, are the material from which playbooks are written. The difference is that the playbook doesn’t stay in a document. It becomes a way of working that the tool carries out.
Writing a good playbook requires more than describing the steps. One must formulate the considerations that lie behind each step, the exceptions, and what must not be done. These are exactly the elements an experienced role holder knows and often doesn't write down, so they require elicitation.
The next chapter covers the tool's ability to perform actions, not just respond.
Action – Performing, Not Just Responding
So far, the tool has read, analyzed, and formulated. At this stage, the tool can act: tools are capabilities that let it perform actions in the world, not just produce text.
Types of Actions
Searching and reading on the web: Locating up-to-date information and reading pages.
Running code: Analyzing data, performing calculations, and producing files, such as spreadsheets, presentations, and documents.
Acting in the organization's systems: Reading and writing in email, the calendar, a document management system, or the CRM system.
Operating a browser or computer: Navigating websites, filling out forms, and operating applications, similar to how a person works.
The Connection: The Tool's Hands
To act in an organizational system, the tool needs a connection. The connection gives the tool access to the system and permission to act in it. In Chapter 3, we saw connections used for retrieving knowledge. The same connections also perform actions, such as sending a message, updating a record, or saving a file.
The distinction between Skill and connection: In Chapter 4, we saw that a Skill can define actions. The Skill determines what to do and in what order, and the connection makes it possible to execute this in practice. Skill that defines saving receipts in Drive knows what to do. Without a connection to Gmail and to Drive, it cannot do this. The Skill is the script, and the connection is the hands.
Across tools: In Claude, connections are called Connectors; in ChatGPT, they are called Apps (also called connectors). In Gemini, they are called Connected apps. In Microsoft 365 Copilot, a distinction is made between two types: Copilot connectors, used mainly for bringing in knowledge, and Actions, used for performing actions.
The shared standard: All four tools support MCP (Model Context Protocol), an open protocol that defines how a model connects to an external system. Thanks to the standard, a connection built once can serve several tools. The extent of support varies by tool and by plan type.
Permissions and Approvals
A tool that is capable of sending a message or updating a document needs clear boundaries: which actions it is permitted to perform independently, and which require human approval. The main tools define cautious defaults. Thus, for example, ChatGPT's Workspace agents request approval by default for every write action, and Gemini Spark requests approval before sensitive actions, such as sending email or making a payment.
Considerations in Choosing
Deciding what the tool can do on its own rests on two considerations: how reversible the action is and the nature of the judgment it requires.
Type of action | Examples | Recommended policy |
Reading and gathering | Search, reading documents, summarizing email | Independent execution |
Internal, reversible writing | Creating a draft, saving a file, tagging a message | Independent execution, with reporting |
Outward-facing action | Sending a message, publishing, calendar invitation | Human approval before execution |
Irreversible action | Deletion, payment, changing permissions | Explicit approval every time, or an absolute prohibition |
A decision requiring human judgment | A professional recommendation, approaching a sensitive stakeholder, prioritizing among competing needs | Joint decision: The tool presents analysis, alternatives, and considerations, and the person decides |
The last row cuts across all the rows above it. Some decisions make it clear that the tool cannot have all the required knowledge: the full context, the sensitivities of the people involved, the organizational nuances, and the professional understanding accumulated through experience. This is the tacit knowledge of the person and the organization: knowledge that was never articulated. Even when the knowledge exists, the tool cannot replace the person's judgment in making the decision. In such decisions, the tool serves as a thinking partner, and not as an executor. It broadens the picture, surfaces considerations, and proposes alternatives, but the person still makes the decision.
The next chapter deals with the agent: the combination of instructions, knowledge, and actions into autonomous work over several steps.
Permission policy is an organizational decision, not a technical one. The questions “who is permitted to do what” and “what requires approval” are familiar from the fields of knowledge management and information governance. The difference is that this time they apply to the tool as well.
The next chapter deals with the agent: the combination of instructions, knowledge, and actions into work over several steps, and with the question of what degree of autonomy is appropriate for it.
The Agent – Instructions, Knowledge, and Actions in Autonomous Work
An agent combines instructions, knowledge files, and actions to achieve a goal over several steps and decides what to do next. In this sense, the agent is not a new component but a combination of the components presented in the previous chapters, with one addition: autonomy.
The essential difference between an agent and the previous stages lies in how it works. Instead of a single answer, the agent operates in a loop: it plans, executes, examines the result, and decides whether to continue, change direction, or finish. The diagram “Anatomy of an Agent” presents this loop and the components that feed it.
An Agent Is Defined by How It Operates, Not by Its Packaging
The term “agent” has long been used to describe a wide range of tools, including preconfigured assistants such as a custom GPT or Gem. Such a tool, which combines instructions, knowledge files, and actions and operates over several steps, is indeed an agent. However, packaging does not determine this. The same components, packaged today as Skills and as connections inside a Plugin (Chapter 7), also make up an agent. What determines it is how it operates: does the tool operate over several steps and decide on the next step on its own?
Is every knowledge bot an agent? For a long time, systems that answer from a knowledge repository using a simple retrieval method (RAG) — receiving a question, retrieving passages, and responding — were also called “agents.” By this chapter's definition, such a system is not an agent but a knowledge-based tool. It becomes an agent when it decides what to search for, rephrases questions when the results are unsatisfactory, cross-references sources, and acts on the findings. The distinction is not between “bot” and “agent,” but in the degree of judgment and autonomy that the system exercises.
In the different tools: In Claude, agentic work is carried out in the Cowork and Claude Code work environments. In ChatGPT, there is a ChatGPT agent and, in organizational plans, Workspace agents. In Gemini, the agent Gemini Spark is in the early stages of rollout. In Microsoft 365 Copilot, the term "agent" describes a preconfigured assistant built in Agent Builder or Copilot Studio; alongside it, Copilot Cowork supports agentic work. Note: The word “agent” means different things at each vendor, so it is better to look at what the tool actually does rather than rely on its name.
Levels of Autonomy
Instructions, knowledge, and actions can be used at different levels of autonomy. The difference between them is who decides on the next step:
Level of autonomy | Who leads | Example |
Guided conversation | The playbook determines the order, and the user approves each step | Documenting a lesson learned in seven fixed steps |
Guided agent | The agent chooses the way, within boundaries that were defined for it, and reports at key points | Preparing a briefing ahead of a meeting: locating sources, reading, cross-referencing, and summarizing |
Autonomous agent | The agent operates alone over time, and reports at the end | Ongoing handling of the mailbox according to fixed rules |
Considerations in Choosing Varying Levels of Autonomy
The appropriate level of autonomy derives from three considerations:
Consideration | Low autonomy | High autonomy |
Impact of the actions - Chapter 5 | Outward-facing or irreversible actions | Reading, gathering, and internal writing |
Nature of the judgment - Chapter 5 | Requires tacit knowledge and human judgment | Technical and clear judgment |
Maturity of the playbook | A new task, with no accumulated experience | A familiar task, with a playbook that has been tested over time |
Autonomy is not a one-time decision. A new playbook usually begins as a guided conversation. As experience accumulates and the results prove themselves, the agent can be granted greater autonomy, step by step. Even when the agent is autonomous, decisions that require human judgment remain joint decisions.
A Comprehensive Agent or Focused Agents
A central question in agent design is whether to build one agent that handles all tasks or several focused agents, each specializing in a defined domain.
A comprehensive agent gathers all the instructions, knowledge files, and actions in one place. It is simple to operate and sees the full picture. However, as more domains accumulate, the instructions grow longer, the context window fills up, and the agent may mix up roles and miss the main point.
Focused agents divide the work among themselves. Each knows only the instructions and knowledge needed for its domain. Like an escape room, where each room has its own clues and a single puzzle, a focused agent doesn't have to deal with all the clues at once and therefore doesn't get lost.
It is also possible to combine the approaches: a main agent (orchestrator) receives the task, divides it among focused sub-agents, and consolidates their results. It is recommended to maintain a shallow hierarchy. As the number of levels grows, the risk of losing context in the transitions between agents increases.
A middle way: one agent with Skills. A Skill is loaded only when the task requires it (Chapter 4). Therefore, one agent equipped with many Skills enjoys the advantages of both approaches: it serves as a single entry point, but at any given moment operates only with the playbook relevant to the task.
Considerations in Choosing How to Divide a Task Among Agents
Consideration | Comprehensive agent | Focused agents |
Focus | Low: the instructions and knowledge of all the domains are available simultaneously | High: each agent operates only in its own domain |
Seeing the full picture | High | Lower: context may be lost in the transitions |
Testing and improvement | Difficult: a change in one domain may affect another | Simpler: each agent is tested and improved separately |
Ownership | One owner for all the domains | An owner for each domain, similar to role holders in an organization |
Usefulness | Few tasks, related to one another | Many domains, requiring specialization |
The principle is familiar from knowledge management: the distinction between a comprehensive agent and focused agents parallels the long-standing organizational question of generalists versus experts. Here, too, the answer depends on the domain's scope, the required depth of specialization, and the cost of coordinating among them.
What Makes an Agent Good
A good agent rests on five conditions: a clear goal and a defined domain; playbooks for recurring actions; access to an orderly source of truth; a permission policy that matches the level of risk; and a level of autonomy that matches the playbook's maturity and the nature of the decisions. Knowledge management already deals with each of these conditions. The difference is that they now apply not only to people, but also to the tool.
The next chapter covers the transition from the personal to the organizational: packaging and distributing capabilities, and governance.
From Personal to Organizational – Sharing, Packaging, and Governance
Everything described so far can operate for a single person: a personal workspace, playbooks written for oneself, and connections to the systems in which one works. At this stage, the capabilities become an organizational asset, and all employees operate from the same playbooks, against the same source of truth, and within the same boundaries.
Sharing
The simple way to transfer a capability from a person to a team is to share it. You can share a workspace so colleagues work with the same instructions and knowledge files, and you can share individual playbooks.
Across tools: In Claude, organizational plans (Team and Enterprise) let you share Projects and Skills across the organization. In ChatGPT, you can share Projects; in organizational plans, you can also share Skills and publish them in the organization's library. In Gemini, one can share Gems. In Microsoft 365 Copilot, system administrators publish Agents to employees through the Microsoft 365 admin center.
Packaging: Plugin
When several playbooks, connections, and actions work together, it is convenient to package them in a single unit, which is installed once. Such a unit is called a Plugin. A Plugin can include Skills, connections to systems, commands that are invoked by name, and agents. Installing a Plugin makes all its capabilities available in every conversation, so you don't need to switch to a dedicated tool.
In Claude, the organization's system administrator can install a Plugin for all employees. In ChatGPT, a Plugin bundles Skills and Apps and replaces the custom GPT: GPTs will be retired on December 11, 2026, and upon conversion, their instructions become Skills and their knowledge files become supporting files. In Microsoft 365 Copilot, Agents are packaged as an application package and distributed through the admin center.
Note: At Microsoft, the term “plugin” describes a single action, not a package. Gemini has no parallel packaging mechanism.
Governance
The more the capabilities are shared, the greater the importance of the familiar questions from the field of knowledge management:
Ownership: Who is responsible for each workspace, each playbook, and each repository?
Quality: Which files are included as knowledge files, and who approves a playbook before it is distributed?
Updating: How often are the knowledge and playbooks checked to ensure they are still valid?
Permissions: Who is permitted to access which files, and which actions is the tool permitted to perform without approval?
Learning: How do questions the tool can’t answer become knowledge gaps that are addressed?
Considerations in Choosing
The decision on the scope at which to distribute a capability rests on four considerations:
Consideration | Personal | Team | Organizational |
Maturity | Initial experimentation | A playbook tested in use | An established playbook that has proven itself over time |
Target audience | One person, in a unique role | Role holders or a profession in one team | Role holders in different units of the organization |
Sensitivity | Personal or confidential knowledge | Team knowledge | Knowledge that all employees are permitted to have |
Ownership | The user themself | The team leader or the domain owner | A defined role holder, with an update process |
The scope of distribution derives first and foremost from the target audience. Most professional knowledge is not personal, but role-dependent. A playbook for documenting lessons learned, or for handling a certain type of inquiry, belongs to the role holders who deal with it; therefore, it belongs from the outset at the team or organizational level. Other considerations determine the pace: a new playbook is first tested with a small group of role holders, and only after it proves itself is it distributed to the entire target audience.
The next chapter sums up the layers into a single picture: the stable components and the changing containers.
Components and Containers – The Complete Picture
The layers presented throughout the article converge on a single principle: the components are stable, and the containers change. Tools change rapidly, and so do the names vendors give their capabilities. Beneath the changing names, a few components remain fixed. Anyone who identifies them can understand any tool, even a tool that has not yet been created.
The Four Components
Component | Essence | Chapter in which it was presented |
Instructions | Rules for how to work: procedural knowledge (know-how), from a single prompt to a structured playbook | Chapters 2 and 4 |
Knowledge files | The knowledge that the tool brings to the domain: domain knowledge (know-what) | Chapters 2 and 3 |
Actions | The ability to perform in systems, conditioned on a connection to them | Chapter 5 |
Autonomy | The degree of judgment of the tool in choosing the next step | Chapter 6 |
Alongside the four components there operates case input: the knowledge about the current case, coming from the conversation itself. Case input is not part of any container, since it changes with every use.
The Containers
Every term that the reader encounters is a container that holds some of the components or all of them. The containers differ in two respects: which components they hold and how they are used.
Container | Instructions | Knowledge files | Actions | Autonomy | How it is used |
Conversation | Individual prompts | Files loaded into the conversation | According to the available tools | Low | One turns to it anew each time |
Workspace (Project, Notebook) | ✔ | ✔ | Via connections | Low to medium | One turns to it, in every conversation on the topic |
Preconfigured assistant (GPT, Gem in transition) | ✔ | ✔ | ✔ | Varies | One turns to it directly |
Skill | ✔ | Supporting files | Definition of actions | — | Loaded automatically according to the task |
Plugin | Via Skills | ✔ | Via connections | — | Installed once, and available everywhere |
Agent | ✔ | ✔ | ✔ | ✔ | Receives a goal and operates over several steps |
The table clarifies why the terms seem to overlap. Many containers share the same components; the differences lie in how they are used and their degree of autonomy. For example, a preconfigured assistant and a Plugin hold almost identical components, so you can convert one into the other. The difference is that one uses the preconfigured assistant, whereas a Plugin's capabilities are available in every conversation, as needed.
How to Read a New Term
When a new term appears, it can be understood by means of three questions:
Which components does it hold? Instructions, knowledge files, actions, or a combination of them.
How is it used? One turns to it, it is loaded as needed, or it is installed and operates in the background.
What is its degree of autonomy? Does it respond, guide, or operate alone over several steps?
These three answers place each term on the map, regardless of the vendor's name.
What This Means for Knowledge Management
The layers from tool to agent are, in essence, layers of knowledge. Technology supplies the containers, and knowledge management supplies what fills them:
Component | What technology provides | What knowledge management provides |
Instructions | Playbooks and Skills | Elicitation of procedural knowledge and encoding of the professional doctrine |
Knowledge files | Workspaces, repositories, and connections | An orderly source of truth and approved, updated knowledge files |
Actions | Connections to systems | A policy of permissions and approvals |
Autonomy | Planning and execution over steps | Defining boundaries, and identifying the decisions that require human judgment |
Distribution | Sharing and Plugins | Ownership, professional validation, updating, and learning from gaps |
Even as the tools advance, one domain remains beyond their reach: the tacit knowledge of the person and the organization. Tools cannot access experience, intuition, and nuanced understanding until someone articulates them; even then, judgment remains in the person's hands. Making this knowledge accessible, as far as possible, is the long-standing mission of knowledge management. It is now becoming more important than ever.
Therefore, as the tools advance, the central question shifts from “Which tool should we choose?” to “What knowledge will we put into it, and who will maintain it?” Knowledge management has been answering this question for years.
In the attached appendix, the names of the components and containers in the four main tools are brought together.
Appendix – Glossary of Terms
The appendix below includes two parts. The first part brings together the article's basic terms, which do not depend on a particular tool. The second part presents how each idea is called in the four main tools.
Basic Terms
Term | English term | Definition | Chapter |
Language model | Language model | A system that has learned from an enormous amount of text, and knows how to formulate, explain, summarize, and reason | 1 |
Prompt | Prompt | What one writes to the model in a conversation | 1 |
Context window | Context window | The amount of text that the model can hold in view at once | 1 |
Instructions | Instructions | Rules for how to work, defined in advance | 2 |
Memory | Memory | What the tool has learned about the user from previous conversations | 2 |
Workspace | Workspace | A permanent place that gathers the conversations on one topic, with shared instructions and knowledge files | 2 |
Knowledge files | Knowledge files | Files anchored in the workspace that provide the tool with domain knowledge | 2, 3 |
Case input | Context | The knowledge about the current case, coming from the conversation itself | 2 |
Retrieval | Retrieval (RAG) | Locating the relevant passages in a repository and producing an answer based on them | 3 |
Source of truth | Source of truth | The system in which the organization's approved knowledge is kept | 3 |
Playbook | Playbook | A written description of how to carry out a single task | 4 |
Guided conversation | Guided conversation | A conversation in which the tool guides the user according to a playbook | 4 |
Skill | Skill | A portable playbook, loaded as needed, that can include supporting files, code, and a definition of actions | 4 |
Connection | Connector | Access and permission of the tool to act in an external system | 3, 5 |
MCP | Model Context Protocol | An open protocol for connecting models to external systems | 5 |
Agent | Agent | A tool that combines instructions, knowledge, and actions over several steps, and decides on its own what the next step is | 6 |
Autonomy | Autonomy | The degree of judgment of the tool in choosing the next step | 6 |
Sub-agents | Sub-agents | Focused agents among which a main agent divides the work | 6 |
Plugin | Plugin | A packaged unit of Skills, connections and actions, installed once | 7 |
Tacit knowledge | Tacit knowledge | Knowledge that has not been articulated, or that is not accessible to the tool | 5, 8 |
The Terms in the Different Tools
As of October 2026. Names and availability change frequently, and some of the capabilities are available only in certain plans.
Idea | Claude | ChatGPT | Gemini | Microsoft 365 Copilot |
Standing instructions | Preferences | Custom instructions | Instructions and saved personal information | Custom instructions |
Memory | Memory | Memory | Memory | Memory |
Workspace | Project | Project | Notebook | Copilot Notebook |
Knowledge files | Project knowledge | Project files | Notebook sources | Notebook references |
Workspace instructions | Project instructions | Project instructions | Notebook custom instructions | Notebook custom instructions |
Preconfigured assistant | Implemented via Project | GPT to be retired on December 11, 2026 | Gem, converted to Skills in personal accounts from November 2026 | Agent |
Skill | Skill | Skill in organizational plans | Skill | Skill (in Copilot Cowork) |
Connection | Connector | App - also called connector | Connected app | Copilot connector for knowledge Action for actions |
Agentic work | Cowork, Claude Code | ChatGPT agent; Workspace agents | Gemini Spark (early rollout) | Copilot Cowork; Agents |
Packaging and distribution | Plugin | Plugin | — | Application package, via the admin center |
Notes:
Convergence: Project, Skill, and Plugin are now used in several tools, with similar meaning. This signals the field's maturation.
Same word, different meanings: “Agent” describes in Microsoft 365 Copilot a preconfigured assistant, and in other tools a tool that operates independently. “Plugin” describes in Microsoft a single action, and in Claude and in ChatGPT an entire package.
Containers in transition: GPT and Gem are being converted to the structure of Skills and Plugins. Anyone who built them in the past will find the same components in the new structure.
Sources (checked on October 13, 2026):
ChatGPT: Projects · Skills · MCP apps · Workspace agents · Custom GPT retirement
Gemini: Gems · Notebooks · Custom apps ·
Comments