There's a particular kind of work that never shows up in a job description: you ask the questions, you find the answer, and then you do it again next month. Same questions, same joins, newer numbers, and a fresh afternoon gone.
Databasin One now offers to take that job. When a conversation has done something worth repeating, there's an Automate this action — in the chat sidebar, and on the answer itself. Click it, and the conversation becomes a scheduled report.
Everything happens over the chat
The modal opens already filled in, because the conversation is the specification. No wizard, no second screen, nothing to rediscover somewhere else.
It carries the questions you actually asked, the tables you were working against, and — the important part — the SQL that already ran successfully. Not a guess at what you meant. The queries that worked, on your data, minutes ago. The modal says so plainly: carries N queries that already worked in this conversation.
What you fill in is the small stuff:
- Questions it will keep answering — your turns, numbered, editable
- How often — every weekday morning, every Monday morning, first of the month, or the start of each quarter
- Who gets it, and whether they get an email, a PDF, or both
- Only send when there is something worth reporting — for the reports that should stay quiet on a normal week
Preview before you commit
Preview report runs the same request the schedule will run — same skill, same queries, same budgets — against live data, right then. What appears in the modal is not a mockup. It's the document, rendered: this is what each run will deliver, built from live data just now.
That matters more than it sounds. A scheduled report that turns out wrong is a special kind of annoying, because you find out on a Monday in front of other people.
Only then does Create automation save it. The two-step is deliberate — this thing will email other people on a schedule, so nothing is created until you've seen what they'll get.
The design is ours, the content is yours
The interesting engineering here isn't that a model can write a report. It's that the same spec always produces the same document.
The model supplies content and structure — the headline figure, which comparison matters, what the finding actually is. It does not supply appearance. It can't: the renderer doesn't sanitize a color out of the model's output, it rebuilds the document from a fixed vocabulary of named blocks and never reads anything else. A stray color, font, or snippet of HTML isn't stripped; it's simply never looked at.
The vocabulary is ten blocks — a hero figure, stat tiles, sections, prose, a composition bar, charts, report-card tables, callouts, bullets, and a fine-print block for sources and row counts. Series colors are positional, so the model never names one. Chart types are an enum, and anything unrecognized becomes a column chart rather than an argument.
There's a nice detail in there: a stat's delta is colored by what it means, not by its sign. Costs up 8% and revenue up 8% are not the same news. Unstated, it renders neutral rather than guessing.
And if a spec comes back malformed, the report is rejected wholesale and the run falls back to the plain markdown it always sent. There is no half-rendered document.
Reports that survive being printed
Every chart is drawn as an image at twice its display size and embedded directly in the document, which is why the PDF looks like a document rather than a web page that lost a fight with a printer. The whole layout is built to survive the trip from HTML to PDF intact.
Ask for both in the modal and the styled report arrives as the email body and as a PDF attachment.
The same machinery, just easier to reach
None of this is a separate product. It creates an ordinary agent automation running an ordinary skill, on the same canvas as your SQL, dbt, notebook, and OCR tasks — same read-only tools, same query budgets, same audit trail per run. You can open it later and edit it like anything else.
And you can go the other way: Report Composer sits in the skills library as a preset, so you can copy it into any agent task you build by hand — which is also how you point it at Slack, Teams, or a write-back to your lakehouse instead of email.
What changed is the distance between having a good answer and having it forever. It used to be a project. Now it's a button.
Ask Databasin One something worth asking twice, then look for Automate this.