Tags, comments and saved views
Use workspace tags, comments, and saved views to organize shared work.
Tags, comments, and saved views are workspace-owned ways to keep shared work understandable. Use them when collaborators need a common label, a note attached to the work, or a reusable view of workspace information.
They belong to the workspace pack alongside membership, organization settings, credit information, agency work, event webhooks, callback URLs, and notification delivery. They are not Context documents, and they are not external provider connections.
Choose the right workspace object
Start with the job, not the label. A tag identifies something across shared work. A comment records the reason, question, or handoff that collaborators need beside the work. A saved view preserves a perspective that the workspace needs to return to.
These objects remain in the workspace boundary. Before adding or changing one, check the active workspace. The same label or saved perspective can mean different things in different workspaces, so a correct name in one workspace is not evidence that it belongs in another.
| Workspace object | Use it for | Do not use it for | Check first |
|---|---|---|---|
| Tag | A workspace-owned label for shared work. | A durable knowledge document or an external-provider connection. | Confirm the active workspace and the item you intend to label. |
| Comment | A workspace-owned note that keeps collaboration attached to the work. | A replacement for a revisioned Context document. | Read the existing work and any current discussion before adding a note. |
| Saved view | A workspace-owned saved perspective on shared work. | A copy of the underlying workspace data or a personal external bookmark. | Confirm that the view describes the workspace and audience that need it. |
Keep durable knowledge in Context
Context is the workspace knowledge store. It uses Markdown documents, revisions, and attribution to the member and client that wrote a change. Put a durable positioning decision, customer fact, process rule, or source-backed conclusion there when the workspace needs to preserve the knowledge itself.
A tag can point people toward a category. A comment can explain why a specific item matters. A saved view can make a recurring perspective easier to return to. None of those roles replaces a Context revision when the team needs a durable, attributed statement of knowledge.
Use the distinction to reduce ambiguity. If a colleague needs to understand the source and current version of a decision, write or revise a Context document. If the colleague needs to find a class of work, use a tag. If the colleague needs the discussion around one item, use a comment. If the colleague needs the same workspace perspective again, use a saved view.
Context is available at /dashboard/context. Read Context for the document and revision model before moving a durable fact out of a comment or a saved view description.
Work with the active workspace
The workspace pack owns collaborators, membership, organization settings, credits, agency, tags, comments, saved views, event webhooks, callback URLs, and notification delivery. This ownership boundary is useful because it tells you that a workspace object belongs to the workspace that contains the collaborators and work.
The knowledge pack owns durable workspace knowledge and Context. The integrations pack owns external provider connections. Do not use a tag, comment, or saved view to imply that an outside provider is connected or that a workspace fact has been stored as Context.
Architect can use the workspace pack to understand this boundary, then discover the exact capability contract before it performs a supported action. A skill teaches practice but does not grant authority. When the exact contract is not in the current turn, Architect must search and fetch it before it can run it.
Tags, comments, and saved views do not have a documented independent credit price on this page. If a later action selects a capability, its catalog entry defines its cost policy and credit class. Check that exact capability rather than assigning a cost from the workspace label alone.
Prepare a clear workspace change
Before you create a label, write a comment, or preserve a view, name the collaboration question. For a tag, name the category that teammates need to recognize. For a comment, name the observation or decision that must remain beside the work. For a saved view, name the perspective that someone will return to.
Then identify the active workspace and the object that the change concerns. This avoids a common category mistake: a comment about an external provider connection belongs beside the relevant workspace work, but it does not create the connection. A Context document can explain a decision, but it does not replace the workspace object being discussed.
Finally, check for an existing tag, comment, or saved view with the same purpose. Reusing a clear shared object is usually easier for collaborators than creating a second object with nearly identical wording. If the existing object is wrong, document the distinction in Context when it represents a durable policy or decision.
| Before you change anything | Why it matters |
|---|---|
| Name the collaboration question. | The question distinguishes a label, a note, a recurring perspective, and durable knowledge. |
| Confirm the active workspace. | Workspace objects are scoped to the workspace that owns them. |
| Read the current work. | A tag or comment should describe the real item rather than a guess about it. |
| Check for an existing shared object. | Duplicates make a workspace less understandable for the next collaborator. |
| Separate a provider fact from a provider connection. | Integrations owns connections, while the workspace owns its collaboration objects. |
| Separate an explanation from durable knowledge. | Context owns revisioned workspace knowledge. |
A useful comment can link people to a Context document when the full decision is durable. A useful tag can identify the work that needs that decision. A useful saved view can bring the recurring work back into view. These relationships help a workspace remain navigable without pretending that all three are the same kind of record.
Use the contract before an action
Architect, the CLI, and the MCP server use the same controls for discovery and execution. An agent does not receive authority merely by recognizing a workspace term in this page.
It searches for the requested capability, reads the exact contract, and then runs only a contract delivered in the current turn. This matters for workspace organization because the exact action, inputs, mode, and result shape come from the capability contract, not from a broad label.
Search can be scoped to the workspace pack when the request concerns a workspace-owned object. The pack helps route the request, but it does not add a separate list of tools or make an unsupported action valid.
A mutating action must name a mode and the server never defaults to live. Use the returned contract to see whether the selected action supports a dry run, a live action, or another documented mode.
The result may carry a web_url for the exact object in the app. Keep the returned identifier as the source of truth, then use the link to inspect the workspace object in its app context.
When it goes wrong
If collaborators cannot find a tag, comment, or saved view, first check the active workspace. These objects belong to a workspace, so changing workspace context can make a correct object appear absent. Do not recreate it until you have checked the intended workspace and the item it should describe.
If a comment has become the only place where a durable customer fact or decision exists, move the conclusion and its source into Context. Keep the comment focused on the local collaboration history. The resulting Context revision gives the workspace an attributed knowledge record instead of a fragile note attached to one item.
If a saved view is unclear, improve the shared question it represents before creating another one. A second view with nearly the same purpose makes the workspace harder to navigate. Check whether the existing view, tag, or comment already answers the collaboration need.
If the work actually depends on a provider connection, use the integrations surface instead of documenting the connection in a tag or comment. If it depends on membership or an organization setting, use workspaces, members and roles. Those distinctions keep workspace labels from becoming misleading operational state.