Define the agent's job first
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, choose Agents, then Create. 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 selected wiki pages to answer questions wherever its configured support workflow operates. Confluence is a knowledge source in this setup, not a general-purpose write connection.
The integration documentation describes a read-only Marketplace app for Confluence Cloud. It cannot create, edit, move or delete wiki content, and it adds no Confluence triggers. Data Center requires a managed setup discussion rather than the self-serve Cloud installation.
This suits a different assignment from editing Confluence pages: helping a support teammate use approved documentation. 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.
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. Install the Confluence app and select knowledge
Ask the test teammate to help connect Confluence in its dashboard, or use the integration's Install App button. An authorized Confluence administrator must complete the Marketplace install.
Inside the eesel app in Confluence, choose the approved policy pages to index. Selecting a parent includes descendants, including future child pages. Review that subtree rather than assuming the parent contains only the visible policy.
Only selected, viewable page text is indexed. Attachments are excluded; 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 the expected source and content are available. “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 Confluence integration has a default limit of 3,000 pages per connection. It re-indexes saved edits and performs reconciliation roughly hourly. Its troubleshooting guide explains page selection, View access and stale-content checks.
| Symptom | First check |
|---|---|
| Page never appears | Selection and app permissions |
| Important PDF content is missing | Whether it was separately uploaded or included in page text |
| Old wording persists | Saved page version and indexing status |
| 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.
Compare costs without mixing pricing units
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.
eesel work is billed separately from Atlassian. 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, inspect the teammate with eesel CLI, and expand only when the answers and permissions hold up to review.