How do I add an AI agent on top of Jira Service Management without replacing it?
The short answer
You do not have to replace Jira Service Management. Connect Siit through a two-way sync, open the intake in Slack or Microsoft Teams, and Jira keeps the record.
Start with the virtual service agent Atlassian ships on Premium and Enterprise plans. Siit earns its place when your knowledge is split across two tools, access runs through Okta and devices through Jamf.
Does Jira Service Management already have an AI agent?
Yes, and it is the first thing to turn on.
Jira Service Management ships a virtual service agent, available on Atlassian Cloud Premium and Enterprise plans. Atlassian documents two ways to configure it, and the difference matters when you are deciding whether you need anything else.
Intent flows
You define a request type, train it with phrases, and build a turn-by-turn conversation that gathers information, routes to the right request type, or takes an action. Actions outside Jira are possible through an Atlassian Automation rule, a web request, or a third-party tool.
AI answers
Generative answers drawn from a linked knowledge base, either a Confluence space or the native Jira Service Management knowledge base. Each answer carries its source articles. There is no conversation to build: you link the knowledge base, switch it on, and the quality of the output follows the quality of the articles.
Both run in the customer portal and the help center, and can be extended to a widget, Microsoft Teams, and Slack. Slack requires the Atlassian Assist app and dedicated channels.
If your documentation lives in a well maintained Confluence space and your requests stay inside Atlassian, this covers a lot of ground for a cost you are already paying. Evaluate it before you evaluate anything else.
Where the virtual service agent stops
It is scoped to Atlassian, by design. That produces three boundaries that IT teams meet quickly.
It reads a linked knowledge base
AI answers draw on Confluence or the native knowledge base. Documentation kept in Notion, or in a wiki your HR team runs, is outside that scope. Teams whose knowledge is split across two systems face a consolidation project before the AI performs.
Intents are hand-built and need maintenance
Each intent has to be created, trained and given a conversation flow. Atlassian recommends around 20 training phrases per intent for reliable matching, and flows need tuning as you monitor them. That is a real cost for a small IT team, and it is the reason many virtual agents end up covering three request types and stopping there.
Acting outside Atlassian is possible, not native
An intent flow can reach an external system through an automation rule, a web request, or a third-party integration. It works. It is also a chain of moving parts to build and maintain for each action, which is a different proposition from an agent that connects to your identity provider directly.
None of this makes the virtual service agent a poor product. It makes it an Atlassian product. The question is not which agent is better, it is whether the requests you want automated end inside Atlassian or outside it.
Choosing an AI agent for Jira Service Management
An overlay does not compete with Jira Service Management for the ticket. Siit sits in front of it and extends reach in three directions.
| Criterion | Virtual service agent | Overlay agent |
|---|---|---|
| Plan required | Premium or Enterprise | Separate product, no plan change in Jira |
| Knowledge it reads | Linked Confluence space or native knowledge base | Confluence and Notion, alongside the Jira knowledge base |
| Setup of automated answers | Intents built and trained by hand | Retrieval from connected sources, no flow to build |
| Acting on identity and devices | Through automation rules, web requests or third-party tools | Native to Okta, Microsoft Entra ID, Jamf, Microsoft Intune |
| Request scope | IT requests in Jira | IT and HR requests in one flow |
| Primary channel | Portal and help center, extended to Slack and Teams | Slack and Microsoft Teams first |
| System of record | Jira Service Management | Still Jira Service Management |
The line that decides it is not answer quality. It is whether the agent can finish the job. That is the line Siit is built for.
Deflecting a question about VPN setup is useful. Granting the access, checking the manager approved it, and revoking it 90 days later is a different capability, and it requires reaching systems that sit outside Jira, such as an identity provider's group membership API.
How to add an AI agent on top of Jira Service Management
Four steps. The first one is not technical, and skipping it is what makes these projects go wrong.
- Decide what stays in Jira
Before connecting anything, decide which objects Jira Service Management remains authoritative for. In most deployments that is incidents, problems, change and assets. Siit handles intake, qualification and execution. Writing this down first prevents the two systems from competing for the same record. - Connect the agent to Jira Service Management
Authorise the connection between Siit and your Jira Service Management site. The integration is a two-way sync rather than a copy, with control over the direction of each synced event: resolution, assignee, internal notes and messages. - Point the agent at the knowledge and systems it needs
Connect the sources the agent should read, including Confluence and Notion, and the systems it should act on, including Okta or Microsoft Entra ID for access, and Jamf or Microsoft Intune for devices. Jira Service Management's own AI answers are limited to a linked knowledge base, so this step is where an overlay adds reach. - Open the intake in Slack or Microsoft Teams
Employees raise requests in the channel they already use. The conversation becomes the request, the agent answers or executes, and where the request belongs in Jira it is escalated in one click or by a workflow trigger, then kept in sync in both directions.
No data is moved out of Jira at any point. If step 4 goes well, the portal stops being the place employees start, and starts being the place the work is recorded. That is the intended outcome.
How does the two-way sync with Jira work?
Siit connects natively to Jira Service Management through a two-way sync, with control over what flows in each direction. That last part is what separates a sync from a copy.
In practice: a request raised in Slack or Microsoft Teams creates or updates the corresponding Jira work item. Updates made in Jira flow back into the conversation, and replies in the conversation post back to the work item. There is one record, visible from two places: Siit and Jira Service Management. On escalation you pick the Customer Request Type, and defaults can be set per project so agents do not choose it each time.
The technical detail of what is read and written is published in the Siit API reference.
This does not duplicate your tickets. The connection to Jira Service Management is a two-way sync rather than a copy, with per-event direction control over resolution, assignee, internal notes and messages. There is one work item, visible from two places, and no reconciliation to run at the end of the month.
Do we have to move our Confluence knowledge base?
Your articles stay where they are. Siit's AI agents answer from existing Confluence content directly in Slack and Microsoft Teams, and read from Notion at the same time.
That combination is the point. A team whose IT runbooks are in Confluence and whose HR policies are in Notion does not have to consolidate before the agent becomes useful. With AI answers alone, the Notion half stays invisible.
Two questions are worth putting to each vendor on your shortlist, including us: where is the access decision made, and can you audit it?
Siit does not import the access rules of your Confluence or Notion pages. Access is declared once, inside Siit: each article category carries an audience, and the agent answers a requester only from the categories that requester is entitled to see. You can also exclude a category from the sync entirely.
The trade-off is explicit. Connecting a knowledge source is a configuration step, not a passive mirror of your source permissions, and a restriction added later in Confluence is not picked up on its own. What you get in return is a single place to review and audit, uniform across all sources, that does not depend on an access-control sync staying accurate.
What stays in Jira Service Management?
Siit takes the employee request layer: intake, qualification, resolution and execution across IT and HR. It does not absorb the ITSM disciplines your team runs in Jira.
Incidents, problems, change management, the configuration management database and IT asset lifecycle tracking stay where they are, outside Siit. So does everything your engineering teams do in Jira Software and Confluence, which is usually the deciding factor for teams who priced a migration and stopped at the cost of retraining several departments.
Saying this plainly matters, because an overlay that claims to replace everything is a migration in disguise. If a migration is what you want, that is a legitimate choice, and it should be made deliberately rather than discovered halfway through a rollout.
Can an AI agent grant access on top of Jira?
Autonomy without a boundary is not a feature. Before any agent touches identity, four things need an answer. Ask them of each tool you evaluate, and read them alongside the NIST AI Risk Management Framework and the OWASP Top 10 for LLM Applications, which give you a vocabulary independent of vendor marketing.
- What does it do without a human? Reading and answering is one class of action. Granting access is another.
- Who approves the rest? Approval routing should be yours to define, not inherited from the tool.
- Are decisions recorded? Not only the outcome, but what was read, what was concluded, and when.
- Can autonomy be reduced or stopped? Immediately, without raising a support ticket.
Let AI run the queue. You own the governance.
With Siit, grant and revoke actions run through your identity provider after the approval routing you define, not instead of it. Siit logs the decisions its agents make. Across its customer base Siit reports more than 50% of tickets resolved autonomously across IT, HR, Finance and Legal.
Security documentation, including the SOC 2 Type II attested report, the penetration test report, the EU and US Data Processing Addenda and the subprocessor list, is available on request through the Siit Trust Center.
Overlay, migration, or neither: which fits your team?
Your knowledge is in Confluence and your requests stay inside Atlassian
Turn on the virtual service agent and stop there. You are already paying for it, and a second tool will not earn its cost.
Your documentation is split between Confluence and another system
An overlay like Siit is the shorter path. Consolidating knowledge into Confluence to make AI answers work is a project in itself, and it competes with the outcome you actually wanted.
Your employees ask in Slack and ignore the portal
Meet them there. Monzo reports 28% of support tickets deflected that would otherwise have reached IT, and Airalo 50% of tickets automated after moving intake into chat.
Portal adoption does not improve by redesigning the portal, and the virtual service agent in Slack still requires Atlassian Assist and dedicated channels to set up.
You need access granted, revoked and provisioned
Check what each option reaches natively, and what it reaches through a chain of automation rules that someone has to maintain.
Jira Service Management is already on its way out
Then Siit is not the destination. It is a way to run both systems while you decide. See the migration path for what a full move involves.
Related guides
FAQ
Connect Siit to your Jira Service Management site through a two-way sync, and open the intake in Slack or Microsoft Teams. Jira Service Management stays the system of record for incidents, problems, change and assets. The agent handles intake, qualification and execution, and a request that belongs in Jira is escalated there in one click or by a workflow trigger, then kept in sync in both directions. No data is moved out of Jira.
Yes. Jira Service Management ships a virtual service agent, available on Atlassian Cloud Premium and Enterprise plans. It can be configured two ways: intent flows, where you define a request type with training phrases and a turn-by-turn conversation, and AI answers, which generate responses from a linked knowledge base in Confluence or the native Jira Service Management knowledge base. If your requests and your documentation both live inside Atlassian, turn it on before you evaluate Siit or anything else.
No. Your knowledge base stays in Confluence. Siit's AI agents answer from existing Confluence content directly in Slack and Microsoft Teams, and can read from Notion at the same time, so a team whose documentation is split across two systems does not have to consolidate first.
Grant and revoke actions run through your identity provider, Okta or Microsoft Entra ID, after the approval routing you define rather than instead of it. Siit logs the decisions its agents make. Before adopting any agent that touches identity, establish four things: what it does without a human, who approves the rest, whether decisions are recorded, and whether its autonomy can be reduced immediately.
Incidents, problems, change management, the configuration management database and IT asset lifecycle tracking stay in Jira Service Management. Siit takes the employee request layer: intake, qualification, resolution and execution across IT and HR. It does not absorb the ITSM disciplines your team already runs in Jira.