Jira: assign an issue to an agent

To assign a Jira issue to an AI agent, install the Isolation Forge app from the Atlassian Marketplace and assign the work item to Isolation, or mention it in a comment. Agents in Jira is what makes an app assignable, and Isolation is one such agent: the assignment launches a session on the workspace your project is routed to, the agent works in the sandbox, and it reports in the issue. This is the same flow as Linear, in Jira's terms.

What the Forge app is

Jira gives an account only to a Forge app, so Isolation ships one. It declares the rovo:agentConnector module, which is what lets a person assign or mention it, and points that connector at an A2A JSON-RPC endpoint on Isolation Cloud: SendMessage delivers a turn, GetTask answers with the turn's state. Every call carries a Forge invocation token, verified against Atlassian's published keys before the payload is read. Posting back, a comment, a transition, a remote link, goes through the app's own system token, so no Jira credential is ever inside a sandbox. The app also declares the development-info provider, so the pull request the agent opens shows in the issue's development panel.

Your site needs Rovo enabled, a Standard plan or above, and Software or Business projects.

Install, then link

Install goes in two halves, because a Marketplace app cannot redirect back to Isolation the way Slack's does. An owner or admin adds the app to the Jira site, then asks Isolation for the organization's code, on the Jira card of the Apps page or with /app-install jira in any connected app, and posts it in a comment mentioning the app:

@Isolation /link A7K3-Q9ZD

The code names an organization, never a person. It expires in an hour, is spent on use, and can only claim an install nobody owns. A member then says who they are with a member code from the same card ("This is me"), posted the same way; it is single-use and links only within that organization's install. /whoami confirms who Isolation thinks you are. The two acts are described on organizations install, members connect.

Routes

A route on the Jira card maps a project to a workspace, an environment, an agent and a default member, plus what triggers a launch: an assignment, a mention, or a label. Assigning the issue is then the same as typing /launch in it. It runs as the person who assigned it, with their role and balance, and the route supplies what they did not type. An unlinked person is told to link first and nothing launches. Launches are rate-limited per route.

What the agent does in the issue

The A2A task state is the acknowledgement: Jira shows the task as running the moment the turn is accepted. The session is named after the issue key. Jira has no thread inside an issue, so the issue itself is the conversation: comments are messages, and the agent's memory of that issue survives across sessions.

The agent pulls what it needs rather than being handed everything: chat_context for the issue's summary, state and URL, chat_history for the comments. It replies as comments under its own name, transitions the issue when it starts and again when the pull request is up, and attaches the pull request, the web preview and the Isolation session as remote links, all through its item_update tool. When the turn ends, the task completes.

Commands in comments

A comment that mentions the app and opens with a slash is answered by Isolation itself, without a sandbox and without a token spent:

Everything else in a mention is a message to the interlocutor, the agent this issue is talking to. The full list is on the commands reference. Every command and every launch is logged with jira as its channel, which the activity log shows.

After the session

Finishing the session ends the binding; the issue keeps its comments, transitions and links. Mention or reassign the issue later and, while the route's trigger still holds, a new session launches and the conversation for that issue continues where it left off.