# Tool classes

URL: https://tfw.how/tool-classes/
Description: The eight tool classes in TFW, the role each one plays for a topic, and how to name one topic's surface in each class.

In Topic Focused Workflow (TFW), the [topic](/glossary/#topic) is the anchor and the tools are the surfaces. A [surface](/glossary/#surface) is a place in one tool where work on the topic happens. TFW groups tools into eight [tool classes](/glossary/#tool-class): document storage, task management, knowledge base, chat, email, calendar, code repository, and AI agent workspace. Each class plays one role for a topic. Products in the same class can replace each other without changing the topic.

## Tool classes and their roles

Each class is the [source of truth](/glossary/#source-of-truth) for some kinds of information and not for others. The [information placement](/model/#information-placement) rule decides which class holds each kind of information.

| Tool class | Role in TFW | Source of truth for | Not the source of truth for |
| --- | --- | --- | --- |
| Document storage | Holds the topic's files | Source files, working documents, scans, media, signed originals | Task status, decisions, explanations of how the topic works |
| Task management | Holds accountable work and the [Focus System](/model/#focus-system) | Objectives, intentions, strategies, action records, owners, status, dates, dependencies | Long explanations, large files, conversation |
| Knowledge base | Holds durable, readable knowledge | The [purpose page](/glossary/#purpose-page), processes, explanations, decision write-ups, reference indexes | Task status, files, conversation |
| Chat | Holds conversation and automated notifications | Nothing that must last; chat is [conversation](/glossary/#conversation) | Decisions, requirements, procedures, commitments |
| Email | Holds correspondence | Evidence of what was communicated, and to whom | The task, the decision, or the procedure that results from an email |
| Calendar | Holds scheduled time | Event times, attendees, meeting links, agenda links | Decisions or work that result from a meeting |
| Code repository | Holds versioned implementation | Source code, configuration, infrastructure definitions, tests, change history, agent instructions for the repository | Business approvals, task status, chat transcripts, credentials |
| AI agent workspace | Holds the context that AI agents use for the topic | The agent's instructions for the topic | Anything the agent produces; output is a draft until it is written to its source of truth |

Chat, email, meetings, and conversations with an AI agent are conversation. When conversation produces a result that must last, you write the result to the source of truth and post a link back to the conversation.

## One surface per tool class

These rules apply to every class:

- A topic has at most one surface in each tool class. Chat is the exception: a topic has two channels, a [chat channel](/glossary/#chat-channel) for people and an [automated channel](/glossary/#automated-channel) for software. In the code repository class, a topic can have several repositories; together they are the topic's surface, and every name starts with the same prefix.
- The name of each surface contains the [topic code](/glossary/#topic-code) or the canonical name of the topic, or both. A person or an AI agent can then match the surface to the topic without guessing.
- All surfaces of a topic use one [access boundary](/glossary/#access-boundary). A deliberate exception is recorded.
- Each surface has a [maintainer](/glossary/#maintainer) who keeps its name, structure, description, and permissions correct.
- A missing or duplicate surface is a [provisioning gap](/glossary/#provisioning-gap). You record the gap and repair it. You do not create a parallel surface to work around it.

Not every topic needs a surface in every class. A topic with no meetings may have no calendar surface. When a surface does exist, it maps to exactly one topic.

## Consistency over product choice

Consistency matters more than the choice of product. A topic with the same code and name in every tool is easier to work with than a topic that uses the best product in each class but a different name in each one.

Replacing a product does not change the topic. If you move document storage from one product to another, the topic keeps its code, name, owner, participants, and access boundary. You create the new surface with the same naming rule, move the content, and update the links in the [topic profile](/glossary/#topic-profile). If a tool cannot use the canonical name, for example because of a length limit or an older naming rule, you record the name it uses as an [alias](/glossary/#alias) of the topic.

## Naming for one topic

The example topic is Example Co Operations. The venture is Example Co (venture code EX), the unit is Operations (unit code OP), and the topic code is EXOP.

| Tool class | Surface | Name |
| --- | --- | --- |
| Document storage | Shared drive | EXOP Example Co Operations |
| Task management | Project | Example Co Operations, project key `EXOP` |
| Knowledge base | Space | Example Co Operations, space key `EXOP` |
| Chat | Chat channel | `exop-exampleco-operations-chat` |
| Chat | Automated channel | `exop-exampleco-operations-automated` |
| Email | Group | `exop@example.com`, display name Example Co Operations |
| Calendar | Shared calendar | EXOP Example Co Operations |
| Calendar | Event titles | Start with the code, for example EXOP: Weekly review |
| Code repository | Repositories | Start with the prefix `exop-`, for example `exop-website` |
| AI agent workspace | Project or workspace | EXOP Example Co Operations |

Other topics in the same venture use the same pattern. Example Co Marketing uses the code EXMK: `exmk-exampleco-marketing-chat`, `exmk@example.com`, the repository prefix `exmk-`, and so on. Example Co Finance uses the code EXFI in the same way.

## Classes and tools

The pages in this section describe each tool class: its role, how one topic's surface looks, the rules, and common mistakes. The [tools](/tools/) section has one page for each specific product that this site covers, with steps to set up and maintain the surface in that product. Each class page lists the tool pages for its class. The code repository and AI agent workspace classes do not have tool pages yet. Other products in the same class follow the same rules. For the steps that create a topic and its surfaces, see [the method](/method/). For the full model, see [the model](/model/).

## In this section

- [Document storage](/tool-classes/document-storage/): Document storage holds a topic's files. Each topic has one document storage surface, owned by the organization and named with the topic code.
- [Task management](/tool-classes/task-management/): Task management holds a topic's accountable work and its Focus System, and its list of projects often serves as the registry of topics.
- [Knowledge base](/tool-classes/knowledge-base/): The knowledge base holds a topic's durable, readable knowledge, with a purpose page at the root of the topic's space.
- [Chat](/tool-classes/chat/): Chat holds a topic's conversation in two channels: a chat channel for people and an automated channel for software.
- [Email](/tool-classes/email/): Email holds a topic's correspondence through one group address, with labels and filters that route messages to the topic.
- [Calendar](/tool-classes/calendar/): Calendar holds a topic's scheduled time. Event titles start with the topic code, and event descriptions link to the agenda and the records.
- [Code repository](/tool-classes/code-repository/): A code repository holds a topic's versioned implementation. Every repository of a topic has a name that starts with the lowercase topic code and a hyphen.
- [AI agent workspace](/tool-classes/ai-agent-workspace/): An AI agent workspace holds the instructions and reference material that AI agents use for one topic. Each topic has one workspace, named with the topic code and the canonical name.