Why Can't Anyone Answer Questions About the Business? — Garrett Galow, WorkOS

WorkOS 面臨的核心問題是業務人員頻繁需要數據洞察，但傳統流程極其低效。當有人想回答「什麼內容最能驅動新客戶」這類問題時，他們往往技術水平不足以自行查詢，必須向技術人員尋求幫助。技術人員需要理解背景、確認需求範圍、撰寫 SQL 查詢、驗證結果是否符合預期，然後將答案分享在 Slack 中。這個流程容易出現誤解，最終答案通常是一次性的，無法被其他團隊成員重用。

為了解決這個問題，WorkOS 構建了 Studio——一個智能化的內部工作空間。用戶可以在內部儀表板或 Slack bot 中用自然語言提出任何商業問題。系統首先進行序列化的前置檢查，確認所有工具是否正確連接、是否掌握足夠上下文來回答問題，然後通過 LangGraph agent 驅動 Claude Opus 模型開始工作流。

在執行階段，系統的關鍵創新在於分層上下文管理。不是預加載所有數據源的完整 schema（會爆表 context window），而是在 agent 決定調用特定工具時才動態注入該工具的上下文。舉例來說，Snowflake 的上下文包含該公司內部 database 的完整 schema——客戶、環境、資源的表示方式，以及複雜的 join 邏輯（某些關聯需要跨四張表）。同樣，Radar 安全產品的上下文定義了 attempts（登入嘗試）與 detections（偵測事件）的區別，以及如何正確過濾已刪除實體和確認 status column。

系統執行查詢後，進行驗證層檢查。許多 SQL 查詢在語法上完全有效，但返回零結果——這種情況下如果系統沒有察覺，答案對使用者毫無用處。因此 Studio 會實際執行查詢、檢查返回數據是否存在、驗證邏輯是否符合業務常識（如應該過濾已刪除的客戶、應該只計算 active status 的資源）。

當用戶滿足於初步答案後可以要求「幫我建立可重用的儀表板」。此時系統的行為升級為生成完整的 widget 代碼。Widget 包含三個部分：前端 UI（表格、圖表、篩選器）、後端 API 邏輯（呼叫各個工具提取數據）、以及底層 query。一旦 widget 生成並驗證通過，它就變成純 JavaScript 代碼運行——LLM 此後完全不參與。當用戶點擊「刷新」時，系統只是重新執行儲存的 query，無需再次調用 LLM，因此成本固定、性能可靠、結果完全一致。

支持團隊因此可以用 Slack bot 自助查詢特定客戶的問題。例如，Radar 用戶會問「為什麼我被這個系統封鎖了」，支持人員可以通過 Studio 的 widget 快速查詢該用戶的所有登入嘗試和封鎖歷史，無需轉向技術團隊。如果發現自己經常提出相同問題，支持人員甚至可以透過 Studio 自助構建新 widget，然後在團隊內共享。

當前的實裝方面，WorkOS 在連接層上使用用戶個別認證（每個人連接自己的 Snowflake、Linear、Notion 帳號），這在公司內部造成摩擦。公司正計畫透過自家產品 Pipes（第三方整合平台）實現組織級連接——一個人設定連接，其他人按照角色繼承權限（例如預設 Linear 為只讀，某些角色可編輯）。

成本考量上，WorkOS 明確選擇優先質量而非成本最優化。他們使用 Opus 而非更廉價的模型，因為性能差異足以正當化投資——Opus 在理解複雜 schema、處理動態 context 注入、驗證查詢結果上的卓越表現，使得一次性成本投入遠小於 bug 修復和人力投入的損耗。