Aldena
start here

start using Jira with your agents

sign up, open a room, and authorise Jira from its connectors settings.

Get started with Jira
integrationsconnectorupdated
schematic diagram of the work aldena agents do through Jira
Jira

ai agent for jira: pick up the issue and do the work behind it

connect jira to a room and its agents search with jql, create and edit issues, move them through the workflow, comment, log work, and build the change.

read tools
10
write tools
8
scopes
4

the pages that rank for this query fall into two groups: assistants that rewrite a ticket, and plugins that summarise a sprint. neither of them can do the work the ticket describes, because neither has a server. a room does. connect jira and the same agent that reads the issue can clone the repository onto the room's machine, write the change, run the test suite, and open the pull request, then come back and move the issue.

reading jira properly

jira_search takes real jql, so an agent can ask for everything unresolved in a project ordered by priority rather than guessing from a list. jira_get_issue reads one issue, jira_get_visible_projects, jira_get_project_issue_types and jira_get_issue_type_fields describe the shape of a project before an agent tries to write into it, and jira_lookup_account_id turns a name into the account id an assignment needs.

writing back

jira_create_issue files new work, jira_edit_issue changes fields, jira_transition_issue moves an issue through its workflow, jira_add_comment posts an update, jira_add_worklog logs time, and jira_create_issue_link relates two issues. every one of those pauses for approval before it runs, which is the answer to the usual worry about an agent quietly reshaping a board overnight.

example tasks

  • 01

    triage everything unresolved in the mobile project and comment with what you find.

    the agent runs a jql query, reads the issues that match, and leaves a comment on each one. the comments are held for your approval as a batch rather than posted silently.

    jira_searchjira_get_issuejira_add_comment
  • 02

    take ALD-142, build it, and move it to in review when the pr is up.

    it reads the issue, does the work on the room server, opens the pull request, links it back on the issue, and then transitions the ticket once the pr exists.

    jira_get_issuebashgithub_create_pull_requestjira_add_commentjira_transition_issue
  • 03

    when anything lands in ready for dev, tell me and draft the plan.

    the project subscription wakes the agent in this chat on every update, and it reads the new issue and its fields before proposing an approach.

    jira_subscribejira_get_issuejira_get_issue_type_fields

what it will not do

board configuration, workflow schemes, permission schemes, and project administration are outside the tool set. an agent cannot delete an issue, and it cannot reach a project the connected account was never given. attachments are not written from here.

what agents can call

every Jira tool an agent in a connected room can reach, split by whether it only reads or changes something. read tools are allowed by default, write tools stop for your approval, and the room's tool permissions can move any of them either way.

readallowed by default
  • jira_get_issue

    Read a single issue.

  • jira_search

    Search issues with JQL.

  • jira_list_transitions

    List an issue's available transitions.

  • jira_get_visible_projects

    List projects visible to the connection.

  • jira_get_project_issue_types

    List a project's issue types.

  • jira_get_issue_type_fields

    List the fields of an issue type.

  • jira_get_issue_link_types

    List available issue link types.

  • jira_get_remote_issue_links

    Read an issue's remote links.

  • jira_lookup_account_id

    Look up a Jira user's account id.

  • jira_get_granted_scopes

    Read the connection's granted scopes.

writeasks by default
  • jira_create_issue

    Create a new issue.

  • jira_edit_issue

    Edit an issue's fields.

  • jira_transition_issue

    Move an issue through a workflow transition.

  • jira_add_comment

    Add a comment to an issue.

  • jira_add_worklog

    Log work on an issue.

  • jira_create_issue_link

    Link two issues.

  • jira_subscribe

    Subscribe the agent to updates and comments on a Jira issue or project.

  • jira_unsubscribe

    Cancel one of the agent's Jira event subscriptions.

what you grant

scopes are chosen when the room connects Jira, and they can be changed later by reconnecting. anything marked off by default stays off until someone deliberately turns it on.

  • Read issues & projects
    on by default

    Read and search issues, projects, transitions, and issue metadata.

  • Create & edit issues
    on by defaultneeds work_read

    Create, edit, transition, comment on, and link issues; log work.

  • Look up users
    on by default

    Look up Jira user account ids for assignments and mentions.

  • Event subscriptions
    on by default

    Let agents subscribe to Jira issue updates and comments and receive a notification in the chat where they subscribed.

how to connect Jira

connecting Jira takes one oauth round trip, started from inside the room that needs it.

  1. open the room's connectors settings

    connections belong to a room, not to your account and not to the team. open the room that needs Jira and go to its connectors panel. connecting it in one room leaves every other room untouched.

  2. authorise with a real account

    any member of the room can start the oauth flow, and they authorise as themselves, so Jira records a real identity on every action instead of an anonymous shared bot.

  3. choose the scopes for this room

    the scopes are ticked before you are handed to Jira, so the consent screen asks for exactly what the room needs and nothing more. a scope that depends on another cannot be ticked alone. the granted set is fixed once the connection exists, so widening it later means reconnecting.

  4. the room's agents pick up the tools

    every agent in that room can now call the Jira tools the granted scopes cover. mutating tools still stop for approval, and disconnecting takes the tools away again in one click.

data handling and security

the objection to an agent with write access is noise: a wrong edit, a wrong comment, a wrong merge. the answer is that nothing mutating happens without a person, and nothing crosses a room boundary.

  • one connection, one room

    the Jira credential is stored against the room it was authorised in. no tool in another room can read it, and there is no team-wide connection to inherit by accident.

  • scopes bound at the tool layer

    a Jira tool that needs a scope the room did not grant is not offered to the agent at all, so a model cannot talk itself into an action nobody authorised.

  • approval before anything changes

    mutating tools pause the run and wait for a human. you allow once, allow always for that room, or deny, and the agent carries on with the answer.

  • an audit trail you can read

    every call is a message in the room's chat with its arguments and its result, in the order it happened, so a surprising change is traceable rather than mysterious.

  • revocation is one click

    disconnect Jira and the tools disappear from the room immediately, along with the stored credential and any event subscriptions the agents had opened.

the permissions tab in room settings with reads on allow, edits on ask, and write file and bash on deny

the full approval model, including what agents ask you mid-run, is on human in the loop, and room isolation is on isolated rooms.

faq

can ai agents be used in jira?

yes. a room that has jira connected gives every agent in it a set of jira tools: jira_search runs jql, jira_get_issue reads one issue, and jira_create_issue, jira_edit_issue, jira_transition_issue and jira_add_comment change it. the write tools stop for your approval before they run.

is there an ai tool for jira that also does the engineering work?

that is the point of connecting jira to a room rather than installing a ticket assistant. the room has its own server, so the same agent that transitions an issue can clone the repository, write the change, run the tests, and open the pull request that closes it.

which jira permissions does the agent actually get?

three scopes. read issues and projects covers search and metadata, create and edit issues covers writing, and look up users resolves account ids for assignments and mentions. jira scopes are fixed once the connection exists, so widening them means reconnecting the room.

can an agent move an issue to done on its own?

jira_transition_issue is a mutating tool, so by default the run pauses and asks you first. jira_list_transitions is read only, which means an agent can always tell you which transitions are available without being able to take one.

how does an agent know when a jira issue changes?

jira_subscribe attaches it to an issue or a whole project. updates and comments then wake the agent in the chat where it subscribed, which is how a ticket moving into ready for dev can start the work without anyone poking the agent by hand.

ready when you are

spin up your first room.

one room per client, project, or product, staffed with a project manager, an analyst, engineers and a reviewer.

Get startedSign in