RudderStack Docs – How to Work with Rudder Lookout

Lookout: How to Chat and Ask Questions to Rudder Lookout

Mon, 01 Jan 0001 00:00:00 +0000

Chat is the primary surface in Lookout and the entry point for almost everything else. You ask a question in plain English, and the Lookout agent inspects your data, runs a read-only query, and returns a durable chart or table.

Ask a question

Open a new chat and describe what you want to know — for example:

How many signups did we get last week, by source?

The agent:

Inspects the relevant tables and schema in your connected warehouse
Writes read-only SQL to answer the question
Runs the query against your warehouse and returns the result as a chart or table in the conversation

Because the agent reasons over your actual data journey — events, Tracking Plans, and the warehouse they land in — its answers are grounded in how your data really moves, not guessed from table names alone.

Warehouse access is read-only. The agent can list tables, inspect schema, and run queries, but it can’t write to or change your data.

See Warehouses for more details.

Results are durable

The charts and tables the agent produces are saved as durable bubbles in the transcript — they are results you can return to. From there you can:

Ask follow-up questions to refine or re-scope the answer
Save the answer as a dashboard for repeated use
Move from a warehouse number to the tracking-plan definition behind it, to the instrumentation code that emits it — all in the same conversation

Beyond questions

The same chat surface is where you drive the rest of Lookout. Depending on what your workspace has connected, you can ask the Lookout agent to:

Build and edit dashboards
Reference the generated documentation of how your events are instrumented to ground its answers (Generating that documentation happens in the Context Hub, not from chat)
Draft Measurement Plans for tracking changes
Explore your GitHub and GitLab repositories and propose changes as pull requests
Read and manage your RudderStack resources, including sources, destinations, transformations, Tracking Plans, and Audiences

Chat from Slack

You can talk to the same agent from Slack — by direct message or in a bound channel — without opening the web app. See Slack.

Lookout: How to Build Dashboards with Rudder Lookout

Mon, 01 Jan 0001 00:00:00 +0000

A dashboard turns an ad-hoc answer into something your team keeps. Dashboards are built and iterated on in chat, each has its own link inside your workspace, and they re-run their queries fresh on every load — so a dashboard always reflects current data.

Build a dashboard from chat

When an answer is worth keeping, ask the agent to save it as a dashboard panel. The agent writes a dashboard specification, its parameters and panels, and gives it a slug-addressed URL inside your workspace.

You can keep refining a dashboard conversationally — ask the agent to add a panel, change a grouping, or adjust a filter, and it edits the dashboard in place.

Panel types

A dashboard is made up of panels. Lookout supports four panel types:

Panel	Best for
Chart	Trends and comparisons over time or across categories
Table	Row-level detail and breakdowns
Metric	A single headline number, such as a total or a rate
Funnel	Step-by-step conversion through a sequence of events

Parameters and filters

Every dashboard carries parameters that let viewers re-scope the data without editing it:

Time range: Always present, so any viewer can change the window the dashboard covers.
Filters: Optional single-select and multi-select filters you can add to narrow the data.

Because dashboards re-run their queries on every load, changing a parameter always pulls current numbers rather than cached ones.

Live data, nothing cached

Dashboards store their definition, not their data. Each time a dashboard loads, its queries run again against your warehouse, and no result rows are cached. This keeps dashboards current and means your warehouse data stays in your warehouse.

Dashboards are visible to everyone in your workspace by default. You can also publish a read-only version to people outside the workspace via a public link.

See How to Share Dashboards for more details.

Lookout: How to Share Lookout Dashboards

Mon, 01 Jan 0001 00:00:00 +0000

Most work in Lookout stays inside your workspace and is visible only to its members. When you want to show something to people outside the team, you can publish a read-only public dashboard, protected by an unguessable link.

Every dashboard is visible to everyone in your workspace by default. Use the Share menu on a dashboard to confirm workspace visibility or to create a public link.

Public dashboards

A dashboard can be published to a public link that anyone can open without signing in. The public dashboard re-runs its queries on each load, so viewers always see current numbers.

Note that:

The link is protected by a secret share token.
The public view is read-only — viewers can’t edit the dashboard or act on your team’s behalf.

Publishing to a public link is gated by a workspace setting. An Admin can enable public sharing under Settings > General > Public sharing.

When the Allow public dashboard links setting is off, existing public links are unavailable until it is enabled again.

A public link means unauthenticated access

Anyone who holds a public dashboard link can view it — there is no per-viewer login, only the secret token in the URL. Because a public dashboard can expose warehouse query results, treat publishing as a deliberate decision and share the link accordingly.

Everything else in your workspace stays members-only.

See Roles and Permissions for more details on how guest and public access fit into the workspace model.

Lookout: Lookout Context Hub

Mon, 01 Jan 0001 00:00:00 +0000

The Context Hub is your workspace’s knowledge store. It holds what your team and the agent have learned, so the agent can pull it into later conversations for grounded answers and your team can find what was figured out earlier.

In the workspace sidebar, the Context Hub appears under Context.

What it holds

The Context Hub combines three kinds of items, all searchable together:

Generated documentation: AI-generated descriptions of how your sources and events are instrumented
Team notes: Knowledge your team shares manually
Memories: Facts the agent captures from conversations so it can remember them later

The Context Hub page has a keyword search box for finding an item by name or text. When the agent searches the hub during a conversation, it uses a richer hybrid search that combines keyword and meaning-based matching.

Generated instrumentation documentation

To understand what a codebase actually tracks, Lookout generates a structured document describing the RudderStack events and properties it finds in a linked repository. It clones the repository into an isolated sandbox, scans for analytics calls, and produces a document that lives in the Context Hub alongside your notes and the agent’s memories.

This documentation is generated from your source control, not from chat. It is produced when:

You select Generate Context or regenerate an existing document in the Context Hub.
A push lands on the default branch of a linked GitHub repository that has documentation enabled. Lookout refreshes the affected docs automatically.

Automatic push-triggered refresh applies to GitHub only.

For GitLab-linked sources, regenerate the documentation manually from the Context Hub. In chat, the agent can read these generated docs to ground its answers, but it doesn’t generate them.

Notes and memory

Notes are written by your team and are a good place to capture conventions, definitions, and context you want the agent to use.
Memories are captured by the agent during conversations. You control whether the agent captures memory with the memory capture setting, and captured memories appear in the Context Hub where you can review them.

Skills (slash commands)

A team note can be promoted to a skill — a reusable instruction set the agent follows for a particular task. To use one, type / in the chat composer and pick the skill; its instructions are added to your prompt before the agent runs.

Skills are a good way to standardize a repeated task — a recurring analysis, a documentation format, or a review checklist — so anyone on the team gets a consistent result.

Admin controls

A workspace Admin can control what knowledge the agent can use and save, from the controls at the top of the Context Hub, for example, whether the agent draws on team notes and memories, whether it uses generated context, and whether it captures new memories from chat.

All members can see these controls. However, only admins can change them.

See Chat and Ask Questions for more details on how the agent draws on this context during a conversation.

Lookout: How to Create Measurement Plans

Mon, 01 Jan 0001 00:00:00 +0000

A measurement plan captures what your team wants to track and carries it through a reviewed lifecycle — from a draft definition to instrumentation code proposed as pull requests. It is how you go from “we should be tracking this” to a concrete, reviewable change without writing the instrumentation by hand.

In the workspace sidebar, measurement plans appear under Plans.

Create a plan

Draft the plan: From chat, describe the tracking you want — the events and properties that should be captured. The agent saves and refines this as a measurement plan.

From chat, the agent can only save, update, and manage a plan — it can’t implement it.

Review and approve: A person reviews the plan and approves it. Nothing is implemented until this human-gated step.
Generate the pull requests: Approval alone doesn’t start implementation — a person clicks Generate PRs and confirms. This action launches the instrumentation agent and moves the plan to the implementation state.
The instrumentation agent opens pull requests: Once started, a background agent works each repository linked to the plan, writes the code changes, and opens a pull request for each one.
Review and merge: The pull requests sit in your normal code-review process. You can review and merge them like any other change.

The plan lifecycle

A measurement plan moves through clear states so you always know where it stands:

State	Meaning
Draft	The plan is being defined and refined
Approved	A person has approved the plan. It is ready to implement, but the instrumentation agent doesn’t start until someone selects Generate PRs
Implementing	Generate PRs has been triggered — the background agent is generating code and opening pull requests
Implemented	The pull requests have been opened
Partial failure	The agent implemented some repositories but couldn’t complete others
Verified	A person has marked the plan as verified after reviewing the merged pull requests. This is a manual step — merging a pull request doesn’t move the plan to verified on its own

Why it is split this way

The agent proposes, a human approves, and a background worker implements. This process keeps a person in the loop before any code reaches a repository.

From chat, the agent can only save and manage a plan — it can’t set one running.
Turning an approved plan into real code is a separate, human-gated step. Someone must explicitly select Generate PRs to start the instrumentation agent.
Every change lands as a pull request you review and merge, not a commit pushed straight to your main branch.

How Lookout finds the right repository

A measurement plan needs a connected GitHub repository for the instrumentation agent to open pull requests against, and a source-to-repository mapping so Lookout knows which repository to use.

GitLab repositories are not supported currently for measurement plan PR generation.

To open a pull request, Lookout needs to know which repository instruments a given source. That comes from your source-to-repository mappings — each RudderStack source is mapped to the GitHub or GitLab repository (and subfolder) where its events are instrumented.

When you ask to capture a new event, Lookout identifies the source the event belongs to, looks up the repository mapped to it, and targets the instrumentation pull request at the right codebase — without you having to specify where the code lives.

Lookout: How Lookout Manages PR and MR Reviews

Mon, 01 Jan 0001 00:00:00 +0000

Lookout can automatically review incoming pull requests (GitHub) and merge requests (GitLab) for changes that would break your data contract — so a problem is caught in code review rather than discovered later in the warehouse.

How it works

When a pull or merge request is opened or updated in a connected repository, a review agent inspects the diff for changes that would break the data contract, like:

Renamed or removed events
Altered property types
Dropped fields

It posts its findings back as review comments on the pull or merge request, right where your team is already reviewing the change.

Why it helps

Instrumentation drift is usually invisible until the data is already wrong — a renamed event or a dropped property quietly breaks a dashboard or a downstream sync days later. Reviewing the diff at code-review time moves that catch to the earliest possible point, where the change is still easy to fix.

Setup requirements

An automated review depends on three requirements being in place:

A connected repository: Install the GitHub App so Lookout receives pull-request events, or connect your GitLab instance so it receives merge-request events. See GitHub and GitLab for details.
A source-to-repository mapping: The repository must be mapped to the RudderStack source it instruments, so Lookout knows which data contract to check. See Sources for more information.
Auto PR review enabled: The per-source Auto PR review toggle (under Settings > Sources) must be on. An admin can turn it off for a source to stop reviews.

When these requirements are in place, review happens automatically on incoming pull and merge requests — no per-request action is needed.

RudderStack Docs – How to Work with Rudder Lookout

Lookout: How to Chat and Ask Questions to Rudder Lookout

Ask a question

Results are durable

Beyond questions

Chat from Slack

Lookout: How to Build Dashboards with Rudder Lookout

Build a dashboard from chat

Panel types

Parameters and filters

Live data, nothing cached

Share a dashboard

Lookout: How to Share Lookout Dashboards

Share within your workspace

Public dashboards

Public sharing policy

Lookout: Lookout Context Hub

What it holds

Generated instrumentation documentation

Notes and memory

Skills (slash commands)

Admin controls

Lookout: How to Create Measurement Plans

Create a plan

The plan lifecycle

Why it is split this way

How Lookout finds the right repository

Lookout: How Lookout Manages PR and MR Reviews

How it works

Why it helps

Setup requirements