Confluence agentic AI: Rovo workflows and eesel CLI

What is Confluence agentic AI?

An agentic workflow combines a goal, information and permitted actions. The important distinction is between producing text and changing something outside the conversation. A page summary may be useful without taking an action. An automation that creates a review task has a different permission and testing burden.

Atlassian describes Rovo agents as configurable teammates available in Chat, automation, the editor and Studio. Depending on their setup, they can use Atlassian and connected third-party sources, and perform actions such as creating or editing work items and pages.

That makes the old “Confluence AI only works inside its own knowledge silo” comparison inaccurate. I would compare the actual workflow instead: which information it reads, what it can change, whose permissions it uses and how its output is checked.

What Rovo can do in Confluence

Create and improve content

Confluence's writing documentation shows several entry points, including Create with Rovo, Ask Rovo, and the /rovo or /ai editor commands. You can provide context, review a draft and refine it. Rovo can also transform selected text and summarize content.

The creation menu, from Atlassian's Rovo writing guide.

For a runbook, I would ask for structure before new prose:

Reorganize this incident runbook into symptoms, checks, escalation criteria and ownership. Preserve all thresholds and exceptions. List any missing information separately instead of filling it in.

The review should focus on meaning. If an exception disappears during rewriting, a cleaner page can become a worse source for the next person or agent who reads it.

Summarize without losing the decision

My test for a summary is whether someone can act on it without overlooking a constraint. For meeting notes, I would check owners and deadlines. For a support policy, I would check eligibility, exclusions and the point where a person must decide.

A concise answer that cites the right page can still misread it. Keep the original open during review and compare the decisive sentence, not just the overall topic.

Build and test automation

Rovo can help generate Confluence automation flows from a description. Atlassian's automation guide distinguishes app-admin and space-admin scope. Its setup sequence includes previewing the flow, checking its configuration, enabling it and testing the trigger while reviewing the audit log.

I would begin in a test space with a reversible action, such as creating a review task for a newly published test specification. Before enabling it, check the trigger, target space, destination and notifications. Keep destructive housekeeping, such as archiving many pages, out of an initial experiment.

Generating a flow is not the same as validating it. A preview may look reasonable while the actual trigger catches too many pages or the action goes to the wrong destination.

Permissions matter more than a broad capability list

For any knowledge-base workflow, I would write down three separate boundaries:

1. Source access: what can the integration or agent read?
2. Audience: who is allowed to receive the resulting information?
3. Actions: what can the agent change or send?

Those questions are related, but one answer does not settle all three. Permission for an app to read an internal runbook does not establish that every detail belongs in a customer reply.

For example, an incident guide may contain a public explanation, an internal escalation contact and sensitive recovery steps. A customer-facing answer might need only the first. Test that distinction directly instead of assuming that a correct citation makes disclosure appropriate.

Test Confluence answers through eesel CLI

The eesel Confluence integration gives an eesel teammate selected wiki pages as knowledge. It is read-only: it does not add Confluence actions or triggers. The self-serve setup uses a Marketplace app on Confluence Cloud; Data Center requires a managed discussion rather than the same install path.

The eesel CLI operates the same agent and workspace as the dashboard. People can run it directly, scripts can call it, and coding agents can use its structured JSON output. Here, the practical benefit is a repeatable way to inspect the support teammate and ask a controlled set of questions.

It does not turn eesel into a Confluence page editor. The wiki remains the knowledge source; the teammate uses that knowledge for its assigned support job.

1. Select a separate test teammate

With Node.js 18.17 or newer, sign in and confirm the workspace:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents

Create or choose a separate test helpdesk agent in the dashboard. Replace TEST_AGENT_ID throughout this example with its actual ID. Inspect its existing setup:

npx @eesel/cli --agent TEST_AGENT_ID instructions
npx @eesel/cli --agent TEST_AGENT_ID integrations
npx @eesel/cli --agent TEST_AGENT_ID automations

For this exercise, I would keep customer-facing channels and unrelated automations disabled. Do not rely on the words “test only” to prevent a connected tool from acting.

2. Connect a small, approved page set

In that test agent's dashboard, ask to connect Confluence, then complete the Marketplace installation with an authorized Confluence administrator. Open the eesel app inside Confluence and choose the pages to index. Selecting a parent includes its descendants, so inspect the whole subtree before selecting it.

The app needs View permission for selected pages. Attachments are not indexed; only page text is read. If the runbook's decisive instructions live in a PDF, upload that approved file separately or put the necessary content into the page. These limits are documented in the integration reference.

Then inspect the agent again:

npx @eesel/cli --agent TEST_AGENT_ID integrations
npx @eesel/cli --agent TEST_AGENT_ID status

Confirm that the intended source appears and its content is available before testing answers. A connected status alone is not evidence that a particular page was retrieved or interpreted correctly.

3. Ask one question with a known answer

For a pilot, choose an approved runbook and write the expected answer before running the prompt. The example below assumes a test page titled “Login incident runbook”; replace that name and scenario with your own approved material.

npx @eesel/cli --agent TEST_AGENT_ID new --name "confluence-runbook-check"
npx @eesel/cli --agent TEST_AGENT_ID chat "For an internal support colleague: use the Login incident runbook to explain what to check when one user cannot sign in but others can. Cite the page and distinguish documented steps from missing information. Draft guidance only; do not send messages, change accounts, or edit anything."
npx @eesel/cli --agent TEST_AGENT_ID activity

new starts a fresh conversation, not a new agent. Chat can invoke permitted tools and incur usage. Review the instructions and permissions before the request, then inspect what actually happened afterward.

I would check the answer against this small scorecard:

Run a second case with missing information and a third with conflicting pages. Start each in a fresh conversation so a previous answer does not supply the missing context. For an audience test, change the requested audience deliberately and inspect the output before sharing it anywhere.

4. Fix the source or setup, then repeat

If the answer is wrong because the page is wrong, have the document owner correct Confluence. If the source is correct but the response omits an exception, inspect the teammate's instructions and retrieval evidence. Do not patch every failure with a longer question; identify which part needs fixing.

The integration normally re-indexes edits and reconciles roughly hourly. Its default connection limit is 3,000 pages, and exceeding that can truncate indexing rather than fail the whole connection. Check these details when expected content is absent. See Confluence troubleshooting.

The CLI's --dry-run flag previews a write's server call without sending it. It is not an answer-quality simulation. For the runbook exercise, evidence comes from actual answers, source checks and activity review.

The eesel helpdesk dashboard. The CLI works with the same teammate and workspace, so setup and review do not have to happen in separate copies.

Understand plans and usage before expanding

Rovo is not restricted to Premium and Enterprise. Atlassian's current licensing FAQ includes Standard Cloud plans. Check your required feature and administrative setup, rather than assuming every plan has identical limits.

For standalone Confluence, the published monthly Rovo allowance is 25 credits per Standard user, 70 per Premium user and 150 per Enterprise user, pooled at organization level. Atlassian says extra-usage billing takes effect on December 3, 2026; that is a future change as of this guide's September check. Its usage documentation explains allowances, variable consumption and spending controls.

Do not translate a Rovo credit allowance directly into a fixed number of successful support answers. The work performed and pricing unit differ. Likewise, connecting a source is not the same thing as paying for every task an agent performs with it.

For an eesel pilot, check current pricing and set a test budget before scaling the question set. Keep the cost review alongside accuracy and permissions, not after deployment.

Start with one documented job

If your goal is to improve Confluence pages or manage native workflows, evaluate Rovo where that work already happens. If your goal is a support teammate answering from selected wiki pages, test that job directly.

With eesel CLI, start with one approved runbook, one test agent and a few questions whose answers you can verify. Once that works, test the intended support channel separately before exposing it to users. A good terminal answer is useful evidence, not proof that every downstream channel is configured correctly.

Explore eesel for Confluence to connect your wiki and run this kind of focused evaluation.