Studio lets nontechnical teams ask business questions against Snowflake, Linear, and Notion without filing a request with engineering.
2
Reusable widgets are declarative JavaScript applications that query data sources directly, so the language model is not involved each time someone refreshes them.
3
Studio uses preflight sequencing, layered context, primary-source rules, query validation, and evals to reduce errors in generated answers and widgets.
Summary
Garrett Galow describes Studio, an internal WorkOS workspace for answering business questions and building reusable tools. The problem is familiar: someone asks for data, explains the context, waits for SQL, discovers that the answer needs another join, and shares the result as a one-off in Slack. Studio connects to Snowflake, Linear, and Notion, uses an agent to investigate questions, and can turn an answer into a widget with its own UI, APIs, and queries. Galow explains why the system is usable in support: schema context is added when a tool is called, product-specific instructions tell the model to consult primary sources, and every generated Snowflake query is run and checked for returned data before it becomes part of a widget. Once created, widgets run declarative JavaScript directly against the sources, which avoids language-model cost and variability on every refresh. Access controls are still being developed around shared organization connectors.
Business questions create a slow loop between teams
Galow describes questions from support and go-to-market teams about customers, product use, and business performance. Existing dashboards are rigid, so a request for one extra field often requires an engineer to change the dashboard or write new SQL. The requester explains the question and its context, waits for an answer, then often discovers that another layer of detail is needed. The result is a back-and-forth exchange and a one-off answer shared in Slack. WorkOS had this problem every day, which led the team to build Studio as an internal workspace where people can answer questions and create tools themselves.
Studio turns natural-language questions into data-backed answers
Studio can be used from an internal dashboard or a Slack bot. An API parses the request and sends it through LangGraph to an agent connected to an LLM, tools, and guidance about the company's data. WorkOS connects Studio primarily to Snowflake, Linear, and Notion. For a question about which marketing content leads to new team creations, the agent examines available resources, inspects Snowflake schemas, and runs queries against the internal database. It returns information such as the content associated with team sign-ups, along with a summary of the results.
Widgets preserve useful answers as reusable internal applications
After getting an answer, a user can ask Studio to build a table that shows the data across different time slices. Studio creates a widget, which Galow describes as sandboxed code containing the UI, APIs, and query needed for a usable tool. The widget can be rerun, filtered, shared with teammates, and used in recurring meetings. Galow also shows a Radar support widget that looks up login sessions for a customer or email address and reports whether access was blocked. Support staff can ask one-off questions themselves, then turn repeated questions into shared widgets instead of requesting another dashboard from a platform or data team.
Preflight sequencing keeps tool-specific context out of the initial prompt
Studio begins with checks that confirm the tools are connected, assess whether enough information is available, and ask clarifying questions when needed. It then decides which tools to call. Only when a tool is about to be invoked does Studio inject the context for using that tool. Snowflake's context includes a substantial description of the internal schema and instructions for relating teams, environments, and resources. Galow uses this approach because loading the context for every tool at the start would consume the context window before the agent knows which systems it needs.
Layered instructions tell the model to use WorkOS primary sources
Studio combines a base prompt, default instructions, organization rules, and tool-specific context. The tool context can preserve instructions edited for a particular setup. Galow also tells the language model to distrust its own knowledge about WorkOS, because model training data can be out of date while the product changes. The agent is instructed to look at primary sources such as WorkOS documentation instead of relying on what it remembers. This rule is part of the system's attempt to keep answers tied to current company information.
Before a generated Snowflake query is hardcoded into a widget, Studio runs it and checks that it returns data. Galow points out that valid SQL can still be useless when it produces zero rows. The system therefore pre-validates the query before deploying it into a dashboard. He also says the team uses evals in staging and production, with the same treatment in both environments, so the development experience and the experience used by colleagues are tested in the same way.
Widgets remove language-model variability after they are created
A widget is generated as declarative JavaScript that makes API calls to the connected services. Refreshing the widget reruns those calls without asking the language model to reason through the tools again. The model is used when someone requests a change, such as adding a column, but it is not involved in every execution. Inputs can be passed into the widget and fed into its queries as ordinary JavaScript inputs. Galow says this makes the final tool more reliable and avoids paying the language-model cost on every refresh.
Shared data access is still being built around organization connectors
At the time of the talk, users connect Snowflake, Linear, and Notion with their own accounts. Galow says this is inconvenient because every employee may not need to create each connection, and someone might need read access to a system where they do not have an account. WorkOS is using its Pipes product for third-party integrations and building organization connectors. One person can set up a connection and define default access rules. For example, Linear could be read-only by default, while selected Studio roles receive edit or admin access.
"We had this problem every day. And so we built a tool called Studio that serves as kind of an internal workspace where people can answer questions and build these kind of apps or dashboards themselves."02:11
Who should watch
You are an engineer who regularly answers SQL and data requests from support, sales, or marketing teams, and want to reduce the repeated back-and-forth.
Your company has dashboards that answer fixed questions while colleagues keep asking for small variations that require engineering work.
You are building an internal agent that generates queries or applications and need practical patterns for context injection, validation, permissions, and cost control.
