Aptarium
Product

Your agent builds the readout. Aptarium publishes it.

Creation is solved — a real readout is now as easy to ask for as the deck. What isn't solved is everything after: where the readout lives, how the team opens it, whether it's current, and who owns it. Aptarium is that layer. It supplies the governed data access, publishing, versions, sign-in, and audiences that turn a coding agent's output into an internal readout your org can trust. Aptarium is not a builder and runs no model inference.

For the technical reader

The three cards below go deep on the mechanics — the setup command, the token it mints, the configuration the agent writes. If you don't write code, you can skip them without missing anything: "If you own the report, you can own the readout" further down walks the exact same three moves in plain language, with none of the plumbing.

01

Pair the agent you already use.

aptarium setup signs you in with Google, detects the coding agent on your machine, installs Aptarium's skills and MCP configuration, and mints a 90-day least-privilege token. The scopes are data:read, apps:read, and apps:deploy by default; share:manage is an explicit opt-in with --share. The secret is installed but never printed. There are no API keys to mint, copy, or paste — you connect the agent, not a pile of credentials.

02

Build an ordinary web page, publish it as a readout behind sign-in.

The agent writes plain HTML/CSS/JS and declares its connector reads as named bindings in aptarium.json (Jira shown here as the worked example; each of the ten connectors has its own read allowlist). Aptarium content-addresses the files, commits an immutable version, and serves it at an org-scoped URL that requires sign-in. Every connector ships with a complete recipe — sprint status, delivery, pipeline, support, on-call, weekly status — so the clock is never spent on a blank page.

03

Share like a link, manage like software.

Widen the audience on purpose: a named teammate, a space, the whole org, or an expiring guest scoped to a single readout. Every deploy is immutable, diffable, and reversible with one command. The readout has a named owner, revocation, and a full audit trail — and nothing is public by default.

Where the data flows

The proxy sits on the boundary, so the readout never holds a credential.

Jira shown as the worked example below; the same boundary applies to every connector, each with its own read allowlist.

A readout never gets a connector key. When a viewer opens it, it asks Aptarium's data proxy for a piece of data it declared up front; the proxy runs that request against the viewer's own connected account — Jira, in this example — through a series of access checks, and returns only the rows that person is already permitted to see. The readout just renders them. There's no shared connection under the hood — the source system decides who sees what, exactly as it already does.

  • Live reads run as the viewer. Sam sees Sam's issues; Priya sees Priya's.
  • Editions are the shared, dated form, and they're explicit: a person chooses to publish an edition — a stable copy the whole team opens — carrying a byline: whose access it went out on, as of when. (The mechanism is a snapshot; on screen it's an edition with a byline.) A scheduled publish re-runs as its last human byline.
Agent builds the app CLI / MCP declares reads Proxy gates R0–R16 Jira read-only Viewer opens the URL App static, no keys as viewer
Apt the axolotl, thinking
While an edition is being published, the read is still evaluated as a person.
The four pillars

What agent output is still missing.

Agent-native

Skills, MCP, and one CLI command configure the coding tools your team already uses. No builder, no inference.

Identity-correct

Live connector reads run as each viewer's own account, with no standing shared credential in the live path. The one shared form is an edition with a byline, never an anonymous connection.

Snapshot-first

The shared, dated edition is the product; every edition names its byline and its as-of time, so a stable view is never anonymous. Per-viewer live reads are act two, for personal or sensitive views.

Versioned

Every deploy is immutable, diffable, and reversible with one command.

Adoption you can see

Versioned, and measured honestly.

Every version is retained and reversible. Usage is counted as authenticated views — the marketing north star is a readout opened by at least three distinct viewers in the trailing week (weekly active readouts), never a vanity page-hit. A handmade artifact that stopped being handmade is the whole point.

app.deployed → app.shared → app.viewed → app.third_viewer

sprint-dashboardLive
1,284 authenticated views · 7-day
For non-engineers

If you own the report, you can own the readout.

The lead maker is usually the person closest to the work — a program manager, an analyst, an ops lead, a chief of staff — not necessarily someone who writes code. A coding agent is an AI assistant that builds software from a plain-English request; you ask, it builds. It starts from a complete recipe and only needs to be pointed at your own data — a Jira board, your GitHub repos, your Linear cycle, a Google Sheet. Pairing the agent is one step, and rolling back a mistake is one step. You never touch an API key, a server, or a hosting dashboard — and if you don't have an agent yet, we help you set one up.

Cohorts invited weekly.

Apt the axolotl, content
No API key, no server, no hosting dashboard.
In a paragraph

Aptarium is where your team's readouts live. Any coding agent — Claude Code, Codex, Cursor, Copilot — builds the report as an ordinary web page; Aptarium publishes it to your organization behind sign-in, feeds it from the tools you already run — ten connectors at launch, from Jira and GitHub to Notion and HubSpot — and keeps fresh editions coming on schedule, each with a byline. Reads follow each viewer's own access, every edition names the person it went out on, and viewers are always free. Made in minutes, current without anyone's Sunday, and entirely yours.