Your Tracker Is the Agent's Interface

Imprint moved from Jira to Linear in under four weeks, against internal doubt, according to Will Larson, its CTO . His explanation was practical: centralized issue management let agents find tasks and pull them down to work on them. That gives a tracker decision a different engineering consequence. The place people record work becomes the place agents obtain it.

Once an agent pulls its own work, I consider the tracker part of the infrastructure. A task whose current state requires someone to reconcile a Slack thread with an issue is an incomplete input. If an agent needs an engineer to untangle permissions before it can claim that task, dispatch still depends on the engineer. Both problems are defects in the interface we expect the agent to use.

Larson’s written account puts the decision in June and identifies the constraint as the lack of a common task management system with higher visibility and less permission complexity than Jira. In a separate essay , he cites a more capable MCP and better Slack integration as reasons for moving. Those are specific integration constraints. They give a team something to test before choosing a migration.

The sequence matters. In the same written account , the tracker move precedes the July rollout of the orchestrated harness Imprint calls Agent Fleet. Visibility into the tickets exposed work that local development was struggling to manage. I covered the Software Factory pattern in October. The part worth copying here is the dependency: make the work accessible before investing in machinery to keep pulling it.

Keep the evidence in proportion. Larson describes a migration at Imprint and credits executive sponsorship; his account supplies no cost, defect or throughput numbers for the move. That report supports investigating the constraint he describes. It cannot establish that another company will benefit from the same migration. My recommendation is to name an executive sponsor if migration is necessary, then make the decision depend on an agent completing the actual dispatch workflow.

Stripe provides evidence for a different approach. Its minions post describes a typical run starting with a Slack message and ending with a pull request ready for human review. Its internal ticketing UI also integrates with minions, including a button on flaky-test tickets that starts a run. Those runs begin with a human action. They establish a route from existing systems into agent work, without establishing that Stripe’s agents pull autonomously from a tracker.

The relevant component is Toolshed, Stripe’s central internal MCP server . Stripe configures different agents to request only the subset of tools relevant to their task . Borrow that curation when a migration cannot solve the problem. A gateway should give an agent a coherent view of work across systems. Exposing every available tool would leave the agent to resolve the fragmentation itself.

That gateway needs an owner, as I argued about the agent-to-tool boundary . Make that owner responsible for deciding which system holds the authoritative task state and where updates must go. If the gateway reads an issue while completion lives in a separate document, its read path is only part of the interface. Require an explicit destination for the result before letting agents claim work through it.

Jira deserves a fair test here. Atlassian’s 2026-07-15 announcement says Agents in Jira lets teams assign work items directly to Claude Code, Cursor, or GitHub Copilot, with Codex coming soon. That announcement follows Imprint’s June decision. Evaluate the available integration against your team’s workflow before accepting that migration is necessary. The tracker brand matters less to me than whether a scoped credential can support the work.

Run that test with an agent credential. Have the agent read an issue and claim it, then update its status and attach a pull request link. Repeat it against a task outside the agent’s intended access and require denial. Atlassian says its Remote MCP Server respects existing permission controls . Verify the resulting access explicitly; the engineer’s inherited credentials are a poor substitute for deciding what the agent needs.

If the current tracker cannot pass that test with scoped access, compare the work of replacing it with the work of maintaining a gateway. Include the teams whose task state would have to move. A migration requires their participation, which is why I would want an executive sponsor with authority over that scope. A gateway needs someone accountable for keeping its view consistent as the systems behind it change. Either decision should come with an owner who can fix a failed dispatch.

Keep responsibility visible too. Linear’s delegation model keeps a human teammate as assignee while an agent contributes on their behalf. Use that distinction to keep responsibility clear through dispatch. Once dispatch works, check the review queue before increasing the work agents claim. Next week, choose a live issue and make an agent take it through the dispatch test using a scoped credential. Fix the first step that requires someone to explain where the work went.