Numbers Station uses a unified Knowledge Layer to give analytics agents business-specific context from warehouses, dashboards, catalogs, Slack, and other sources.
2
A SQL agent can retrieve relevant context, generate SQL, execute it, inspect errors, and retry instead of following a fixed sequence of steps.
3
A planner can coordinate specialist agents for SQL, charts, reports, conversations, and slide decks while preserving shared history.
Summary
Ines Chami explains how Numbers Station builds production analytics workflows around LLM agents. The starting problem is self-service analytics: data teams receive requests to find dashboards, explain fields, write SQL, and answer business questions. Numbers Station connects to data tools and other sources, then builds a unified Knowledge Layer containing schemas, metrics, definitions, and business context. Agents retrieve this information before acting. Chami uses a SQL agent to show the architecture. It can call retrieval and query-execution tools, decide what to do next, correct SQL after database errors, and return an answer. She then describes charting agents and a hierarchical planner that routes work among specialist agents. She is direct about the less glamorous work: ingesting metadata, handling internal terminology, respecting source-system permissions, and collecting admin feedback. These steps matter because a fluent SQL answer can still be wrong without organizational context.
Self-service analytics is needed because data teams are overwhelmed by support requests
Chami says modern data stacks have improved ELT pipelines, storage, and compute, while also creating more tools and resources for users to understand. Data consumers ask teams to find dashboards, explain how database fields were created, and write SQL queries. Data teams then spend much of their time triaging tickets instead of working on longer-term data projects. LLM demos have raised user expectations further because people have seen models write SQL and generate charts, even though few of those demos have reached production.
Numbers Station builds a Knowledge Layer from the organization's existing tools
Numbers Station connects to data warehouses, dashboarding tools, data catalogs, Slack channels, message history, and other sources that contain useful knowledge. It turns this material into a unified Knowledge Layer with items such as tables, columns, metrics, and dimensions. Chami calls this the most important part of the platform because it gives agents business-specific context. Retrieval augmented generation then fetches relevant information for each user question instead of asking the model to rely only on its general training.
A fixed generation-and-execution pipeline cannot recover well from errors
Chami begins the SQL example with a prompt containing the user's natural-language request and the database schema. The model can produce SQL, but someone still has to copy it into an executor. Adding an execution tool improves this, yet a manually written flow remains limited. If the generated query uses the wrong table name or fails to compile, the fixed sequence stops unless developers keep adding special cases. This makes the control flow complicated as more possible failures appear.
An agent can choose actions and retry after a database error
In an agentic system, the LLM decides which tool to call and what to do next. The sequence is therefore not fixed in advance. Chami gives the example of a query that fails to compile. The agent can read the error message, correct the SQL, run it again, and produce a final response. The agent has a prompt defining its responsibility, registered tools such as SQL execution and Knowledge Layer search, and a decision loop that ends when it returns an answer rather than another tool call.
Retrieval grounds SQL in business definitions that the model cannot infer
A plausible number is not enough if the model used the wrong calculation. Chami says the model cannot be given every piece of organizational context in one prompt, so the system retrieves relevant fragments from an index. These fragments can include schemas, SQL, and metric definitions. Her example defines active customers with a business-specific filter where closed is not zero. That rule might live in a Tableau report or an email, and the agent needs to retrieve it before generating SQL.
Specialist agents can work under a planner with shared history
After describing the SQL agent, Chami introduces a charting agent. It can write Python charts, execute Python, search documentation, and reuse examples of charts generated before. Multiple agents are coordinated through a hierarchical design. A planner decomposes a user request into subtasks and routes them to agents that search reports, inspect conversations, write queries, generate charts, or create slide decks. The user talks to the planner, while the agents share history. A chart request can therefore use the SQL agent first and then pass the result to the charting agent.
Production accuracy depends on metadata work and controlled feedback
In the Q&A, Chami says the Knowledge Layer is the main way Numbers Station handles the gap between impressive demos and dependable answers. The system should be able to say it does not know rather than give an unsupported answer. Much of the implementation involves parsing, ingesting, and cleaning metadata from existing tools. Setup used to take a couple of weeks with customers, but had been reduced to a couple of hours of admin-user training and feedback. Chami still wants a final sanity check because internal names and terminology can be difficult to automate fully.
Agents should respect existing permissions and avoid uncontrolled routing growth
Chami says Numbers Station does not rebuild an organization's permission system. Each tool's existing access controls remain the source of truth, and the platform respects the permissions of the authenticated user. She also acknowledges that a hierarchical design would become difficult with dozens or hundreds of agents. Her proposed direction is multiple smaller hierarchies, with routing optimized so the system skips a model call when it is unnecessary. At the time of the talk, she says the product used at most about a dozen agents.
"The key to fix this accuracy problem is to bring in the context in the model through retrieval augmented generation and by leveraging this knowledge layer."Ines Chami09:01
Who should watch
You are building an LLM feature for analytics and need to connect model output to real database actions.
Your team is deciding whether retrieval, tool calls, or multiple specialist agents belong in a production workflow.
You need a practical account of the metadata, permissions, feedback, and routing work behind an analytics agent.
