Skip to main content
Delegate a Linear issue to Macroscope and an agent picks it up. It reads the ticket, works on a cloud VM, opens a pull request, and streams progress back to the issue. Follow-up comments in Linear reach the running agent, which continues handling CI failures and review comments until the task lands.

​
How it works

  1. You delegate an issue to the Macroscope agent in Linear. Linear opens an agent session on the issue.
  2. Macroscope acknowledges within seconds: “Picking up this issue — getting started.”
  3. The platform matches the issue against your flights. A flight with a matching linear_delegation trigger controls how the agent spawns: workspace, persona, model, instructions. With no matching flight, the agent spawns directly from the ticket.
  4. The agent works the task and posts progress to the session: status updates, pushed commits, the opened pull request, and a final result. The PR and the agent’s dashboard page are attached to the session as links.
  5. The agent stays reachable. Prompting the session sends a follow-up to the same agent; stopping the session interrupts its current turn.

​
Who the agent runs as

Every delegation is authorized against the person who delegated the issue. Their Linear account must be linked to a GitHub account that belongs to your organization, and your organization must permit that person to start agents (agent.create) — the same permission they need to spawn an agent themselves. What the agent then runs as depends on the flight the issue matches: A delegation that fails any of these checks is refused with an explanation in the Linear session, and nothing starts. It never falls back to a service profile the delegator could not have used themselves: delegating an issue reaches exactly what that person reaches by spawning the agent from the dashboard.
A service profile whose access grants are open to your whole organization can be used by everyone who can delegate in Linear: any member of your Linear workspace whose GitHub account is in your organization can spawn an agent under it. Narrow the grants to the people who should use the profile, or omit service_profile so each delegation runs as the person who asked for it.

​
Setup

1

Install the Macroscope GitHub App

Your GitHub org is your tenant. If you haven’t already, install the app at app.macroscope.com; see the admin quickstart.
2

Connect Linear to Macroscope

Connect your Linear workspace to your organization at app.macroscope.com. This installs the Macroscope agent in Linear and links the Linear workspace to your GitHub org, so delegations route to your tenant.
3

Create a service profile

A delegation that matches no flight runs under a service profile accessible to all users in your organization; create one under Organization Settings → Automations → Service Profiles on the dashboard. A flight can set its own service_profile instead, or omit it to run as the person who delegated the issue — so if every delegation is routed through flights, the org-wide profile is not needed. Without either, delegations are refused with an actionable error in the Linear session.
4

Have your delegators connect GitHub in Linear

Each person who delegates needs GitHub connected in their Linear account settings, under a GitHub account that belongs to your organization. That is how Macroscope tells whose delegation it is.
Linear delegation is enabled per organization. If a delegation responds with “This feature is currently disabled”, contact the Macroscope team to enable it for your org.

​
Delegating an issue

In Linear, delegate the issue to the Macroscope agent: assign the issue to the agent, or delegate it from the issue’s menu. Linear creates an agent session on the issue, and everything the agent does shows up there. What you’ll see in the session:
  • Acknowledgement: “Picking up this issue — getting started.” within seconds.
  • An autopilot note: the agent runs in autopilot: after the initial work lands (e.g. a PR is opened), it keeps monitoring CI failures, review comments, and base-branch conflicts, and continues shepherding the task automatically. Every update includes a link to the task’s Murmur settings where you can toggle autopilot features off.
  • Progress activity: status updates as the agent works, pushed commits, and an “Opened pull request” action linking the PR.
  • Links on the session: the agent’s Murmur dashboard page and the pull request, attached as external links.
  • A final result: a completion response, or an error explaining what went wrong.
The agent’s task description is the ticket itself: the issue’s title, description, and comment context as Linear provides them.

​
Where the agent runs

The spawned agent gets a stable identity derived from the issue: ENG-123 becomes agent linear-eng-123, and is tagged linear-<your-name> so you can filter your delegations on the dashboard. The dashboard link in the session pre-selects that filter. Which workspace the agent uses:
  • A flight matched: the agent runs in the flight’s workspace, with the flight’s persona, model, and instructions. See Customizing delegations with Flights.
  • No flight matched: the platform selects a workspace (and persona) automatically, weighing the ticket’s full metadata: team, project, labels, priority, and description. If your org has a single workspace, it’s used directly.
Automatic selection is a reasonable default, but flights make routing explicit and repeatable. If delegations should land in a specific workspace with specific instructions, define a flight.

​
Follow-ups, stop, and revival

The delegated agent sleeps when idle instead of terminating, so the Linear session stays live for its whole life:
  • Prompt the session: your message is queued as a follow-up to the same agent, with its full conversation context. Use this to answer questions, redirect the work, or request changes.
  • Stop the session: interrupts the agent’s current turn. The agent stays alive and reachable; prompt it again to continue.
  • Who can do either: anyone in the session, for an agent running under a service profile. An agent running as a person is prompted and stopped only by that person, since both acts spend their access.
  • Revival: if the agent has since been torn down, prompting the session revives it in place with its full conversation history. Same agent, same session: the follow-up is never dropped. A revived agent re-establishes the access it runs on, so a service profile the organization has stopped sharing, or a person who no longer has permission to start agents, stops the revival with an explanation in the session.

​
Customizing delegations with Flights

A flight is a Markdown document in your catalog that defines how agents spawn: which workspace they run in, what persona and model they use, what instructions they follow, and, for multi-agent flights, a DAG of agent tasks a pilot orchestrates. Adding a linear_delegation trigger to a flight routes matching delegations through it.
With this flight in place, every issue delegated from the ENG team spawns a programmer agent in the backend workspace, with the flight’s prose appended to the ticket context as standing instructions.

​
Matching rules

The linear_delegation trigger supports three optional filters, matched against the delegated issue: All filters on a trigger must match (AND semantics). A trigger with no filters is a catch-all that matches every delegation. Unlike GitHub event triggers, linear_delegation triggers take no repos list: routing is by ticket attributes, not repository. When several flights match the same delegation, the highest priority (a frontmatter field, default 0) wins. Two flights at the same priority with overlapping triggers are rejected when you write them, so the winner is always unambiguous. A common pattern is team-specific flights at priority: 10 plus a filterless catch-all at priority: 0:
If no flight matches, the delegation falls back to the default behavior: automatic workspace and persona selection from the ticket metadata.

​
What a flight controls

The agent’s prompt contains the ticket’s routing facts (team, labels, project), followed by the ticket content (title, description, comments) and the flight body. The flight prose serves as instructions about the ticket, and the agent receives both.

​
Running as the person who delegated

A flight whose only trigger is linear_delegation may leave service_profile out. Its agents then run as the person who delegated the issue — the same agent they would get by spawning the flight themselves, on their own account settings, model and inference connections, git identity, and GitHub access.
Use this when the work should carry the delegator’s own identity and reach exactly what they can reach. Use a service_profile when the work needs a stable machine identity with its own access, independent of who assigns the ticket. Every other kind of flight still needs a service_profile, because nobody invokes an individual run: a schedule, a repository trigger, messages, daemon: true, and any flight that combines one of those with linear_delegation. On top of what every delegation requires, the delegator’s own Macroscope account must be able to act on GitHub as them, since the agent uses their GitHub access rather than a profile’s. Every one of those checks runs again on each turn, not only when the issue is assigned, whether the agent is awake or asleep. If the person has since left the organization or lost permission to start agents, the session says so and takes no further turns until that changes. One change cannot be undone: an agent is filed under its owner’s GitHub login, so renaming that account ends the sessions of agents already running as them. Those sessions say so and ask you to delegate the issue again, which starts a session under your new login. Work already pushed is unaffected. Only the person the agent runs as can prompt or stop the session: both acts run as them, on their account. A prompt or stop from anyone else is declined in the session. To get the same work done as yourself, delegate the issue to the agent — that starts a session of your own.

​
Multi-agent flights

A flight with H2 agent sections runs as a pilot. The delegated agent reads the flight’s DAG and orchestrates sub-agents through its dependencies, gates, and fanout, exactly as described in multi-agent orchestration. The pilot is the agent bound to the Linear session, so progress and follow-ups flow through it.
Unlike GitHub-triggered flights, which terminate when idle, a flight spawned from a Linear delegation sleeps when idle, so prompting the ticket always reaches the pilot.

​
Troubleshooting