Work tracker sync

Keep planning in Linear and let agents work the issues

Connect a Linear workspace and map team to team, so agents pick up Linear-born issues while status, comments, and assignees stay current both ways.

Join the waitlist See the Linear example

Linear with Aestus

Keep the tool. Change what the team can see.

Linear is where the team decides what to build. Aestus is where the doing gets supervised. An issue filed in Linear is picked up by an agent, worked under a policy, and returned with a status transition and a comment — without anyone copying a ticket by hand or asking the team to plan somewhere new.

The pairing is team to team. One Linear team maps to one Aestus team, with its own state map and its own direction setting, so a single workspace runs one team two-way while another stays import only. Priorities, labels, sub-issues, assignees, and comments cross in both directions. Cycles and estimates are kept alongside the issue so nothing is lost, but this first version neither manages them nor shows them inside Aestus.

Two-way sync fails in predictable ways, so the connection names them rather than discovering them in production. Aestus authorizes as its own app user, keeps a ledger of what it wrote, and compares normalized content — three separate reasons an inbound event that is merely its own echo gets dropped. Webhooks are a speed-up rather than a guarantee: a sweep re-reads each mapped team from its watermark, including archived issues, so nothing depends on a delivery that never arrived.

Good first workflows

Give triage a worker
Map the triage state to a ready column and let an agent take the small, well-specified issues.
Keep one team two-way
Run a single Linear team two-way while the rest of the workspace stays import only.
Report to the team that planned it
Send the outcome back as a status change and a comment, where the people who filed it already look.

A complete Linear example, from trigger to proof.

The example names the people, task event, tool boundary, returned evidence, and acceptance state. The run row below it is a fixed product example, not customer data.

Example — fictional team and data. Not a live run or customer result.

Inside the connected tool

What the result looks like in Linear

The team keeps planning in Linear and reads the outcome there: the state moves and one comment lands from the app.

ENG-311

Import rejects valid EU currency rows

Status: In Review
Priority: Urgent
Assignee: Aestus coding agent
Labels: triage · import
Cycle: Cycle 24

Activity

Aestus APP changed status from In Progress to In Review
Aestus APP Fix opened as PR #318. Nineteen import tests pass; the valid EU matrix is unchanged.

Aestus ticket · PLAT-96 · accepted by Sofia

Example — fictional team and data. Not a live run or customer result.

Concrete workflow example

Let an agent work a Linear issue without leaving Linear

A triage issue filed by support in Linear is assigned to an Aestus agent. The team keeps planning where it always has, and the result comes back as Linear updates.

TriggerENG-311 is assigned to the Aestus coding agent

1
Sofia · Support
Files the issue in Linear as usual
The reproduction, priority, and team labels are set in Linear; nothing is re-entered anywhere.
ENG-311 · urgent · Triage
2
Aestus sync
Mirrors the issue onto the mapped team board
The Linear team maps to one Aestus team, and the workflow state maps to a column on that board.
pair ENG ↔ PLAT · Triage → Ready
3
Aestus coding agent
Works the issue and returns the fix
The run reports its phases, opens the pull request, and records tokens, latency, and cost.
EXAMPLE-LN-01 · PR #318
4
Aestus sync
Returns the transition and one comment to Linear
Sofia reads the outcome in Linear; the write is stamped as the app's own and never echoes back.
ENG-311 → In Review · 1 comment

Example — fictional team and data. Not a live run or customer result.

Deterministic product example — not a production run

Work the Linear-born triage issue

Example run		Runtime	Outcome
EXAMPLE-LN-01	Aestus coding agent	aestus	Completed	$0.03	58.0s

Tokens in / out: 12,600 / 700
Failure code: —
Agent: coding-agent

Example source: lib/marketing/integration-run-examples.ts

Example run cost

$0.0284 in the worked example on this page

The figure is a fixed illustration drawn from comparable Aestus coding-agent runs, not a measurement of a Linear sync that has run. It stands for one agent run of 12,600 input tokens, and keeping the two sides in step adds no second run.

Set it up in four steps.

Follow the real Linear connection path. Provider steps link to the provider documentation. Aestus steps name the contract they follow.

01
Connect the workspace
An organization admin opens Settings, Integrations, then Linear and authorizes the workspace. Aestus installs as its own Linear app user, so its writes stay identifiable.
Aestus contract: docs/linear-sync-setup.md
02
Pair a Linear team with an Aestus team
One dialog names the Aestus side, the Linear team, a direction — two-way, import only, or export only — and a label policy.
Aestus contract: docs/linear-sync-setup.md
03
Map the states, then the people
Both are separate screens, reached from the pair once the pair exists. Linear's stable state types supply the column defaults, and any state can be pinned. People match by email in one press, because Linear publishes member addresses. Do both before the first import.
Read the provider docs
04
Preview the import, then run it
The dry run reports what it would create without writing. You run it for real once the counts look right, and a long backlog picks up where the last run stopped.
Aestus contract: docs/linear-sync-setup.md

The boundary stays visible while the work moves.

See what Linear can do, where a person still decides, and what Aestus records for every governed run.

Where control lives

One admin owns the connection

The Linear workspace is authorized once at the organization level. Individual agents never hold Linear credentials.

Direction is a per-pair choice

A cautious team starts import only and turns on outbound writes for one pair at a time.

Disconnecting is a decision, not a cliff

Ending the connection asks one question first: keep the imported tickets as ordinary Aestus work, or archive them. Your tickets and projects are never deleted. What is erased is the personal data Aestus copied from Linear — the person mappings, and the author name on every imported comment — because that is somebody's, not ours to keep.

Acceptance stays an Aestus decision

A status transition arriving in Linear is delivery evidence. Whether the work is accepted remains a named decision on the card, as it already is today.

What Aestus records

Both sides of every change

The identity map holds the Linear issue, its identifier, and the normalized content Aestus last agreed with, so a conflict has a readable history.

Run economics stay with the run

A synced issue does not create a model charge. Cost, tokens, and latency belong to the agent run that worked it, exactly as they do for any run today.

Skipped echoes are visible

Every inbound event Aestus drops as its own echo is written to the event log rather than discarded silently.

A withdrawn sign-in is named, not guessed

If the Aestus app is removed on the Linear side, Linear tells us and the connection reports that it has stopped, instead of failing quietly on the next write. Nothing already imported is removed.

Questions teams ask

Can we use this today?

Yes. An organization admin connects the Linear workspace in Settings, Integrations, Linear, pairs a team, previews the import, and runs it. A change made in Linear reaches the board in seconds, and a reconciliation sweep runs every fifteen minutes underneath as the backstop.

Do our issues have to move into Aestus?

No. Planning, cycles, and triage stay in Linear. Aestus holds the operations record for the work an agent performs on those issues.

Can a change bounce between the two systems?

No. Aestus writes as its own Linear app user, keeps a ledger of what it wrote, and skips any inbound event that would be a no-op.

See all integrations See the security controls

Start with one Linear run.

Bring one real run. Map its actors, boundary, evidence, cost, and acceptance step.

Talk to us

Example — fictional team and data. Not a live run or customer result.

Concrete workflow example

Let an agent work a Linear issue without leaving Linear

A triage issue filed by support in Linear is assigned to an Aestus agent. The team keeps planning where it always has, and the result comes back as Linear updates.

TriggerENG-311 is assigned to the Aestus coding agent

1
Sofia · Support
Files the issue in Linear as usual
The reproduction, priority, and team labels are set in Linear; nothing is re-entered anywhere.
ENG-311 · urgent · Triage
2
Aestus sync
Mirrors the issue onto the mapped team board
The Linear team maps to one Aestus team, and the workflow state maps to a column on that board.
pair ENG ↔ PLAT · Triage → Ready
3
Aestus coding agent
Works the issue and returns the fix
The run reports its phases, opens the pull request, and records tokens, latency, and cost.
EXAMPLE-LN-01 · PR #318
4
Aestus sync
Returns the transition and one comment to Linear
Sofia reads the outcome in Linear; the write is stamped as the app's own and never echoes back.
ENG-311 → In Review · 1 comment

Example run

Runtime

Outcome

EXAMPLE-LN-01

Aestus coding agent

aestus

Completed

$0.03

58.0s

Questions teams ask

Can we use this today?

Do our issues have to move into Aestus?

No. Planning, cycles, and triage stay in Linear. Aestus holds the operations record for the work an agent performs on those issues.

Can a change bounce between the two systems?

No. Aestus writes as its own Linear app user, keeps a ledger of what it wrote, and skips any inbound event that would be a no-op.

Keep planning in Linear and let agents work the issues