Tool classes
In Topic Focused Workflow (TFW), the topic is the anchor and the tools are the surfaces. A surface is a place in one tool where work on the topic happens. TFW groups tools into eight tool classes: 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 for some kinds of information and not for others. The 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 | Objectives, intentions, strategies, action records, owners, status, dates, dependencies | Long explanations, large files, conversation |
| Knowledge base | Holds durable, readable knowledge | The 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 | Decisions, requirements, procedures, commitments |
| 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 for people and an 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 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. A deliberate exception is recorded.
- Each surface has a maintainer who keeps its name, structure, description, and permissions correct.
- A missing or duplicate surface is a 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. 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 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 |
| 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 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. For the full model, see the model.