Why a workspace needs more than integrations
Macro, the open-source macro-inc/macro workspace, is best understood through a problem that sits underneath its feature list: work loses meaning when the relationships around it are scattered across tools. This chapter examines why Macro treats that loss as a product and systems problem, not merely a matter of having too many tabs. The practical payoff is a mental model for judging whether a workspace is genuinely integrated: can it preserve why a piece of work exists, who can use it, what state it is in, how to find it, and what someone—or an agent—can do next?
Macro’s answer is to make context durable. Email, messages, documents, tasks, CRM records, calls, files, and agents remain purpose-built surfaces, but they are meant to participate in one connected workspace. That is a stronger claim than “these applications have integrations.” It says the relationships among the surfaces should survive the handoffs where organizations most often lose information.
The problem is context loss, not just too many tabs
Macro’s own origin story begins with a growing startup using good products for different jobs: Slack for conversation, Linear for work tracking, Notion for documents, HubSpot or Salesforce for customer information, and Superhuman for email. Each product could be useful on its own. The failure appeared between them. The team had to carry decisions from one system into another, maintain integrations, and remember which system contained the latest explanation. MCP and Zapier could connect actions, but a connection that moves data is not necessarily a connection that preserves meaning.
Consider a small but consequential chain. A customer reports a problem in an email. Someone discusses it with engineers in a channel. An engineer creates a task, a pull request implements the fix, and a customer-facing teammate needs to know what changed. In a fragmented stack, the task may contain a compressed paraphrase rather than the original report. The pull request may mention an issue number without the customer context. The CRM may show a company and a last interaction but not the engineering discussion. Each handoff creates an opportunity for omission, delay, or conflicting versions of the truth.
This is why Macro’s description of the “company was not computable” is more precise than a complaint about inconvenience. A company is computable, in this sense, when its important entities and relationships can be retrieved and acted on without reconstructing them by hand. A message is not only text. It can be the origin of a task. A task is not only a status and assignee. It can carry the reason for the work and connect to the code that completes it. A company record is not only a row in a CRM. It can be a view over conversations, emails, contacts, and decisions.
The distinction matters because simply putting several tools behind one login solves only identity and navigation. It does not answer the harder questions. Does a link point back to its origin? Does a new teammate gain access to the context they need? Does a status change in the execution system update the work record? Can a person search across the content without knowing which application contains it? Can an agent use the same relationships rather than interrogating every system separately?
Macro’s design premise is that these questions should be answered by the workspace itself. The claim is not that a single product makes coordination automatically good. It is that the product should own enough of the underlying relationships that coordination does not depend on a permanent layer of manual translation.
That distinction exposes why ordinary integrations often feel more complete on a diagram than they do in daily work. An integration may copy a task title into a project tracker, send a notification into chat, or attach a record ID to an email. But the receiving system may not know which conversation created the task, which people were meant to have access, whether the copied status is current, or what evidence should be consulted before the task is closed. The data has moved while the responsibility for interpreting it has remained with the team.
There is also a question of ownership. If a customer update changes an engineering task, which system is allowed to decide that the task is now urgent? If a person leaves a project channel, which copied documents should disappear from their view? If a pull request is merged, which record should reflect completion? These are not merely transport questions. They are decisions about identity, authority, timing, and consequences. A connected workspace can make them explicit because it has a chance to preserve the relation and the policy together.
Macro’s proposal is consequently closer to a shared context layer than to a bundle of synchronized screens. It tries to keep the object, its references, and the action paths around it available to each surface. That does not remove the need for judgment. It changes the default from “someone must remember to join the dots” to “the system should retain the dots unless a boundary says otherwise.”
Blocks are specialized surfaces inside one workspace
Macro calls the entities in its workspace blocks. Documents, email, channels, tasks, AI chats, CRM records, calls, and canvases are different kinds of blocks, with different purposes and different interfaces. The word is useful because it identifies the common unit without pretending that the units behave identically.
A document needs collaborative editing and history. A channel needs conversation, participants, and threads. A task needs a compact work state. An email needs sender, recipients, attachments, and provider synchronization. A CRM record needs a durable view of a relationship with a company or contact. If Macro forced all of these into one generic database primitive, it might gain formal uniformity while losing the qualities that make each surface useful. Its stated approach is the reverse: keep the surface purpose-built, but let the blocks share a context substrate.
The benefit of this arrangement is not that a person sees every detail everywhere. It is that each surface can show the detail appropriate to its job while still pointing to the same context. A channel can discuss a task without becoming a task board. A task can expose its originating message without turning into a transcript. A CRM record can aggregate the relationship with a company without pretending that every email is a pipeline stage. The common layer supplies continuity; the specialized surface supplies focus.
This is a subtle but important architectural choice. Generic systems usually make their shared primitive visible, asking users to assemble workflows from fields, pages, and links. Macro instead makes the block’s job visible and tries to make the relationships underneath it reusable. The integration is judged by what remains intact when the user changes views, not by how many menus or connectors the product contains.
That substrate appears in several forms. A task can be mentioned in a message or document. An email can be the source of a task. A pull request can be attached to the task that led to it. A canvas can place live references to the work it represents. A block’s References panel can show where it has been mentioned or embedded. The result is not one giant screen. It is a set of views over entities that know how they relate.
The difference between a block and a conventional record is especially important for changing information. Macro describes mentions as live pills that carry current metadata: a task mention can show its current title, status, or priority rather than freezing the values that existed when someone wrote the message. This makes the relationship useful after the original conversation. The reader can move from the current task back to the discussion that created it, or from the discussion forward to the task’s present state.
That design also explains why Macro can offer a unified inbox and unified search without making either one the whole product. The Inbox is an attention-oriented view. Search is a retrieval-oriented view. Memory is a synthesized background view for agents. None of them replaces the block that owns the underlying work. They are projections of a connected system, each optimized for a different question.
The diagram’s most important arrow is not from one feature to another. It is from the blocks to the relationships that connect them. The same task may appear in a channel, an inbox, a search result, a document, a CRM discussion, and an agent’s context. Those appearances are valuable only if they still refer to the same underlying work and respect the rules governing who can see or change it.
Integration is a relationship, not a pile of features
This gives Macro a useful initial model. A context-native workspace needs to preserve at least five things as work moves between surfaces.
Origin answers why the work exists. A task created from a customer email or a bug report should not require someone to rewrite the original rationale from memory. Access answers who is allowed to use the context. A reference that is visible to one person but inaccessible to the people expected to act on it has not solved coordination. Current state answers what is true now: the task’s status, the latest conversation, or the pull request’s position in its lifecycle. Retrieval answers how someone finds the relevant material when they do not remember its exact location. Action answers what can happen next: create a task, edit a document, reply in a channel, or ask an agent to carry out a bounded operation.
These dimensions reinforce one another. Without origin, current state becomes a detached status label. Without access, retrieval can expose a pointer that cannot be opened. Without retrieval, preserved relationships remain technically present but practically invisible. Without action, the workspace becomes an archive rather than a working system.
The model also prevents an easy overstatement. One workspace does not automatically create one source of truth. Macro’s own documentation distinguishes mentions, notifications, and permissions by surface. A document embedded in another document can be read-only and may still require separate sharing. A mention in a document body does not have the same notification effect as a mention in a comment. Email follows different rules because recipients can be added or forwarded. CRM visibility is governed by team settings and email synchronization rather than by every mention. Search depends on indexing, and memory is a synthesis rather than a live transcript.
Those differences are not side notes. They are the conditions under which Macro’s central idea can work. The value comes from preserving meaningful edges while allowing each block to retain the semantics of its job. The risk comes when a user assumes that every edge behaves like every other edge.
Macro therefore asks a more demanding question than “Can these tools integrate?” It asks whether a team’s important work can remain legible across the points where conversation becomes execution, execution becomes evidence, and evidence becomes the next decision. The next step is to inspect the mechanism that makes those edges real: how blocks record references, and how a channel can make context available without turning every mention into unrestricted access.