Studio Sheets: The Spreadsheet That Reads From the Graph, Not From CSVs

Every Ops team at a software company builds the same spreadsheet. Pull a list of competitors. Look up reviews per competitor. Look up pricing per competitor. Look up integrations per competitor. Look up funding per competitor. Look up the recent press per competitor. The result is a 25-column wide sheet with 60 rows — much of which is stale by the time the sheet is shared, because each lookup was a manual snapshot from a different tool.

The default enterprise-analytics workflow is a spreadsheet with 25 manually-stitched columns. Studio Sheets is the same surface — spreadsheet UI, formulas, the cell paradigm · but the rows come straight from the graph, and a formula can look up a graph node or run a model.

Spreadsheets are still where most analysts do their work. The spreadsheet isn't going away. The argument is about what sits underneath it. Studio Sheets is the variant where the substrate is a typed product graph instead of a stack of CSVs.

Section 1: The three things that make Studio Sheets different

1. Rows come from the graph, not from a CSV

Bind a sheet to a table in the product graph — products, companies, reviews, categories, industries, countries, roles, and the other taxonomies — or to one of your own tables, such as the accounts and deals your Salesforce sync writes into PYRAMYD. The rows load from that table when the sheet opens, and the columns are its fields. Nothing is exported first.

Keeping a VLOOKUP's right-hand side current is manual work that never ends. Sheets replaces it with graph functions: =GRAPHLOOKUP(row.company, "arr") reads a field off the matching node in the graph the sheet is bound to, and =GRAPHCOUNT counts the nodes of a type. The graph loads once, so a whole column of lookups costs one request.

2. AI-filled values show their source

When AI enrichment fills a contact's fields in a sheet, it shows the source URL, the time, and the method beside each value it found on a source, so the question "where did this come from?" has an answer in the grid, not in someone's memory. Today those values and their sources stay in the grid only until the page reloads; export the sheet to Excel to keep them.

3. Formulas can call the graph and a model

A regular column holds values. A calculated column holds a formula, and in Sheets that formula can reach past the sheet. The graph functions above read the graph; the AI functions — AI_CLASSIFY, AI_SUMMARIZE, AI_EXTRACT, AI_SENTIMENT, AI_TRANSLATE and AI_CLEAN — run a model over a value and return one result per row. APEX's agents can work the grid themselves: create, rename, duplicate, or delete sheets, switch on a pivot, and export to CSV or Excel.

The pattern is borrowed from Bloomberg's BQL functions[4] · a BQL formula in an Excel cell pulls Bloomberg Terminal data straight into the cell. Graph and AI formulas do the same thing for the product graph. Today calculated columns and typed formulas last only while the sheet is open; saving them with the sheet is not built yet, so export to Excel to keep a result.

Section 2: The architecture: bound tables and cached AI calls

Under the hood, a sheet is bound to one source table and loads its rows from it when it opens. Graph formulas load the bound graph once and answer every lookup from that copy.

AI formulas are batched: cells queue up and go to the model in a single request every ~150 ms, or as soon as 25 are waiting. Results are cached by operation, arguments, and input, so the same input is not sent to the model twice in a session.

Section 3: Sharing a sheet

Share a saved sheet with a person or a team as a viewer, commenter, or editor, or send a tracked link with an expiry, allowed domains, and an optional passcode. Live co-editing (an avatar bar, live cursors, and the sheet's layout syncing between people) is built but not running yet, so it is coming rather than available today.

Sharing is separate from the graph substrate. The sheet is a thin view; the underlying data is the graph. Two people who open the same sheet are reading the same tables, not copies of each other's spreadsheet.

Section 4: Three workflows to start with

Account scoring

Bind a sheet to your accounts — the companies your Salesforce sync writes into PYRAMYD — and score them with calculated columns. An AI_CLASSIFY column can sort each account into the segments you define.

Feature parity matrix

Start from the Feature Parity & Capability Matrix template. Rows: capabilities, grouped by category. Columns: your product and the solutions you compare it with, each scored 2 (native), 1 (workaround) or 0 (missing). It gives the gap analysis a PMM does by hand one standard shape.

Win/loss aggregation

Start from the Win/Loss Quantitative Tracker template, or bind a sheet to the deals your Salesforce sync brings in. The template pairs a deal log with a per-competitor win-rate summary, and an AI_CLASSIFY column can sort free-text loss reasons into a fixed set of labels. Until saving cell edits and calculated columns is built, export the sheet to Excel to keep your changes.

Section 5: Why the spreadsheet was the right surface

Studio could have shipped only the dashboards, only the agents, only the documents. The spreadsheet is in the bundle because it's how analysts actually think. Spreadsheets have stayed dominant because the cell-based mental model maps to how people organise knowledge: rows are things, columns are properties, cells are answers.

What changes when the substrate is a typed graph is the cost of answering. In a CSV-backed sheet, every new question is a new lookup table. In Sheets, many new questions are a new formula over data that is already there.

The deeper claim is that the spreadsheet was never the problem. The problem was that the cells underneath weren't typed and weren't connected to the data. Once they are, the spreadsheet stops being a stale snapshot and starts being a queryable view onto the substrate · which is what enterprise analysts have wanted since at least 1985.