Blocks, links, and the permissions that travel with them
Macro’s context model becomes concrete in its blocks, @mentions, and sharing rules. This chapter asks what happens when one block refers to another: how the relationship is recorded, how the target can point back to it, and how a channel can make that context available without turning every mention into unrestricted access. The result is a practical way to read Macro links: distinguish what a reference lets you navigate to, whom it notifies, and who is allowed to open or change the target.
The distinction matters because a visible link is only the beginning of coordination. If a task appears in a message but loses its origin, the team still has to reconstruct the reason for the work. If a document is mentioned but the recipient cannot open it, the link creates another request rather than removing friction. If access follows a channel too broadly, the workspace may become easier to search at the cost of exposing information to the wrong people. Macro tries to connect these concerns, but it does not make them identical.
A block is a common identity, not a common behavior
Macro calls the entities in its workspace blocks. A document, email thread, channel, task, AI chat, CRM record, call, or canvas has a different job and therefore a different local model. Documents need editing and history. Channels need participants and threaded discussion. Tasks need a compact set of work properties. Email needs provider identity, recipients, attachments, and synchronization. A CRM record needs to organize a relationship with a company or contact. The block vocabulary gives these entities a common place in the workspace without requiring them to behave like interchangeable records.
That common identity is what makes cross-surface references possible. A task can be mentioned in a document or channel. An email can be the context from which a task is created. A pull request can be attached to the task it advances. A canvas can place a live reference to the work represented by a diagram. The user does not have to convert every object into a generic page before connecting it to another object.
Macro’s documentation describes an @mention as a live inline pill. The pill points to a selected entity and can carry current metadata, such as the status and priority of a task. That is different from copying the task’s title and status into a message. A copy is a new piece of text that can become stale. A mention is a pointer to the entity that owns the current state. Clicking the pointer can take the reader to the target, while the target’s References panel can show where it has been mentioned or embedded.
The difference between a pointer and a copy is the first important architectural consequence. A copy preserves a statement made at one time. A relationship preserves a way to ask a new question later. Where did this task come from? Which discussion mentioned this document? Which customer record is connected to this conversation? What other context points at the same entity? Macro’s value is strongest when these questions can be answered from the objects themselves rather than from a person’s memory.
The repository makes this relationship more explicit than the visual pill does. Its channel domain model represents an entity mention with both sides of the edge: the source entity’s type and identifier, and the mentioned entity’s type and identifier. It also records who created the mention and when. The mention-event model publishes created, deleted, and message-sent events keyed by the mentioned entity. That keying matters operationally. A consumer interested in one entity can find references to it across messages and documents without first knowing every possible source location.
This is enough to call the relationship durable in a useful sense. The edge has an identity and a lifecycle: it can be created, removed, surfaced as a reference, and consumed by other parts of the system. It does not mean that every consequence of the edge is durable or universal. A target can be mentioned without being shared. A mention can produce a notification on one surface but not another. An index can expose the target later than the message that created the edge. The relationship is the shared substrate; its effects still belong to the surface and policy that interprets it.
That separation also prevents a common misunderstanding about the word “graph.” Macro does not need to display a network diagram every time a user writes a message. Most of the time, the graph is experienced as small conveniences: a live pill, a backlink, a preview, or a jump to the source discussion. The graph becomes visible when a user follows an edge in the reverse direction or needs to understand why an item is available. Its purpose is not visual complexity. Its purpose is to keep context from disappearing at a boundary between blocks.
A reference has three different effects
A useful way to analyze a Macro mention is to ask three questions in order.
Can the recipient navigate to the target? This is the reference effect. In a document, chat, task description, or channel message, the mention is a navigable pointer. The target can expose the backlink in its References panel. In an agent prompt, the mention can also identify the exact context the agent should read.
Should someone be notified? This is the attention effect. Mentioning a person in a channel or comment can create a notification. Mentioning a person in the body of a document does not notify them, because the document may still be in progress. Assigning a task notifies the assignee, while naming a person in the task body does not. The same visual @ syntax can therefore represent different communication intent.
Does the recipient gain access? This is the permission effect. A channel mention can share a referenced document or task with channel members under Macro’s channel-based policy. A document embed is read-only and does not automatically grant access. A CRM company or contact is governed by team rules, not by the fact that someone mentioned it. A public document link is a separate boundary because anyone with the URL may read it.
These effects often reinforce one another, but they cannot be collapsed into one rule. A reference without access is a pointer to something the reader cannot use. A notification without access tells someone that a fact exists but does not give them the context to act. Access without a notification can be appropriate when a team member needs the shared record but should not be interrupted. The design question is not whether Macro should choose one universal behavior. It is whether each surface’s behavior is predictable enough for the consequence it creates.
The following diagram is a conceptual view of that separation. A source block can create a mention of a target block. The target can expose a backlink. A channel contributes membership and may contribute an access grant. A notification is possible, but it is not the same edge as access.
The channel-sharing path shows how these edges meet in an actual operation. When a channel message is posted, Macro stores the message and its mentions. The service also identifies referenced entities in message mentions and attachments. For supported entity types, it asks an access service what the actor can already see. That check is essential: the person posting a link cannot use the channel as a way to grant access to an item they themselves cannot view.
If the actor has the necessary access, a separate sharing capability updates the target’s channel-based visibility. Ordinary referenced entities receive view-level sharing through this path. Agent sessions are treated differently: Macro’s policy permits edit sharing only when the actor is the owner. The implementation then updates the relevant channel permission and entity-access records. In other words, the message service owns the event of posting, while a permission adapter owns the persistence of the access consequence. Neither side has to pretend that a mention, a notification, and a permission row are the same object.
This boundary is valuable for more than code organization. It gives the system a place to enforce privilege non-amplification. It also makes a failure easier to reason about. If the message is saved but a sharing side effect fails, the channel still contains a reference, but the intended access may not have been established. If the target is deleted, the reference may remain as historical information while navigation degrades. If the user loses channel membership, the access derived from that channel should no longer be treated as a permanent personal grant. Relationship and authorization have to be reconciled over time.
The exceptions are part of the contract
Macro’s sharing rules become clearer when read as responses to the different risks of each block. The platform does not claim that one permission rule can fit every context.
Documents and comments. A mention in a document body is usually part of an unfinished artifact. Macro therefore does not treat it as an automatic notification or share event. A comment is different: it is a discussion addressed to people, so an @mention there can notify the person once the document is shared with them. This preserves the difference between drafting content and asking someone to respond. It also means that a person named in a document may not know the document exists unless the owner shares it explicitly.
Channels. Channels are the clearest case for coupled reference and permission. When a person mentions a document or task in a channel, the item is shared with channel members under the channel policy. Adding a participant can make previously shared items available; removing a participant can remove that channel-derived access. This is why channel membership is more than a roster. It becomes an operational control over the context made available in the channel.
Email. Email has a different social and security shape. Mentioning a person adds them as a recipient. Mentioning a Macro document creates a link, and the product documentation says the document’s permissions are updated so recipients can view it. But email does not use the same automatic channel-sharing rule. Messages can be forwarded, new recipients can be added, and an email’s eventual audience is not known when it is written. Treating every recipient as a permanent member of a shared context would be difficult to control.
CRM records. A company or contact record is not shared merely because someone mentions it in a channel. Macro puts CRM visibility under team rules and Email Sync. When Email Sync is enabled for a company, relevant team email threads become visible in the CRM; when it is disabled, the record can remain while those threads stay private to their participants. This is a reminder that a CRM record represents a relationship with its own governance, not just another document that can be passed around by reference.
Tasks and calls. Team defaults can supply access without a channel mention. Tasks are automatically shared with team members in a team workspace. Calls are placed in team memory by default, but a call can opt out and remain in personal memory. These rules fit the coordination purpose of the blocks, but they also make team membership and call-level choices consequential. A user evaluating a shared workspace needs to know which context is visible by default, not only which context can be linked manually.
Agent sessions and public links. Agent sessions have stronger control requirements because access can include the ability to influence an ongoing or saved interaction. The channel-sharing policy distinguishes owner-authorized edit sharing from ordinary view sharing. Public document links are stronger still in the other direction: they can make a document readable to people without Macro accounts. A public link is therefore not a convenience equivalent to a channel mention. It is an explicit decision to move the item outside ordinary workspace membership.
These exceptions may seem less elegant than a single rule, but the alternatives are worse. A universal “mention means share” policy would expose unfinished documents, CRM records, or email-derived context in situations where the author did not intend that result. A universal “mention never shares” policy would restore the request-and-forwarding friction that Macro is trying to remove from channels. The product instead makes the edge depend on the container, the entity type, and the actor’s existing authority.
The cost is that users must learn more than the syntax. The @ character tells you that a relationship is being created, but it does not tell you whether the target will be shared, whether the named person will be notified, or whether they can edit it. Macro’s own documentation calls out several of these differences as design decisions. That is a real adoption and governance cost: a team needs conventions about where sensitive work is discussed, how channels are formed, when to use public links, and which CRM or call defaults are acceptable.
A Macro link is therefore best understood as a typed relationship with policy attached. The relationship supplies provenance and reverse navigation. The container may supply access. The surface may supply notification. The target’s own rules determine whether the recipient can view or edit it. Once those distinctions are in place, a channel message can preserve not just what a team said, but the work object the conversation is about and the people who are meant to act on it. The next question is what happens when that object moves from discussion into execution: how a message or email becomes a task, how a task follows a pull request, and how the chain keeps its original context.