From conversation to completed work
Macro’s task model is a test of whether its context graph helps with real work rather than merely connecting nouns. This chapter follows one work item from a channel message or email into a task and then toward a GitHub pull request, while asking what each relationship preserves for the team. The practical goal is to distinguish a task that carries its reason and current evidence from a task that is only a title, assignee, and status in another silo.
The path matters because Macro designs task creation around conversation. A customer describes a problem, a teammate adds a technical detail, and someone decides that the organization should act. If the task system receives only a cleaned-up sentence, it may be easy to sort but hard to trust. Macro tries to keep the originating context attached as the work changes form.
The origin of a task should stay attached
Macro’s documentation describes task creation as deliberately close to the places where work is discussed. A teammate can create a task from a channel message or customer-support email, from a document or checklist, or from an agent conversation. The exact entry point can vary, but the design principle is stable: the person who recognizes the work should not have to leave the conversation, open a separate tracker, and reconstruct the background in a new record.
This is a response to a familiar failure in issue tracking. A traditional tracker often asks for a summary, a title, an owner, and a status. Those fields are useful for management, but they are not the same as the evidence that caused the work to exist. The original report may contain a reproduction detail. The channel thread may contain a decision about scope. The customer email may explain the consequence of delay. If those details are paraphrased into a task and the source is lost, the task can remain technically up to date while becoming semantically thin.
In Macro, the creating context can remain linked to the task. A bug report in a channel is not merely the event that preceded task creation; it is a related object that can be revisited. The same applies when a task begins with an email or a planning document. That relationship lets a reader ask two questions from either direction: why was this task created, and which work item came out of this discussion? The task becomes a context node with a history, not just a row in a list.
The distinction between a link and a copied summary is important here. A copied summary is useful when a human has already decided what matters, but it also freezes the author’s interpretation. A link keeps the source available for verification. It lets an engineer inspect the original report, a product lead inspect the decision that shaped scope, or a support teammate see what the customer actually asked. Macro’s bidirectional-linking model does not eliminate summarization; it gives the summary a route back to evidence.
That route also changes how an agent can participate. An agent asked to turn a product document into tasks can create work items while retaining the document as their source. A person reviewing those tasks can move backward to the requirements instead of trusting an opaque generated list. The useful unit is not “AI created five tasks.” It is “these tasks remain connected to the document and can be checked against it.”
This design reduces one kind of coordination cost, but it does not make the task self-explanatory. A link can point to an unfinished document, a noisy channel, or an email that some teammates cannot access. The task still needs a clear title, an appropriate owner, and enough local explanation to be actionable. Preserving origin is a way to keep evidence available; it is not a substitute for deciding what the evidence means.
It is useful to separate the task’s own state from the context it points toward. The task owns the question of what work the team has decided to track: its title, properties, assignee, and status. The originating message or email owns the historical account of what prompted that decision. The document may own the requirements, while the pull request owns the code review and change set. A link lets these owners remain distinct without making the reader traverse an unrelated toolchain to compare them.
That separation makes the task a coordination boundary. A support teammate can start with the customer’s language, an engineer can work from the task’s scope, and a reviewer can inspect the pull request. Each person sees a surface shaped for their job, but the edges between the surfaces make the handoff inspectable. If the scope changes, the team can return to the original discussion and see whether the task still represents it. If the task is closed, the source remains evidence of the decision rather than disappearing behind the final status.
The relationship is also useful when the work begins somewhere less structured than a channel. A planning document can contain a checklist item that becomes a task. An agent can turn requirements into several tasks. An email can create work before anyone has decided which team channel should own it. In each case, the task can enter the structured work system without requiring the source to be copied into a new, authoritative-looking paragraph. Macro’s model makes the edge the place where the transition is recorded.
The work lifecycle can be pictured as a sequence of state changes and projections rather than a list of independent applications:
The arrows do not mean that every step happens automatically in every account. They show the intended direction of context: conversation gives the task a reason, the task gives execution a place to report state, and the resulting work becomes visible through the workspace’s common views. The useful property is that the path can be followed in both directions.
The task does not finish at creation
A task’s value increases when its state reflects work that is happening elsewhere. Macro’s GitHub integration is the clearest documented example. After a task is connected to the code workflow, creating a branch moves it to In Progress, opening the pull request moves it to In Review, and merging the pull request moves it to Done. The pull request appears on the task with identifying information and a route to the code.
These transitions do more than save someone a status update. They give the task a relationship to an external event that is meaningful to engineers and reviewers. “In Review” is not simply a label someone typed because the work feels nearly finished; in the documented flow, it corresponds to a pull request being open. “Done” is tied to the merge event rather than to a person remembering to close the task after deployment. The task remains a work-facing record while GitHub remains the execution-facing system.
That division of responsibility is a strength of the model. Macro does not need to reproduce every code-review interaction to keep the work state visible. GitHub owns the pull request and its lifecycle. Macro owns the task as a connected object and projects the relevant state into it. The integration is useful precisely because the systems do not have to become identical.
It also creates a condition for failure: a status is only as current as the relationship that supplies it. The account must be connected. The branch or pull request must be associated with the task. Events must reach the integration. If a task is created without that association, its status may remain manual even while code work advances. The documented workflow supports a strong chain under its stated conditions; it does not prove that every task in every repository will discover the right pull request without setup or correction.
Team context adds another layer. Macro says that tasks created in a team workspace are shared with team members by default, and that assigning a task produces an Inbox notification. This means a task can become visible to people who were not in the original channel conversation. An engineering task can be seen by a manager, a support teammate, or another engineer who needs to understand the current workload. The visibility comes from team policy, while the origin link supplies the missing background.
A customer-facing relationship can be connected in a similar way through Macro’s CRM. The CRM builds company and contact records from team email, and Email Sync can make relevant company email threads visible to teammates. A discussion attached to a company record is also available in the same workspace and can be queried by an agent. This does not mean that every task automatically becomes a CRM event. It means the task, customer conversation, and company record can occupy one context system when the relevant references and team settings are in place.
That distinction matters in a cross-functional case. Suppose a customer reports a defect and an engineer creates a task from the email. The task can preserve the customer’s original report. GitHub can later provide the implementation state. The CRM can provide the broader relationship with the company if Email Sync allows those threads to be shared. The support teammate does not need to ask the engineer for a fresh summary merely to learn whether the fix is in review. Each surface answers a different question, but the relationships reduce the distance between the answers.
The Inbox then acts as an attention layer over this chain. Assignment can notify the responsible person. A channel response, a shared email, or an agent result can appear alongside the task. But marking an Inbox item done is not the same as completing the task. Macro’s notification lifecycle—unseen, seen, and done—is separate from email read state and from the underlying work state. The Inbox tells a person what deserves attention; the task and its linked systems record what has happened to the work.
This separation prevents a subtle category error. If a manager marks a task assignment as seen, the task should not become complete. If a teammate marks a notification done after reading a pull-request update, the pull request has not changed. Conversely, a task can move to Done through the GitHub workflow even if a person has not yet cleared every related notification. Attention and execution are connected, but they are not the same state machine.
The GitHub transitions should also be read as evidence about the code workflow, not as a guarantee about deployment. A merged pull request is the documented trigger for the task’s Done state; that state alone does not establish that the resulting software is already deployed, that the customer has been notified, or that all follow-up work is complete. This is a healthy division if readers understand what the state represents. It becomes misleading if a team treats one synchronized status as a complete account of delivery.
The same principle applies to work that changes direction. A task may move from a channel discussion into a pull request, but a later customer reply can change its scope. The original message remains useful because it records the initial reason; the current task and conversation record the new decision. A graph does not freeze the organization’s understanding. It makes the sequence of understanding easier to inspect.
For a manager, this creates a better question than “Are all tasks up to date?” They can ask which edges are authoritative for the decision at hand. GitHub is authoritative for the pull-request lifecycle. The task is authoritative for the team’s tracked work and properties. The channel or email is evidence of discussion and request. CRM is the relationship context when its sharing settings include the relevant mail. Inbox is the person’s attention queue. Keeping these roles separate reduces the temptation to use a convenient but incomplete view as the whole truth.
The chain also shows why CRM and team sharing cannot be treated as universal automatic access. Macro’s documentation says CRM visibility is governed by team rules and Email Sync, not by merely mentioning a company or contact. A task may be team-visible while a related email remains private. A channel member may be able to see the task but not an embedded source document if that document was not shared under the relevant rule. The existence of an edge does not erase the access boundary around the target.
Human judgment remains at several transitions. Someone decides whether a message represents work worth tracking. Someone chooses the task’s scope and owner. A product or sales team may still have to set a CRM stage manually; a connected system cannot infer every organizational decision from an email. Someone must check that the linked pull request is the one that actually addresses the task. The point of Macro’s model is not to automate away those decisions. It is to make the evidence and current state available where the decisions occur.
The most reliable reading of Macro’s task workflow is therefore conditional. When the origin is linked, the relevant people can access it, the external integration is connected, and the events synchronize, a task can preserve a continuous path from reason to execution. When any of those conditions fails, the task can fall back toward the familiar isolated tracker: a useful status record that requires a human to recover the missing context.
Macro’s contribution is to make the stronger path the intended default. Conversation can create work without abandoning its source. Code can update work state without asking an engineer to duplicate it. Team sharing, CRM context, Inbox attention, and Search can expose the same object for different purposes. The resulting history is more valuable than a pile of independent records because it answers not only “what is the status?” but also “why is this here, who can act on it, and what evidence supports the status?” The next problem is scale: when many such chains are active, how can a person or agent find the right one, decide what needs attention, and distinguish current retrieval from synthesized memory?