An AI report generator that keeps going: agents that build reports, refresh them on a schedule and share them as private pages

In this guide:

• What is an AI report generator?
• Which AI reporting tool fits?
• How does an Olano agent build and publish a report?
• Worked example: a weekly revenue report
• Why should a report page sit behind a password?
• Common mistakes
• How Olano helps, and its limits

What is an AI report generator?

An AI report generator is software that takes data and produces a readable report from it: the numbers, the charts and the sentences that explain them. Most products sold under the name do that middle part well: you give them a spreadsheet or a prompt, and they return a formatted summary.

The chores sit on either side of it: fetching this week's figures from Stripe and the CRM beforehand, then sending the report and doing it all again next Monday. So the real choice is between a one-off AI document and a report an agent owns.

Which AI reporting tool fits: a chat assistant, a BI tool or an agent?

It depends on whether people need to explore the numbers or read them. BI tools with AI features are built for exploring governed data; an agent that publishes is built for a recurring, narrated report drawn from several systems. Vendor details below were checked on 16 October 2026 against each vendor's own pages.

Sources: Microsoft's overview of Copilot for Power BI and Copilot in Fabric FAQ; Tableau's Tableau Pulse documentation; Google Cloud's Looker page and Looker pricing.

Where a BI tool is the better choice

If many people need to slice the same numbers their own way, drill from a total to the rows behind it, and trust that "revenue" means the same thing on every dashboard, use a BI tool. Governed self-serve analytics on a warehouse, with a semantic layer, row-level permissions and a data team maintaining the definitions, is what Power BI, Tableau and Looker are for. An agent-built report does not replace that.

An agent earns its place in the gaps: the weekly report that combines Stripe, a CRM and a spreadsheet nobody has modelled, or the client summary that has to arrive on its own. The two also combine: an agent can query the warehouse a BI tool sits on and narrate what it finds.

How does an Olano agent build and publish a report?

From parts it already has: tools that read your data, a charts skill, render tools, and Pages, which publishes a workspace folder as a password-protected web page. A scheduled job ties them together.

• Reading the data. 450+ connector tools and 75+ built-in integrations (Stripe, HubSpot, Salesforce, SQL databases, Google and more), plus any MCP server from a library of 200+, or your own. Credentials stay in a per-agent vault.
• Charting it. The built-in charts skill turns a small recipe or any Vega-Lite spec into a themed chart with a takeaway title and a source line.
• Rendering it. The render tools turn HTML into a PNG, PDF or SVG on the browser that ships with every install. No API key, no network, nothing billed.
• Publishing it. With the Pages toolkit added, the agent publishes a workspace folder, with index.html as the entry point, at <your deployment address>/pages/<name>/. The page is served live from that folder, so edits show on the next load.
• Repeating it. A scheduled job sends the agent its instructions at the time you choose, and can run on a bigger model than the agent's everyday one.

Worked example: a weekly revenue report every Monday at 7:00

A finance lead wants last week's revenue on Monday morning. You set it up once; after that it runs on its own.

Once, before the first run

1. Connect Stripe and the CRM to the agent. HubSpot and Salesforce have built-in toolkits; anything else can come in through an MCP server. The agent can send you a sign-in link for each from the chat.
2. Add the Pages toolkit to the agent, like any toolkit.
3. On the agent's Pages tab, set the viewer username and password (at least 8 characters).
4. Connect Slack or Telegram for the link, and email for the PDF.
5. In the Scheduler, create a task for Mondays at 7:00, Singapore time, with this message:

Build this week's revenue report.
Pull last week's Stripe payments, refunds and new subscriptions, and the CRM
deals marked won. Compare with the previous four weeks.
Chart weekly revenue, new vs lost recurring revenue and revenue by plan with
the charts skill; save the charts as SVG in reports/weekly-revenue/.
Move last week's page and charts into reports/weekly-revenue/archive/<date>/,
then rewrite index.html: three-line summary, the charts, a source and as-of
line, and a link to the archive. Totals only - no customer names, no raw exports
in that folder.
Render a dated PDF of the page to reports/pdf/.
Post the page link to #finance in Slack and email the PDF to the finance list.

What happens every Monday

At 7:00 the job wakes the agent. It reads the week's payments and closed deals, compares them with the previous four weeks, writes the summary, draws the three charts with the charts skill and rewrites index.html around them.

On the first run the agent publishes the folder as weekly-revenue, so the report lives at /pages/weekly-revenue/ on your deployment's address. After that, each run only rewrites the files: because the page is served live from the folder, the same link shows the new report next time anyone opens it, with earlier weeks one click away in the archive.

The render tools turn the same page into a PDF for the email, and the agent posts the link in Slack. If the agent's approval settings ask before outbound messages, those sends wait in Approvals for a person.

What it costs to run

The charts, the PDF and the page cost nothing extra: the render tools bill nothing and your deployment serves the page. The model's work is the cost, in credits on a managed deployment (1,000 credits is US$1, with a monthly allowance on every plan) or on your own provider key at no surcharge.

Why should a report page sit behind a password?

Because revenue, pipeline and customer names belong to the people you choose. A report page should be a password-protected website, not a public one, and on Olano that is not a setting you can forget: every page an agent publishes sits behind a username and password, and publishing never makes content publicly readable.

• One username and password per agent, covering every page that agent publishes. Viewers get the browser's sign-in prompt before anything loads.
• Set only by a person: the owner or an admin, on the agent's Pages tab, at least 8 characters. Change or remove it there.
• The agent never has it. Agents can neither set nor see the password, so it never appears in a conversation or a file.
• Locked until set. An agent can publish before a password exists, but its pages stay locked until you set one.
• Names are not shared. Each page name belongs to one agent, so agents cannot publish over each other.
• You can take it down. Stop, restart or delete a page; deleting releases the name and leaves the files in the workspace.

Who can see the report? Anyone who can reach your deployment's address and has the username and password: a board, an investor or a client, and nobody else.

Common mistakes

Sending the password with the link

A link and its password in one Slack message means anyone who can read that channel, now or in a year, can open the report. Post the link where the team works, hand the password over once another way, and change it on the Pages tab when someone leaves.

Publishing raw data the reader should not see

Everything inside the published folder can be opened by someone with the password, including files the page never links to. Keep exports and customer lists outside that folder, and say so in the job's instructions, as the example does.

Putting different audiences on one agent

One password covers all of an agent's pages, so a board report and a team report from the same agent are open to the same people. Give each audience its own agent.

Leaving out the source and the date

A chart without "Source: Stripe, as of Monday 07:00" invites the wrong question. Check the first few reports against the source system, then let the job run.

How Olano helps, and its limits

Olano runs persistent AI agents for a business on a deployment of your own. Reporting uses what is already there: connectors and MCP servers to read data, the charts skill and render tools to present it, the scheduler for recurring reports, 15+ messaging channels to deliver it, and Pages to publish it privately. The platform overview covers the rest; security covers approvals, audit and spending caps.

When you switch Cortex on, it runs Fully Autonomous by default, and in that mode it may publish an item's results as a page behind the same agent password. Rewrites of an agent's own instructions, outbound sends and irreversible actions still wait for a human.

The limits: an agent-built report is a narrated document with fixed charts, not an interactive analytics tool, and it is only as good as the data the connectors return. Plans start at US$25 a month, with unlimited agents and people and your own model keys on every plan; see Olano pricing.