Connect Looker to AI Agents: Automate LookML, schedules, and reports

You want to connect Looker to an AI agent so your system can autonomously run queries, provision user access, validate LookML projects, and schedule dashboards. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to build and maintain a custom integration from scratch.

Giving a Large Language Model (LLM) read and write access to your Business Intelligence (BI) stack is an engineering challenge. You either spend weeks building, hosting, and maintaining a custom connector that understands Looker's complex data modeling, or you use a managed infrastructure layer that handles the boilerplate for you.

If your team uses ChatGPT, check out our guide on connecting Looker to ChatGPT, or if you are building on Anthropic's models, read our guide on connecting Looker to Claude. For developers building custom autonomous workflows, this guide breaks down how to fetch AI-ready tools for Looker, bind them natively to an LLM using your preferred framework, and execute complex data workflows.

This approach works with any agent framework - LangChain, LangGraph, CrewAI, or Vercel AI SDK - and is not limited to MCP. We cover the architectural patterns for this in depth in our guide on architecting AI agents and the SaaS integration bottleneck.

The Engineering Reality of the Looker API

Building AI agents is straightforward in a sandbox. Connecting them to external enterprise SaaS APIs is where the architecture breaks down.

Giving an LLM access to external data seems simple on paper: you write a Node.js function that makes a fetch request and wrap it in an @tool decorator. In production, this approach collapses entirely. If you build a custom integration for Looker, you own the entire API lifecycle. Looker's API specifically introduces several unique integration challenges that break standard CRUD assumptions.

The Asynchronous Query Pattern

When a user asks an AI agent to "run the Q3 revenue report", the LLM cannot simply issue a single synchronous HTTP request and expect an immediate JSON response. Looker queries often hit massive cloud data warehouses (like Snowflake or BigQuery) and can take minutes to execute. Standard REST requests will time out.

Looker enforces an asynchronous query pattern for large operations. The caller must initiate the query (create_a_looker_async_query), receive a task ID, and then continuously poll the API (get_single_looker_async_query_by_id) until the status changes to complete. LLMs do not inherently understand polling loops. If you do not provide explicitly defined, separate tools for initiating and checking query status, the agent will hallucinate results or fail entirely.

LookML Metadata Abstraction

Unlike a raw SQL database where an LLM can query SELECT * FROM table, Looker relies on LookML - an abstraction layer defining models, explores, views, and dimensions.

An LLM cannot guess the arbitrary string identifiers your data team assigned to a specific dimension. To construct a valid query, the agent must first navigate the LookML schema. It has to fetch the model, identify the correct explore, and extract the exact dimension and measure names before it can execute an inline query. Exposing this complex, nested metadata structure to an LLM requires strict, dynamic JSON schemas.

Rate Limits and the IETF Standard

Looker enforces strict API rate limits to protect warehouse compute costs. If an AI agent enters a loop attempting to validate hundreds of LookML files or brute-force dimension names, the Looker API will throw an HTTP 429 Too Many Requests error.

It is a common misconception that integration platforms absorb these errors. Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Looker API returns an HTTP 429, Truto passes that error directly to the caller. We've detailed strategies for managing these constraints in our guide on best practices for handling API rate limits and retries across multiple third-party APIs. However, Truto solves the parsing problem: it normalizes upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. Your agent execution loop is responsible for reading these headers and initiating a sleep/retry mechanism.

Exposing Looker to AI Agents via Truto

Truto maps external SaaS APIs into a standardized REST-based CRUD API. Every integration in Truto represents the underlying product's API behavior as a comprehensive JSON object - acting as a unified API for LLM function calling optimized for integrations.

These integrations consist of Resources (e.g., Dashboards, Users, Queries) and Methods (List, Get, Create, Update, Delete, or custom methods like Run Query). Truto exposes these Methods as Proxy APIs, handling the authentication and query parameter processing automatically.

For AI workloads, Truto provides a dedicated /tools endpoint. By calling GET https://api.truto.one/integrated-account/<id>/tools, Truto dynamically generates and returns complete JSON schemas for all available Looker methods on the connected account.

Fetching and Binding Tools

Here is how you fetch these tools and bind them to an LLM using the TrutoToolManager from our LangChain.js SDK.

import { ChatOpenAI } from "@langchain/openai";
import { TrutoToolManager } from "truto-langchainjs-toolset";
 
async function initializeLookerAgent(trutoAccessToken: string, integratedAccountId: string) {
  // 1. Initialize the Truto Tool Manager for the specific Looker connection
  const toolManager = new TrutoToolManager({
    accessToken: trutoAccessToken,
    integratedAccountId: integratedAccountId,
  });
 
  // 2. Fetch the dynamically generated tools from Truto
  const lookerTools = await toolManager.getTools();
 
  // 3. Initialize your LLM
  const llm = new ChatOpenAI({
    modelName: "gpt-4o",
    temperature: 0,
  });
 
  // 4. Bind the tools natively to the model
  const modelWithTools = llm.bindTools(lookerTools);
 
  return { modelWithTools, lookerTools };
}

Because the definitions update automatically when changes occur in the Truto integration UI, your agent always has the correct schemas to interact with Looker.

Hero Tools for Looker AI Agents

To build highly capable BI agents, you need tools that go beyond basic record fetching. Here are the highest-leverage tools exposed by Truto for orchestrating Looker.

looker_query_run_inline

This tool allows the agent to execute an ad-hoc query instantly. It requires a JSON body defining the model, view, fields, filters, sorts, and limit. It is perfect for rapid data extraction when the agent already knows the LookML dimensions.

"Pull a JSON report of the top 10 users by session count over the last 7 days from the 'web_analytics' model and 'events' view."

create_a_looker_async_query

For complex reporting, synchronous requests will time out. This tool allows the agent to initiate an asynchronous task to run a previously created query in the background. It returns a query task ID that the agent must track.

"Start a background query for the end-of-year financial reconciliation report. Give me the task ID so I can check on it later."

looker_projects_validate

This tool triggers a validation check on all LookML files within a specified project. It returns a list of errors including the file path, line number, and severity. This is essential for AI agents tasked with acting as DevOps assistants or code reviewers for your data engineering team.

"Run a validation check on the 'marketing_attribution' LookML project and summarize any syntax errors or broken joins."

create_a_looker_scheduled_plan

AI agents can be used to set up recurring reporting. This tool enables the agent to configure a scheduled plan, specifying a dashboard or query, a crontab schedule, and delivery destinations (like email or a webhook).

"Schedule the 'Daily Executive Summary' dashboard to be emailed to the leadership team every weekday at 8:00 AM EST."

update_a_looker_user_role_by_id

IT teams frequently waste time manually provisioning BI access. This tool allows the agent to programmatically set or modify the roles assigned to a Looker user, directly tying into automated onboarding workflows.

"The new analyst, Sarah, just joined the team. Update her Looker account to include the 'Data Science' and 'Explore Only' roles."

create_a_looker_dashboard_render_task

Agents aren't limited to just extracting raw data. This tool commands Looker to generate an image or PDF rendering of a specific dashboard, which the agent can then extract and pass along to external communication tools.

"Generate a PDF render of the 'Server Uptime Metrics' dashboard so I can attach it to the incident post-mortem."

For the complete inventory of available Looker operations - including board management, alert configurations, and artifact storage - check out the Looker integration page.

Workflows in Action

When you combine these tools within an execution loop, you unlock sophisticated, autonomous BI workflows. Here are three concrete scenarios showing exactly how an AI agent uses these tools in production.

Scenario 1: Asynchronous Financial Reporting

Financial queries are notoriously slow. A user interacting with a Slack bot needs the agent to handle the waiting period gracefully without crashing.

"Run the Q3 revenue reconciliation query. It usually takes a few minutes, so wait for it to finish and then summarize the total revenue by region."

1. create_a_looker_async_query: The agent initiates the query execution, receiving a query_task_id in response.
2. get_single_looker_async_query_by_id: The agent enters a loop, periodically calling this tool to check the status.
3. get_single_looker_async_query_by_id (success): Once the status reads complete, the agent parses the payload.
4. Agent Logic: The agent calculates the summary metrics from the JSON array and formats a readable response for the user.

Scenario 2: DevOps LookML Code Review

Data engineers frequently push broken LookML to production. An AI agent can act as an automated reviewer triggered by a GitHub PR.

"Validate the 'sales_analytics' LookML project. If there are errors, tell me exactly which file and line number to fix."

1. list_all_looker_projects: The agent queries the environment to find the exact internal project_id for 'sales_analytics'.
2. looker_projects_validate: The agent executes the validation sequence on the project ID.
3. Agent Logic: The tool returns an array of error objects. The agent filters out warnings, formats the critical errors by file_path and line_number, and instructs the developer on how to fix the broken table relationships.

Scenario 3: Automated IT Access Provisioning

Onboarding a new employee requires granting access across dozens of SaaS platforms. An agent can handle the Looker portion of this seamlessly.

"Provision BI access for john.doe@company.com. Give him the standard 'Viewer' role."

1. looker_users_search (Custom / List): The agent searches for the user by email to retrieve their user_id.
2. list_all_looker_roles: The agent retrieves all roles to find the internal role_id corresponding to the string 'Viewer'.
3. update_a_looker_user_role_by_id: The agent applies the specific role_id to the specific user_id, updating the system state.

Building Multi-Step Workflows

Executing these workflows requires a robust agent execution loop. Frameworks like LangGraph excel at this, allowing you to maintain state across multiple tool calls.

Crucially, your agent execution loop must handle infrastructure reality. If the agent asks for too much data, Looker will throw a 429 rate limit error. Truto exposes the exact reset time via standard IETF headers. Your application must intercept this failure, parse the ratelimit-reset header, pause execution, and retry the tool call.

Here is a conceptual example of a custom tool-calling loop handling rate limits safely:

import { ToolCall } from "@langchain/core/messages";
 
async function executeLookerToolSafe(toolCall: ToolCall, tools: any[]) {
  const tool = tools.find((t) => t.name === toolCall.name);
  
  if (!tool) throw new Error("Tool not found");
 
  let attempt = 0;
  const maxRetries = 3;
 
  while (attempt < maxRetries) {
    try {
      // Execute the Truto Proxy API call
      const result = await tool.invoke(toolCall.args);
      return result;
    } catch (error: any) {
      if (error.response && error.response.status === 429) {
        // Looker rate limited the request.
        // Read the IETF standard header exposed by Truto.
        const resetTimeHeader = error.response.headers.get('ratelimit-reset');
        
        if (resetTimeHeader) {
          const resetSeconds = parseInt(resetTimeHeader, 10);
          console.warn(`Rate limited. Sleeping for ${resetSeconds} seconds.`);
          
          // Suspend execution until the limit resets
          await new Promise(resolve => setTimeout(resolve, resetSeconds * 1000));
          attempt++;
          continue;
        }
      }
      // If it's not a 429, or we lack header info, bubble the error up to the agent
      throw error;
    }
  }
  
  throw new Error("Max retries exceeded for Looker API");
}

By normalizing the authentication layer, generating dynamic schemas, and standardizing error headers, Truto removes the infrastructure boilerplate from agent development. You can focus entirely on designing complex, multi-step BI workflows instead of maintaining custom OAuth handlers and LookML parsers.