Apps

Apps are interactive tools that live in your workspace — calculators, dashboards, planners — built by agents and published by you. Where a work product is something to read, an app is something to use.

Every team runs on small tools: the spreadsheet that computes deal pricing, the doc that tracks team capacity, the checklist someone has rebuilt three times. Apps give those tools a durable home. An agent builds the tool in conversation, you publish it, and the workspace gets a versioned, permission-reviewed tool anyone can open.

What apps look like in practice:

App	What it does	Permissions it would request
Deal-size calculator	Seats, term, and discount tier in; annual price and approval notes out	None
Pipeline dashboard	Charts a data table the sales agent maintains	Read one data table
Content request intake	Collects briefs and hands each one to the content agent	Call one agent

Building an app

Ask an agent to build the tool you want — a description of the inputs, the outputs, and who will use it is usually enough to start:

Build a deal-size calculator for the sales team. Inputs: seat count, contract term, and discount tier. Output: the annual price, with a note when the discount needs manager approval. Use the pricing rules from the Product handbook knowledge base.

When you’re happy with the preview (previews run with write capabilities disabled, so you can try the tool freely without side effects), choose Publish as App: name it, describe it for the gallery, pick an emoji icon, and review the permissions it requests — which agents it can call, which data tables it may read or write, which integrations and storage it touches. Nothing is granted silently; newly requested permissions are badged on every update.

Read the permission list like an access grant

An app’s permissions describe its reach. An app that requests nothing can only compute; one that writes a data table or touches an integration acts on shared state every time someone uses it. Because updates badge newly requested permissions, you only re-review what changed — the review stays quick as the app evolves.

Running and evolving

Open an app from the Apps page to use it. To change it, hit Edit — which starts an agent session seeded with the app — describe the change, and publish the update. Each publish becomes a new version.

Changes are described the way the app was built: in plain language. “Add a multi-year option to the term input.” “The approval note should trigger at 15%, not 20%.” The session shows the agent’s work as it makes the change, and the update goes live when you publish it.

Versions

Apps keep their whole history. The published version serves as Head, and restoring an older version just moves the head pointer — nothing is deleted. That makes iteration low-stakes: if an update misbehaves, restore the previous version and Head moves back, with the newer version still in history when you want to revisit it.

Retire an app by archiving it (reversible) or deleting it (which removes its version history and storage permanently). Archive when a tool has run its course but its history still has value; reserve deletion for apps that should leave nothing behind.

Patterns that work

• Encode the spreadsheet — the pricing calculator that lives in a spreadsheet someone quietly maintains becomes an app: the rules sit in one reviewed place, and changes become versions instead of forked copies.
• Window onto a table — a dashboard that reads a data table an agent maintains: the assignment keeps the data current and the app keeps it legible. Pairs naturally with the agent-maintained table guide.
• Front door for an agent — an intake tool that calls an agent, so teammates submit a structured request instead of composing a prompt from scratch.