Atlassian's remote agents for Jira: what assigning a work item to your own agent actually changes

The one line version is good news. You can now assign a Jira work item to an agent that runs on your own infrastructure, and Jira treats it as an assignee: an avatar in the assignee field, a panel showing what it is doing, a cancel button, and a conversation the person who assigned it can follow. Until this year, an agent in Jira meant a bot account with a licence and a webhook listener hoping to notice that a field had changed.

When I put this post on the plan it was an early access feature. Since then it has moved. On 28 September Atlassian's Forge changelog marked the rovo:agentConnector module generally available (CHANGE-3484, with A2A 1.0 as the only accepted protocol. The guide for the A2A 0.3 version it launched with is now marked deprecated, and a 0.3 connector is refused at deploy. Two protocol versions in a few months is worth remembering when you size the maintenance on this.

It is also the door Atlassian's own partners came in through. In July, Atlassian announced that Jira work items could be assigned to Claude Code, Cursor and GitHub Copilot, with Codex to follow, alongside its own Jira Coding Agent. The connector is that mechanism with the door left open for you. This is what it is, read against the documentation rather than the announcement, what genuinely changes, and the list of things it does not touch.

ways a work item reaches your agentassignment, a mention, a workflow transition, a manual trigger, or an automation rule

5

ceiling on a task started from a work item30 minutes for a chat, with 55 seconds per synchronous call

60 min

lifetime of the tokens Jira hands you to call back inone acting as the user who asked, one as your app

4 h

the only A2A version accepted at deploythe 0.3 guide is deprecated less than a year after it shipped

1.0

What you actually build

Two things. A Forge app, which for this purpose is mostly a manifest: it registers the agent, points at your service, declares the scopes, and gives an admin a configuration page. And an A2A server on your own infrastructure that speaks JSON-RPC 2.0. Jira sends SendMessage to start or continue a task, or SendStreamingMessage if you declared streaming, polls GetTask while the task is active, calls CancelTask when somebody presses cancel, and uses SubscribeToTask to reconnect a dropped stream.

modules:
  rovo:agentConnector:
    - key: triage-agent
      name: Triage Agent            # 30 characters at most
      description: Reproduces bugs and proposes a fix
      icon: resource:agent-resources;icons/agent.svg
      productContexts:
        - jira                      # the only product supported
      protocols:
        agent2Agent:
          version: '1.0'            # 0.3 is refused at deploy
          jsonRpcTransport:
            endpoint: a2a-endpoint
            streaming: true
  endpoint:
    - key: a2a-endpoint
      remote: agent-backend
      route:
        path: /a2a/json-rpc
remotes:
  - key: agent-backend
    baseUrl: https://agent.example.com
    operations: [fetch, compute, other]
permissions:
  scopes:
    - read:jira-work                # required for the connector to work at all

What arrives on that first call is thinner than you would guess. The invocation carries the work item's id, key, summary and description, plus the comment that triggered it for a mention. Linked issues, attachments and everything else you fetch yourself. And the description and comments are converted from Atlassian Document Format to plain text before you see them, so the table a reporter carefully built in the description reaches your agent as a run of words. If formatting matters to the task, fetch the issue through the REST API and read the ADF yourself.

One side effect catches people at deploy. Adding the connector changes your Forge app's system user: the app itself can no longer be mentioned in comments or fields, and the connector user is mentionable instead, across every version of the app in that environment. Forge CLI 13.3 and later warns you and asks before it does it. If anything in your existing app relied on being mentioned, read that prompt properly.

What genuinely changes

The last row is the one I would point a Jira admin at. An automation rule that routes every bug with a given component to an agent, or a workflow transition that hands the ticket over at Ready for triage, means the agent becomes part of the process the team already runs instead of something people have to remember to call. That is the same argument as putting the agent where the work is recorded, made by the platform itself.

The private conversation is the other quietly good decision. An agent working through a task produces a lot of text that nobody else on the ticket needs, and the old pattern put all of it in comments and every watcher's inbox. Now the working stays in the panel and the person who asked decides what is worth a comment.

The task lifecycle is the real contract

The announcement is about assigning work. The documentation is mostly about tasks, and the rules there are what your agent will be judged on. A task starts in TASK_STATE_SUBMITTED and moves through WORKING to one of four terminal states: COMPLETED, FAILED, CANCELED or REJECTED. It can stop for INPUT_REQUIRED, when it needs the person, or AUTH_REQUIRED, when it needs an admin.

• One active task per context. A context is one user, one agent and one work item or chat session. Every new assignment or mention starts a new context.
• Terminal means terminal. A completed, failed, cancelled or rejected task is never restarted. A retry is a new task in the same context, with a new task id, and reusing the old one is a bug Jira will show to the user.
• INPUT_REQUIRED stops the polling. Jira waits for the person to answer in the panel, so that is the state for a genuine question rather than a pause while you work.
• UNKNOWN is a slow failure. It counts as active, gives the user nothing, and Jira eventually treats it as failed. Report what you are doing instead.
• People will reach the agent before an admin has configured it. Answer with AUTH_REQUIRED and say what is missing, rather than failing with a stack trace in a panel.
• A completed status carries a message describing the outcome. It is what the user reads, and it is what they will share as a comment.

The handler on your side is small, and the shape of it is set by two numbers: 55 seconds for a synchronous call and 60 minutes for the task. Nothing slow happens inside the request.

// One JSON-RPC 2.0 route. Check the exact envelopes against the A2A 1.0
// spec the guide links: the shape below is the logic, not the wire format.
export async function POST(req: Request) {
  // Every call from Jira carries a Forge Invocation Token. Verify it against
  // Atlassian's JWKS before reading anything else in the request.
  const invocation = await verifyForgeInvocationToken(req.headers.get("authorization"));
  const rpc = await req.json();

  switch (rpc.method) {
    case "SendMessage": {
      const { message } = rpc.params;
      // No contextId: a new assignment or mention, so a new context and task.
      // A contextId: a follow up, so a new task only if the last one is terminal.
      const task = await tasks.startOrContinue({
        contextId: message.contextId ?? crypto.randomUUID(),
        site: invocation.site,
        input: message.parts,
        // Act as the person who asked. The system token may see more than
        // they can, and using it for their data is the escalation Atlassian
        // names as grounds for delisting.
        userToken: req.headers.get("x-forge-oauth-user"),
      });
      await queue.push(task.id); // the work happens here, not in the request
      return Response.json({ jsonrpc: "2.0", id: rpc.id, result: toA2aTask(task) });
    }
    case "GetTask":
      return Response.json({ jsonrpc: "2.0", id: rpc.id, result: toA2aTask(await tasks.get(rpc.params.id)) });
    case "CancelTask":
      return Response.json({ jsonrpc: "2.0", id: rpc.id, result: toA2aTask(await tasks.cancel(rpc.params.id)) });
    default:
      return Response.json({ jsonrpc: "2.0", id: rpc.id, error: { code: -32601, message: "Method not found" } });
  }
}

What it does not change

This is the half the announcement does not cover, and it is the half that decides whether your agent is safe to install.

• Authorisation is still yours. Jira hands you two tokens: x-forge-oauth-user, acting as the person who invoked the agent, and x-forge-oauth-system, acting as your app. The guide is blunt that the system user may see more than the user and that your agent must only reason about data the invoking user can access, calling it a strict requirement whose failure can mean a security incident and delisting from the Marketplace. Nothing in the platform enforces that for you. It is the shared token problem in a new place.
• The work item is untrusted input. Anybody who can create an issue writes the description your agent reads, and an issue description is not authority to act. Being assigned a ticket is a request, the same boundary as page content in a website agent.
• Rate limits still apply. Forge apps are inside the points based quota Jira has enforced since 2 March 2026, so an agent that re-reads the same issue on every step is spending a pool that may be shared across all your tenants.
• Scopes are a release. A new scope needs a redeploy, and each customer has to upgrade the app and consent before the new API calls work. Ask for what you need at launch, and no more.
• It is Jira Cloud, and SaaS shaped. The guide is written for multi tenant services and says it does not suit services sitting behind a customer's firewall. Data Center customers are outside all of this.
• Your compute, your bill. Jira holds the task for up to an hour. Your model tokens and your workers pay for that hour, and nothing on Atlassian's side caps what a single assignment can cost you.

Who should build on it

Marketing, then reality

The same exercise as checking the Jev install prompt line by line: read the claim, then read the source. The marketing says you can assign Jira work to any agent. The documentation says you can assign Jira work to an agent somebody has wrapped in a Forge app and an A2A 1.0 server, which verifies a token on every request, refuses to see anything the person asking cannot, reports its state honestly, and finishes inside an hour. That is a narrower sentence and a genuinely good product. It is the first time Jira has had a real place for an agent that lives outside Atlassian, and it is worth building on if you build all of the second sentence and not only the first.

Jira now gives your agent an assignee field, a panel and a cancel button. It still does not give it permission to see anything the person who assigned it cannot.

If you want an agent that Jira users can assign work to, or you are deciding between the connector and a plain REST integration, tell me what the agent has to do and on how many sites. I will come back with the architecture, the permission model and a fixed price. Start that conversation here.