Building Internal Flashboards in Slack with AI
Flashboards is WorkOS's internal reporting tool: a doc with a live data connection, and agents as the only editing interface. Zero to 55 weekly readers in seven weeks.
Flashboards, our internal reporting tool, has no chart builder. No drag-and-drop canvas, no widget library, no settings panel for axis labels. Claude and other agents are the only practical way to create or edit a board.
Here is what creating one looks like. A message in Slack, to an agent:
create a flashboard of weekly active directory sync teams, production environments only. display them as stacked columns segmented by freemail vs. business domains. include a toggle for Paid Only and a selector for lookback # of weeks: default 12 and include options for 4, 24, and 52 weeks. Add two leaderboards at the bottom for top 5 Dsync customers by (a) ARR and (b) total syncs L7d.
No ticket, no mockup, no chart-type picker. Ask for a chart in plain English and receive it in Slack moments later.
A flashboard is a doc with a live data connection
Think about how you create documents and spreadsheets. You draft the content, revise and iterate, then share that document with your team and collaborate. That is the mental model here: docs, with a database connection.
A flashboard is exactly that: a document with live data, closer to a Notion page than an old-school BI dashboard. Specifically, it's a self-contained, sanitized, secure HTML page that pulls fresh data every time it loads, at a stable URL. No credentials live in the page; queries run read-only through a same-origin proxy, and the whole thing is gated by AuthKit for employees only.
Drafting one is a sentence
The app is deliberately thin: a frame for loading files, file storage, a data query API, and a runtime that connects them. The runtime is injected when the page is served, so a board just calls window.flashboard. With this runtime, a complete board can be fully-customized HTML/JS, or as simple as this:
<!doctype html>
<title>Orgs by plan</title>
<h1>Orgs by plan</h1>
<div id="chart"></div>
<script>
const res = await flashboard.query(`
SELECT plan, count(*) AS n
FROM analytics_db.prod.organizations
GROUP BY 1 ORDER BY 2 DESC
`);
flashboard.chart(res, { x: "plan", y: "N", type: "bar", into: "#chart" });
</script>
Agents learn to work with this quickly. Queries can run at any time, not just on load, which is what makes filters and drill-downs work, and selections live in the URL.
Iterating is a conversation, and version history means nothing is lost
People converse with their agent for small tweaks and major rewrites alike. When they are ready, the next build and deploy is one operation: upload the new file.
Most boards are a single file, so the slow parts are agent code generation and network latency, not the platform. Replacing the whole small file rather than patching it costs a little speed and buys a lot of simplicity. There is also no local dev preview. You just upload your new draft.
That sounds reckless until you look at the version model: every build exists side by side, and one is production. A push stages a draft; re-pushing overwrites that draft in place, so iteration doesn't leave a trail of versions; publishing moves the live pointer, and rollback moves it back to any earlier version. Anything not live says so, and every version carries a console with queries executed and errors seen.
Draft, publish, roll back. The same moves you already make in a doc.
Sharing a board is sending a link
Because a board is a document, the permission model is delightfully boring and familiar. Any signed-in employee can view a board if they have the link. Remixing a flashboard or proposing a change back is a lightweight request and approval: your push stages a version, the owner reviews and either publishes it or discards it. New boards are open to any employee, and locking one down to an editor list is a per-board decision.
An agent with the pen still needs hard limits
A doc that can query production needs boundaries the author can't cross. The query proxy holds them, not the page: a read-only role, one statement per query, concurrency limits, a row cap, and a required viewer identity or the request fails closed, with every query tagged by board, version, and viewer for attribution. The viewer's identity is available to a board for personalization and is explicitly not an authorization credential. Values are bound, not interpolated, and dynamic column names are validated before reaching SQL.
Taste lives in docs, skills, and the MCP
Those limits stop an agent from doing damage. None of them make it produce something worth looking at, and there are no UI defaults left to do that job.
So the docs page carries the judgment. It's the canonical contract, served as a page, as Markdown, and as llms.txt for agents, and creation runs through the flashboard MCP from any MCP client. Everything a chart builder would have encoded in its defaults is written down: pinned, CSP-safe libraries with no build step, a house style built on a small design-token sheet with semantic colors, a real type scale, and flat dense cards, theme tokens a board can read so it follows the viewer's light/dark toggle, and a set of mobile rules, because boards get read on phones after someone drops a link in Slack.
An agent reads all of that before it writes a line. A person clicking through a chart builder would have absorbed it from the defaults, badly.
The app itself came off the paved path
None of the plumbing above was a bespoke build. Flashboards was scaffolded with wow, our internal app deployment CLI. wow app create starts an app with the opinionated defaults already baked in: AuthKit for login, Cloudflare Workers for hosting, SQLite per app, Doppler for secrets, and a GitHub Action that ships on merge. Boards, versions, and the live pointer are rows in that per-app database.
That paved path is the same one behind Claude Day, where 39 apps reached production in a single day with the non-technical person driving. The point of it is that whoever is building doesn't have to care about the stack.
So auth, hosting, storage, and deploys were decided before this project started. What was left to build was the part specific to reporting: the runtime, the version model, and the query proxy.
Flashboards works because of the investment in our data platform
An agent-only editor sitting on unmodeled tables and undocumented business rules generates confident, wrong charts faster than anyone can review them. That's why internal teams at WorkOS are constantly delivering:
- Better datasets that make reporting consistent, reliable, and fast.
- Better guidance including business rules, data gotchas, and the dataset routing that naive SQL table crawling can't do, curated and updated with every PR.
- Better tools to explore, create, update, and share findings, homegrown and vendor alike.
- Better distribution channels, so the above reaches people where they already work via marketplaces, MCPs, and agents in Slack.
Without these, the tool fails.
Atlas, our internal agent platform, was the first to have all four live, and none of it is Atlas-specific: it works with any harness, including Claude Code, Cowork, Codex, and Pi, with Wallaby and Horizon getting hooked in.
Seven weeks in
The agent-only bet is holding up in our warehouse query logs. Flashboards went from zero to 55 weekly readers in about seven weeks, 37 of them in the last full week and a new high in a week that isn't over yet. Twelve people authored or edited boards in that same week, and you don't need many authors when drafting one is a sentence.
Usage is live rather than scheduled. This week the proxy served about 6,300 panel fetches against roughly 630 authoring calls, across about 560 page loads, which works out to roughly 11 queries every time someone opens a board. There is no scheduler anywhere in the system: if a query ran, a person was looking at the result.
The sharpest signal is what happened to the commercial BI tools Flashboards is replacing. Weekly human users of our previous default fell by nearly three quarters over the same stretch, and most of its remaining query volume is unattended scheduled jobs, timers talking to themselves. People moved to the tool that answers in the room where they asked.
The point is confidence in the numbers
The gap between raw data tables and an agent's ability to find and synthesize metric definitions is still too big, and the answer isn't another third-party system to shove context into: the guidance has to be readable from where it already lives.
What we're after underneath all of it is trust in the data. Two people in different meetings pull the same number, agree on what it means, and decide that afternoon instead of scheduling a follow-up to reconcile spreadsheets.