You can build a Confluence AI agent two ways. A native Rovo agent comes with Confluence Standard, Premium and Enterprise Cloud, runs on Rovo credits (25 per user a month on Standard, 70 on Premium), and is created from Chat or Rovo Studio. An eesel AI teammate reads Confluence live and answers in Slack, Microsoft Teams, your helpdesk or the dashboard, linking the page it used. See the AI agent for Confluence.
Either way, decide who it serves, which pages it may use and what it is allowed to do before you connect it. For an eesel support teammate, the CLI is a practical way to inspect setup and test answers before rollout. You can sign in, select the agent, inspect its instructions and sources, ask a policy question and review its activity. It is the same teammate you see in the dashboard, not a separate terminal-only agent.
Before that first policy question, the teammate needs approved sources. Through the eesel CLI, a coding agent can connect the Confluence spaces you've cleared or upload approved documents, check that the approved sources are available, and run test questions where you already know the right answer. Leave restricted spaces out until access is agreed.
What should your Confluence AI agent do?
This guide uses official documentation checked in October 2026. The examples are suggested tests, not results from a live customer deployment.
A Confluence AI agent uses wiki content to help with a specific task. That might be explaining an expense policy to an employee, drafting a support reply from a setup guide, or helping a document owner improve a page.
These are different jobs. I would not begin by connecting an entire company wiki and asking an agent to “help everyone.” Instead, write down a small assignment:
Help employees understand the published expense policy. Cite the relevant policy page, ask for missing details, and refer exceptions to the named policy owner. Do not approve expenses or change records.
That assignment gives you something testable. It separates explaining a policy from deciding whether a particular person receives money.
| Decision | Example for an internal policy helper |
|---|---|
| Audience | Employees in one pilot team |
| Knowledge | Approved expense and travel policy pages |
| Output | Explanation with a source link |
| Escalation | Policy owner handles undocumented exceptions |
| Excluded work | Approvals, reimbursements and record changes |
For a customer-facing agent, choose customer-safe documentation instead. An internal page can contain useful technical facts alongside information a customer should not receive.
Option 1: Create a native Rovo agent
Rovo is Atlassian's native route for configurable agents. It supports Atlassian and connected third-party knowledge, so external sources are not exclusive to third-party products. The relevant comparison is whether the agent fits your intended work and governance. See Atlassian's agent overview.
Create and configure the agent
From Confluence Chat, select Rovo, then Create agent. Alternatively, open Studio through the app switcher and create a Rovo agent from its Agents area. You can describe the agent conversationally or choose manual setup.
Review its identity, instructions, knowledge, tools and reasoning settings before completing creation. The precise finishing control differs between the conversational and manual paths; follow Atlassian's creation guide for the route you choose.
For the expense-policy example, I would provide the small assignment above, select the relevant policy sources and leave unrelated action tools out of the initial setup. Adding a tool because it is available is not a reason to let a policy helper use it.
Rovo's Confluence chat interface, retained from an earlier eesel article. Current setup steps are documented in Atlassian's agent creation guide.
Review scope and sharing
Atlassian says Rovo knowledge can include Confluence spaces, individual pages and connected sources. Its knowledge documentation also says agents have organization-wide knowledge scope unless configured otherwise, while respecting the prompting user's source permissions.
That is a reason to inspect defaults. “This person can view a document” and “this document is relevant to this helper” are different tests.
Rovo Studio administrators can restrict who creates agents. Agent visibility and management also have their own controls. Check the governance documentation before making a team-wide helper available.
Option 2: Set up an eesel teammate with Confluence knowledge
An eesel support teammate can use your wiki to answer questions wherever its configured support workflow operates: Slack, Microsoft Teams, the eesel dashboard, a helpdesk reply, a chat bubble or email. Confluence is a knowledge source in this setup, not a general-purpose write connection.
The integration documentation describes a read-only connection to Confluence Cloud with an Atlassian API token. There is no Marketplace app to install. The agent reads Confluence live with four actions: search (across spaces or within one space), get a page, list spaces and list child pages. Nothing is copied into eesel, so it works from the current version of a page and links the page it used. It cannot create, edit, move or delete wiki content, and it adds no Confluence triggers. Data Center is a managed setup eesel runs for some customers, not the self-serve Cloud connection.
This suits a different assignment from editing Confluence pages: helping a support teammate use approved documentation. If your team also works in Jira, the same teammate can be an AI agent for Jira that answers Jira Service Management tickets from these pages. I would evaluate it with the same policy questions as the native option, not assume either product is accurate because it found a source link. You can try it free with 100 credits.
Configure and test the teammate through eesel CLI
The eesel CLI gives people, scripts and coding agents access to the same workspace and agent as the dashboard. JSON output makes setup and inspection usable by an agent running terminal commands. It can inspect instructions and integrations, chat with the teammate and show activity.
For a policy helper, that means you can keep a repeatable set of test questions alongside your setup notes. A colleague can use the dashboard while you inspect the same teammate from a terminal.
1. Confirm the workspace and agent
With Node.js 18.17 or newer:
npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
Create or choose a separate test helpdesk agent in the dashboard. In the commands below, replace TEST_AGENT_ID with that agent's actual ID. Do not use a production agent just because it is the saved default.
npx @eesel/cli --agent TEST_AGENT_ID instructions
npx @eesel/cli --agent TEST_AGENT_ID integrations
npx @eesel/cli --agent TEST_AGENT_ID automations
Check the standing instructions and existing connections. For this pilot, I would leave unrelated automations and outward-facing channels disabled. A “draft only” prompt is not a substitute for restricting the available actions.
2. Connect Confluence and scope what it can see
Ask the test teammate in its dashboard chat to connect Confluence, or open Integrations and pick Confluence (API token). It asks for your Confluence subdomain, your Atlassian email and an API token. You paste the token into a secure form, not into the chat.
The token acts as the account that created it, so the agent sees exactly what that account can open. That is the real scope control. For a policy helper, connect with an account that can open the approved policy spaces and little else, rather than an admin account that sees everything. You can also tell the agent in its instructions to search only the policy space, but treat that as guidance, not an access control.
The read actions return page text. If an approved PDF contains necessary detail, upload it separately to the intended agent or put that content into the page. The source setup guide covers these boundaries.
npx @eesel/cli --agent TEST_AGENT_ID integrations
npx @eesel/cli --agent TEST_AGENT_ID status
Confirm that Confluence shows as connected. There is no document count, because nothing is copied in. “Connected” is a setup signal, not proof that an answer will use the right policy.
3. Set the behavior deliberately
Use the dashboard's instructions editor to record the assignment you agreed with the policy owner. For this example, the important requirements are citing the policy, asking for missing details and escalating undocumented exceptions.
Read the instructions again through the CLI after saving:
npx @eesel/cli --agent TEST_AGENT_ID instructions
Keep instructions separate from source material. Uploading a policy provides knowledge; it does not automatically set the teammate's standing rules or authorize approvals.
4. Ask a question that exposes missing information
Write down what a correct answer should include before testing. Then try a fictional question whose answer depends on your actual policy:
npx @eesel/cli --agent TEST_AGENT_ID new --name "expense-policy-pilot"
npx @eesel/cli --agent TEST_AGENT_ID chat "For an internal employee: I paid for dinner while traveling for work. What information do you need to explain which expense-policy rules apply? Use the indexed policy and cite it. Do not invent limits or approve reimbursement. Do not send messages or change records."
npx @eesel/cli --agent TEST_AGENT_ID activity
new creates a conversation, not an agent. Chat can use permitted tools and incur usage, so inspect activity as well as the answer. These behaviors are documented in the CLI reference.
The point is not to force a refusal. If the policy supports a direct explanation, the agent should give it. If location, amount or another fact matters, it should ask rather than invent the missing input.
5. Test exceptions and audience boundaries
Use fresh conversations for separate cases. I would include:
| Test | What it should reveal |
|---|---|
| Clearly documented case | Whether the answer preserves the applicable rule |
| Missing required detail | Whether the agent asks a useful follow-up |
| Undocumented exception | Whether it routes the question instead of inventing approval |
| Conflicting policy versions | Whether it flags uncertainty rather than silently choosing |
| Different audience | Whether internal details stay out of an inappropriate response |
Keep the page URL, expected answer, actual answer and any correction together. That makes the result easier to review than a vague “the chatbot seemed good” verdict.
Do not enter real employee financial details just to test the flow. Fictional examples can expose these failures without introducing unnecessary personal data.
The eesel dashboard provides another view of the same teammate. CLI checks and dashboard review work on the same setup.
Troubleshoot knowledge before expanding the prompt
If an answer misses a policy, inspect the source path first. The agent reads Confluence live, so there is no index to wait for, but it only sees what the connected account can open. Its troubleshooting guide covers account access, Confluence licences and expired tokens.
| Symptom | First check |
|---|---|
| Page never appears | Whether the connected account can open that space and page |
| Agent cannot read Confluence at all | Whether the connected account has a Confluence licence |
| Important PDF content is missing | Whether it was separately uploaded or included in page text |
| Old wording persists | Whether the edit was published, and whether an older copy of the page still exists |
| Confluence stops working after a while | The API token's expiry date |
| Correct source, wrong answer | Instructions, retrieval evidence and the exact question |
If the policy itself is ambiguous, ask its owner to clarify it. If the policy is sound but the agent consistently misreads an exception, retain that question as a regression test.
The CLI's --dry-run flag previews a write request without sending it. It does not simulate the quality of a generated answer. Do not present that flag as a substitute for the evaluation above.
What does a Confluence AI agent cost?
Atlassian's Rovo licensing FAQ includes Standard, Premium and Enterprise Cloud plans. A claim that you must always upgrade to Premium for native AI is outdated. Check the plan, feature and organization-level allowance relevant to your deployment.
Rovo runs on credits pooled across your organization each month: 25 per Confluence user on Standard, 70 on Premium and 150 on Enterprise. A basic Rovo agent interaction uses 10 credits, while advanced agents use a variable amount. Extra usage is on by default at $0.01 per credit, billed from 3 December 2026, and an admin can cap it or turn it off. If you are comparing Rovo with other tools, see my list of Rovo alternatives.
eesel work is billed separately from Atlassian, as one fixed monthly price: 1 credit per ticket or chat, from $299/month for 500 credits, with no per-seat fee. Review eesel pricing before a batch of test conversations, and check live billing from the terminal if needed:
npx @eesel/cli billing
That is a read-only billing view, not a forecast of what your future question set will cost. For either route, I would track useful answers, required corrections and usage together. More answers are not better value if a person has to repair each one.
Launch the channel only after testing the job
A terminal test shows how the teammate responded in that context. It does not prove that a Slack audience, helpdesk workflow or public channel is configured correctly. Test the intended channel separately with appropriate access and a small pilot group.
For internal support, check that an employee gets the right explanation and escalation path. For customer service, use customer-safe sources and confirm the actual reply destination. For documentation improvement, let the page owner review proposed changes; eesel's Confluence connection does not publish them.
Start with the smallest page set that can answer a real recurring question. Try eesel free, inspect the teammate with eesel CLI, and expand only when the answers and permissions hold up to review.