Confluence already summarises a page for you. Rovo, Atlassian's built-in AI, will summarise a page, a live doc, or a blog post on demand, and it will summarise what changed since you last looked. So the honest version of this topic is not "how do I get AI summaries in Confluence". It is narrower: what do you do about the pages nobody thinks to open?

What Rovo already does, and on which plans
What Rovo already does, and on which plans

What Rovo already does, and on which plans

Start here, because most articles on this topic skip it and end up recommending you build something Atlassian ships for free with your plan. Rovo's summarising features are native, they sit in the page UI, and they are automatically activated on paid Confluence Cloud plans.

Availability matters more than the feature list. Rovo is available and automatically activated for all apps on Standard, Premium, and Enterprise plans, and it is not available for Atlassian Government apps. If your team is on the Free plan, none of the above is your baseline, and the calculation in this post changes completely.

Job to be doneRovo (built in)Scheduled summary agent
Condense one long page you already openedYes, on demandOverkill
See what changed on a page since your last visitYes, when you visit itYes, without you visiting
Condense a long comment threadYesPossible, rarely worth it
Notice a change on a page you did not openNoYes, this is the point
One digest across a whole spaceNoYes
Delivery to Slack or email on a cadenceNoYes
Works on the Free planNoYes, via the REST API

The gap: summaries need someone to ask

Every native summarising feature in Confluence is triggered by a human who is already on the page. That is a reasonable design, and it quietly assumes the thing you most need to read is the thing you already opened. In a busy space that assumption is wrong most weeks.

The documentation that hurts you is not the page you are reading. It is the runbook that changed while you were on holiday, the pricing page a colleague edited without telling anyone, the onboarding doc that drifted three revisions away from how the process actually works. Nobody opens those pages, so nobody asks for a summary, so the summary never happens. The feature works perfectly and the problem persists.

This is the same shape as the stale page problem in Confluence, approached from the other end. Stale-page work asks which documents stopped changing when they should have. Change-digest work asks which documents changed when you were not watching. Most teams need both and notice neither until something breaks in production.

What a scheduled summary agent actually does

The useful version of this agent is unglamorous and narrow. It does not read your whole knowledge base and produce insight. It runs on a cadence, asks the API a boring question, and writes a short digest that is mostly empty on a quiet week.

  1. Wake on a schedule. Daily or weekly. Weekly is right for most spaces.
  2. List the pages in scope. One space, or a labelled subset. Scope creep is what makes these digests unreadable.
  3. Compare versions against the last run. Every Confluence page carries a version number and a version history; the agent stores the last-seen version per page and asks which have moved.
  4. Fetch only what changed. Pull the body of the changed pages, not the whole space.
  5. Summarise per page, then rank. A two-line summary per changed page, ordered by how much moved, not alphabetically.
  6. Deliver one message. Slack or email. One digest, not one notification per page, which is the failure mode of Confluence's own watch feature.

Point six is the whole value proposition. Confluence can already email you when a page changes. Teams turn that off within a fortnight because it produces a notification per edit and a typo fix looks identical to a rewritten deployment procedure. A digest that says "four pages changed, here is what each change was, one of them is your runbook" is a different product built on the same event.

What we ran, and what surprised us

We pointed a weekly version-diff digest at our own internal documentation space to see whether the output was worth reading. The setup was the one described above: list pages, compare stored version numbers, summarise the bodies that moved, post one Slack message on Monday morning.

Two things came out of it that we did not expect. The first is that the digest is boring, and that is the feature. Most weeks it lists two or three pages and takes fifteen seconds to read. The weeks it matters, it surfaces one line you would otherwise have missed entirely. A tool that is mostly empty is easy to keep reading; a tool that is always full gets muted.

The second is that the ranking mattered more than the summarising. Our first version listed changed pages in whatever order the API returned them, and it read like noise. Sorting by size of change, and putting a plain "minor edit" label on the trivial ones, did more for whether people actually read the digest than any improvement to the summary text itself. If you build one of these, spend your time on what gets to the top, not on prompt-tuning the prose.

The honest limitation: version-diff has no idea what is important. It knows the runbook changed by four hundred words. It does not know the runbook matters more than the team social page. You fix that by scoping the space or labelling the pages you care about, not by asking the model to guess.

The Confluence API primitives it needs

Everything above is built on the Confluence Cloud REST API v2, which is public, documented, and does not require a marketplace app. The endpoints an agent of this shape touches are few.

That list is worth checking before you commit to any tool that promises Confluence automation, because it tells you whether the vendor is doing something you could not do yourself. Reading pages and versions is table stakes. If a product's entire pitch is "we call the pages endpoint for you", you are paying for a cron job. This is the same test we would apply to any Atlassian-adjacent agent task like Jira backlog grooming: find the underlying API first, then judge the price.

When Rovo is enough and you should not build this

Most teams asking this question do not need an agent, and saying so is more useful than selling one. Skip the build entirely in these cases.

How to set one up

The build is genuinely small, and the sequence matters more than the tooling. Whether you write it yourself or describe it to an agent platform, the same five decisions determine whether anyone reads the output.

  1. Pick one space. Not all of them. You can widen later.
  2. Create a scoped API token with read access only. A summary agent never needs write permission, and giving it one is how a digest tool turns into an incident.
  3. Store last-seen version numbers somewhere durable. This is the only state the agent needs.
  4. Set the cadence to weekly and move to daily only if a week's digest is consistently too long to read.
  5. Send it to a channel, not a person. Digests that arrive in a shared channel get corrected when they are wrong; digests in a DM get ignored.

On Gravity you would describe that outcome in plain language, connect the Confluence account with read scope, and set it to run weekly. If you are comparing how this kind of scheduled task is priced across platforms, our breakdown of the cheapest AI agent platforms covers the all-in cost of low-frequency jobs, which are usually mispriced by per-seat tools. For the underlying mechanics of scheduled autonomous tasks, how AI agents work covers the loop this sits on, and the what is an AI agent primer covers the vocabulary.

What it costs

A weekly digest over one space is one of the cheapest useful agents you can run, because the frequency is low and the payload is small. The cost is dominated by how many pages changed, not by how many pages exist.

Rovo itself carries no separate line item on Standard, Premium, and Enterprise plans, so if native summarising solves your problem the marginal cost is zero and you should stop reading. For the scheduled agent, a weekly run summarising a handful of changed pages is a few thousand tokens per week. On Gravity that fits inside the free tier's single agent at $0 a month for most teams; paid plans start at $20 a month and include $20 of usage, with extra usage available beyond the plan if you widen the scope to many spaces or move to a daily cadence.

Frequently asked questions

Can AI summarise a Confluence page?

Yes, natively. Rovo, Atlassian's built-in AI, summarises a page, live doc, or blog post when you select Summarize on the page, and it can also summarise the changes since you last visited and the unresolved comments on the page. It is automatically activated on Standard, Premium, and Enterprise Confluence Cloud plans, so on a paid plan you do not need any third-party tool for single-page summarising.

What can an AI agent do that Rovo cannot?

Run without being asked. Every native summarising feature triggers when a human opens the page, which means it never covers the pages nobody opened. A scheduled agent walks a space on a cadence, detects which pages changed since its last run, and delivers one ranked digest. It also works on the Free plan, where Rovo is not available, and it can deliver into Slack or email rather than living inside Confluence.

Do I need a Marketplace app to build this?

No. The Confluence Cloud REST API v2 is public and documented, and change detection needs only the page, version, and descendants endpoints plus a read-scoped API token. A Marketplace app is worth paying for when it provides something beyond those calls; if the pitch is only that it reads your pages for you, you are buying a scheduled script.

How often should the digest run?

Weekly for most spaces. Daily digests on a normal documentation space are mostly empty, and an empty message that arrives every morning gets filtered within a fortnight. Start weekly and increase the frequency only when a single week's digest is reliably too long to read in under a minute.

Is this different from Confluence page watching?

Yes, and the difference is the reason people build it. Watching a page emails you on every edit, so a corrected typo and a rewritten deployment runbook produce identical notifications. Teams mute it. A digest batches a period's changes into one message, summarises what each change was, and ranks by how much actually moved, which is what makes it readable enough to survive.

Does the agent need write access to Confluence?

No, and it should not have it. Summarising is a read-only job. Create the API token with read scope only. The main risk in connecting an agent to a documentation system is not a bad summary, it is a tool with edit permission acting on a misreading, and read-only scoping removes that risk entirely.

Sources