Skip to main content
Delegate a Linear issue to Macroscope and an agent picks it up: it reads the ticket, works the task on a cloud VM, opens a pull request, and streams its progress back into the issue as an activity timeline. Follow-up comments in Linear reach the running agent, and the agent keeps shepherding the work — CI failures, 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.

​
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

Delegated agents are machine agents — they run under a service profile, not a personal account. By default, delegations use a service profile accessible to all users in your organization; create one under Organization Settings → Service Profiles on the dashboard. A flight can set its own service_profile instead, so if every delegation is routed through flights, the shared profile is not needed. Without either, delegations fail with an actionable error in the Linear session.
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.
  • 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.

​
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 is assembled as: the ticket’s routing facts (team, labels, project), then the ticket content (title, description, comments), then the flight’s body. So the flight’s prose reads as instructions about the ticket, and the agent always sees both.

​
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 it — dependencies, gates, 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