Connect Lattice to AI Agents: Automate Org Hierarchies and Updates

You want to connect Lattice to an AI agent so your system can autonomously map organizational reporting structures, parse continuous feedback, update OKR progress, and synthesize performance review data. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to build and maintain a custom Lattice integration from scratch.

Building an AI agent is fundamentally an exercise in state management and prompting. Giving that agent reliable, deterministic access to external HR and performance platforms is where projects stall. If your team uses ChatGPT, check out our guide on connecting Lattice to ChatGPT, or if you are building on Anthropic's models, read our guide to connecting Lattice to Claude. For developers building custom autonomous workflows, you need a programmatic way to fetch these tools and bind them to your agent framework.

This guide breaks down exactly how to fetch AI-ready tools for Lattice, bind them natively to an LLM using frameworks like LangChain, LangGraph, CrewAI, or the Vercel AI SDK, and execute complex People Operations workflows. For a broader look at this design pattern, read our guide on Architecting AI Agents: LangGraph, LangChain, and the SaaS Integration Bottleneck.

The Engineering Reality of the Lattice API

Giving an LLM access to external HR data sounds simple during a prototype phase. You write a standard Node.js function that makes a fetch request and wrap it in an @tool decorator. In production against complex Human Resources Information Systems (HRIS) and performance management platforms, this naive approach collapses.

The Lattice API introduces several specific integration challenges that break standard REST assumptions. If you hardcode these interactions into your agent, you will spend your sprints writing defensive integration code instead of improving your model's reasoning capabilities.

The Graph Traversal and Entity Resolution Problem

Lattice's data model is highly relational. An agent attempting to generate a summary of a user's performance cannot simply query a single /performance-summary endpoint. The data is scattered across a strict graph.

To understand a user's standing, an agent must resolve the user ID, fetch their direct reports, query active review cycles, resolve the specific reviewee record for that cycle, and finally pull the actual reviews and continuous feedback. If an LLM is given raw REST endpoints, it will inevitably hallucinate relationship IDs or attempt to pass an email address where a UUID is strictly required.

Opaque Object Structures and Untyped Attributes

Certain Lattice resources do not conform to strongly typed schemas in their standard responses. For example, when fetching tasks via the Lattice API, the system returns an unenumerated object exposing only the record's ID alongside an opaque attributes set.

Standard LLMs are trained to expect flat, predictable JSON objects. When an API returns untyped or highly dynamic payloads, the LLM struggles to parse the context, leading to hallucinations in subsequent function calls. You must provide the LLM with a strictly defined JSON schema for what it can write, and a normalized view of what it reads.

Custom Attribute Indirection

Organizations heavily customize Lattice to fit their specific org charts, job levels, and internal compensation bands. These customizations manifest as Custom Attributes.

In the Lattice API, custom attributes are not simply appended as standard JSON keys. They exist as standalone entities. To read or write a custom attribute, the agent must first query the custom attribute schema, resolve the correct attribute ID, and then map it to the custom attribute value object. Pushing this indirection into the LLM's context window consumes valuable tokens and drastically increases the error rate of the agent.

Why a Unified Tool Layer Matters for Agent Safety

Before writing a line of integration code, you must decide what layer your agent talks to. This choice determines the safety and reliability of your production system.

Direct API tools - exposing one tool per raw Lattice endpoint - look convenient initially, but they push all provider quirks directly into the LLM's context. The model has to remember exactly how Lattice handles pagination cursors, which endpoints require query parameters versus path parameters, and how to construct complex JSON payloads for goal updates.

Truto solves this by providing a unified tool layer. Every integration on Truto is essentially a comprehensive JSON object that represents how an underlying product's API behaves. Integrations have Resources that map to the endpoints on the underlying product's API, and Methods defined on those resources (List, Get, Create, Update, Delete).

Truto surfaces these as Proxy APIs, where Truto handles all authentication, pagination, and query parameter processing. We then expose the /integrated-account/:id/tools endpoint to return all of these Proxy APIs with their descriptions and strict JSON schemas, creating deterministic Tools that LLM frameworks can consume natively.

Handling Rate Limits with Agents

When autonomous agents are given access to data-dense APIs, they tend to move fast. It is critical to understand how your integration layer handles rate limiting.

Truto does not retry, throttle, or apply backoff on rate limit errors automatically. We believe the caller - your agent framework - must retain absolute control over execution states. When the upstream Lattice API returns an HTTP 429 Too Many Requests, Truto passes that exact error directly back to the caller.

However, tracking rate limits across dozens of different APIs is a nightmare. To solve this, Truto normalizes the upstream rate limit information into standardized headers across all integrations:

• ratelimit-limit: The total number of requests allowed in the current window.
• ratelimit-remaining: The number of requests left.
• ratelimit-reset: The time at which the rate limit window resets.

Your agent framework is responsible for reading these standardized headers and implementing the appropriate retry or backoff logic. This prevents your agent from entering infinite retry loops hidden behind an opaque integration layer.

Hero Tools for Lattice Workflows

Truto provides a comprehensive suite of tools for Lattice, covering everything from core directory data to performance review cycles. Here are the highest-leverage hero tools your agents will use to automate People Ops workflows.

list_all_lattice_users

This tool retrieves a paginated list of users in the Lattice instance. It returns core directory data including the user ID, email, name, title, status, and their manager's ID. This is the foundational tool agents use to resolve a human name to a Lattice system ID before executing downstream workflows.

"Find the Lattice user ID for Alice Chen in the engineering department and tell me who her direct manager is."

list_all_lattice_direct_reports

This tool accepts a user_id and returns a list of users who report directly to them. Agents use this to autonomously walk the organizational chart, calculate span of control, or recursively gather data for an entire department.

"Pull the profiles of everyone who reports directly to the VP of Sales and list their current job titles."

list_all_lattice_feedbacks

This tool retrieves all continuous feedback records in Lattice, ordered newest first. It surfaces the author, body, visibility status, and timestamps. Agents can ingest this data to synthesize team sentiment, summarize peer recognition, or prep a manager for a 1:1 meeting.

"Gather all public continuous feedback submitted for Marcus over the last 30 days and summarize the core themes."

get_single_lattice_goal_by_id

This tool fetches the complete state of a specific goal or OKR, returning the current amount, due date, owners, state, and tags. Agents use this to inspect the exact status of a high-priority corporate objective.

"Check the current progress amount for the Q3 Enterprise Expansion OKR and tell me if it is off track based on the due date."

create_a_lattice_goal_update

This tool allows an agent to autonomously post a progress update to an existing goal. It requires the goal ID, a comment, a status, and an increment value. This enables agents to bridge external systems - for example, reading a closed-won deal in Salesforce and automatically pushing a progress increment to a revenue goal in Lattice.

"Update the Q4 Revenue goal in Lattice. Increment the progress by $50,000, mark the status as 'on track', and add a comment that the Acme Corp deal just closed."

list_all_lattice_reviews

This tool retrieves all performance reviews for a specific reviewee. It returns the reviewer, the specific question asked, the review type, and the submission timestamp. Agents utilize this tool to generate holistic performance summaries or audit review completion rates.

"Pull the completed performance reviews for Sarah Jenkins from the most recent review cycle and summarize her manager's feedback."

To view the complete inventory of available Lattice tools and their precise JSON schemas, visit the Lattice integration page.

Workflows in Action

Exposing these tools to an LLM allows you to move beyond basic Chat UIs and build asynchronous, multi-step workflows. Here is how specific personas utilize these toolchains in production.

Scenario 1: Manager 1:1 Preparation Synthesis

A Director of Engineering needs to prepare for a 1:1 with a newly promoted Engineering Manager, but wants a holistic view of the manager's team sentiment and recent OKR progress.

"Prepare a 1:1 briefing doc for my meeting with David Smith. Find out who his direct reports are, summarize any continuous feedback they have received recently, and check the status of David's owned goals."

Execution Steps:

1. The agent calls list_all_lattice_users with a filter for "David Smith" to resolve his Lattice user ID.
2. The agent calls list_all_lattice_direct_reports using David's ID to fetch the IDs of his team members.
3. The agent loops through the direct report IDs, calling list_all_lattice_feedbacks to gather recent praise or constructive notes for the team.
4. The agent calls list_all_lattice_goals_user (a standard inventory tool) using David's ID to fetch his current OKRs.

Result: The user receives a synthesized briefing document highlighting that David's team is receiving strong peer feedback for their recent launch, but one of David's primary OKRs is marked as 'at risk', providing the Director with a highly targeted agenda for the 1:1.

Scenario 2: Autonomous OKR Auditing and Progressing

A Revenue Operations platform wants an agent to autonomously audit sales targets in Lattice based on raw data sitting in a data warehouse or CRM.

"Check the 'Q2 New Logo Acquisition' goal in Lattice. If the current amount is less than 15, update the goal by incrementing it by 1 and leave a comment that the GlobalTech account was successfully onboarded."

Execution Steps:

1. The agent calls get_single_lattice_goal_by_id to inspect the current state and currentAmount of the target goal.
2. The agent evaluates the logic internally (Current amount is 14, which is less than 15).
3. The agent calls create_a_lattice_goal_update passing the goal ID, a status of "on_track", an increment of 1, and the provided comment.

Result: The goal is updated accurately in Lattice without human intervention, maintaining strict data schema compliance through Truto's validation layer.

Building Multi-Step Workflows

To deploy these workflows, you need an architecture that handles the tool fetching, the LLM binding, and the execution loop.

Truto's architecture is framework-agnostic. You can use LangChain, LangGraph, CrewAI, or the Vercel AI SDK. The core mechanism remains the same: you fetch the tools from Truto's /tools endpoint, bind them to the LLM, and parse the tool calls.

Here is a conceptual architecture of how your agent framework interacts with Truto and Lattice:

sequenceDiagram
    participant App as Your Agent Framework
    participant Truto as Truto Unified API
    participant Lattice as Upstream API (Lattice)
    
    App->>Truto: GET /integrated-account/{id}/tools
    Truto-->>App: Returns JSON Schemas for Lattice Methods
    App->>App: Bind Tools to LLM (e.g. .bindTools())
    
    rect rgb(235, 232, 226)
    note right of App: Agent Execution Loop
    App->>App: LLM decides to call "list_all_lattice_users"
    App->>Truto: POST /integrated-account/{id}/tools/list_all_lattice_users
    Truto->>Lattice: Authenticated API Request
    Lattice-->>Truto: 200 OK (Raw Data)
    Truto-->>App: Normalized JSON Response
    App->>App: LLM parses response and plans next step
    end

Below is a TypeScript implementation using standard @langchain/core patterns. This code demonstrates how to fetch the tools dynamically, bind them, and critically, how to handle the standardized rate limit headers that Truto passes back from Lattice.

import { ChatOpenAI } from "@langchain/openai";
import { HumanMessage } from "@langchain/core/messages";
 
// 1. Define your Truto credentials and target account
const TRUTO_API_KEY = process.env.TRUTO_API_KEY;
const INTEGRATED_ACCOUNT_ID = "your_lattice_account_uuid";
 
async function executeLatticeWorkflow(prompt: string) {
  // 2. Fetch the deterministic tools for this Lattice account
  const toolsResponse = await fetch(
    `https://api.truto.one/integrated-account/${INTEGRATED_ACCOUNT_ID}/tools`,
    {
      headers: { Authorization: `Bearer ${TRUTO_API_KEY}` }
    }
  );
  const toolsSchema = await toolsResponse.json();
 
  // 3. Initialize the LLM and bind the tools
  const llm = new ChatOpenAI({ modelName: "gpt-4o", temperature: 0 });
  
  // Note: In production, you would use Truto's SDK to map these schemas 
  // directly into LangChain structured tools.
  const llmWithTools = llm.bindTools(toolsSchema.tools);
 
  let messages = [new HumanMessage(prompt)];
  
  // 4. Standard Agent Execution Loop
  while (true) {
    const aiMessage = await llmWithTools.invoke(messages);
    messages.push(aiMessage);
 
    // If the LLM decides no more tools are needed, break the loop
    if (!aiMessage.tool_calls || aiMessage.tool_calls.length === 0) {
      break;
    }
 
    // 5. Execute the requested tool calls against Truto
    for (const toolCall of aiMessage.tool_calls) {
      try {
        const result = await fetch(
          `https://api.truto.one/integrated-account/${INTEGRATED_ACCOUNT_ID}/tools/${toolCall.name}`,
          {
            method: "POST",
            headers: { 
                "Authorization": `Bearer ${TRUTO_API_KEY}`,
                "Content-Type": "application/json"
            },
            body: JSON.stringify(toolCall.args)
          }
        );
 
        // 6. Explicit Rate Limit Handling
        if (result.status === 429) {
            const resetTime = result.headers.get('ratelimit-reset');
            console.warn(`Rate limit hit. Resets at ${resetTime}. Initiating backoff...`);
            // Implement your framework's backoff/sleep logic here before retrying
            throw new Error("Lattice Rate Limit Exceeded");
        }
 
        if (!result.ok) {
            throw new Error(`Tool execution failed: ${result.statusText}`);
        }
 
        const data = await result.json();
        
        // Append the tool result back to the message history
        messages.push({
            role: "tool",
            tool_call_id: toolCall.id,
            name: toolCall.name,
            content: JSON.stringify(data)
        });
 
      } catch (error) {
        // Provide the error back to the LLM so it can attempt a correction
        messages.push({
            role: "tool",
            tool_call_id: toolCall.id,
            name: toolCall.name,
            content: `Error executing tool: ${error.message}`
        });
      }
    }
  }
 
  return messages[messages.length - 1].content;
}

Notice how the try/catch block explicitly checks for a 429 status code and extracts the ratelimit-reset header. Because Truto normalizes this header, this exact same error handling code will work whether your agent is talking to Lattice, Salesforce, or HubSpot. The integration layer handles the API quirks; your code handles the agent logic.

Moving Beyond Brittle Integrations

Giving AI agents access to enterprise HR and performance data requires more than a standard API wrapper. You need strict JSON schemas, predictable proxy routes, normalized rate limit headers, and a system that handles the underlying authentication lifecycle without manual intervention.

By leveraging Truto's /tools endpoint, you abstract away the graph complexities and opaque object structures of the Lattice API. Your engineering team can focus on refining agent prompts, optimizing workflows, and building better People Operations automation, rather than debugging cursor pagination and undocumented custom attributes.