Connect Kaseya BMS to AI Agents: Orchestrate RMM Alerts and Jobs

If your team uses ChatGPT, check out our guide on connecting Kaseya BMS to ChatGPT, or if you are building on Anthropic's models, read our guide on connecting Kaseya BMS to Claude. For developers building custom autonomous workflows into their own applications, you need a programmatic way to fetch native tools and bind them to an agent framework.

Kaseya BMS is the operational nervous system for thousands of Managed Service Providers (MSPs) and IT departments. It houses everything from billing and CRM data to real-time RMM (Remote Monitoring and Management) alerts and service desk tickets. When an IT alert fires, human engineers typically spend ten minutes cross-referencing asset IDs, looking up contract SLAs, and documenting the remediation steps before they even begin fixing the issue.

Agentic AI is perfectly suited for this domain. Large Language Models (LLMs) can parse dense infrastructure alerts, query the BMS service desk for historical context, and execute resolution workflows automatically. But giving an LLM read and write access to Kaseya BMS is an engineering headache. You either spend weeks building, hosting, and maintaining a custom integration layer, or you use managed infrastructure to handle the LLM function calling boilerplate.

This guide explains exactly how to use Truto's /tools endpoint and SDK, part of a unified API for AI agent tools, to generate AI-ready tools for Kaseya BMS, bind them natively to your LLM using frameworks like LangChain, and execute complex IT service management workflows autonomously.

The Engineering Reality of the Kaseya BMS API

Giving an LLM access to external IT data sounds simple in a prototype. You write a Node.js function that makes a fetch request to an endpoint, wrap it in an @tool decorator, and hand it to the agent. In production, this approach collapses under the weight of enterprise API constraints.

Kaseya BMS is a massive, multi-module ERP for IT. Its API reflects this complexity, introducing several specific integration challenges that break standard CRUD assumptions.

The Asynchronous RMM Job Queue

When standard APIs update a record, they return a 200 OK with the updated JSON payload. Kaseya BMS handles RMM operations entirely differently. Because RMM actions (like resolving a batch of alerts, duplicating tickets, or deactivating hardware assets) often trigger downstream scripts on physical endpoints, the API cannot return an immediate synchronous result.

Instead, when you call endpoints like the RMM ticket resolver, the API returns an integration job output object. The operation is placed in a queue. If you do not explicitly teach your AI agent to take that job_id, wait, and then call the list_all_kaseya_bms_tickets_status endpoint to verify the outcome, your agent will hallucinate that the task is complete when it might have failed in the queue. You must provide the agent with both the execution tool and the status-check tool to close the loop.

The Lookup ID Resolution Problem

LLMs operate in human language. They understand concepts like "Assign this ticket to the Network Team" or "Set priority to High". Kaseya BMS requires strictly typed integer IDs for almost every relational field. You cannot pass "High" as a priority; you must pass 3.

To make Kaseya BMS usable by an AI agent, you must expose the lookup endpoints - such as list_all_kaseya_bms_priorities_lookups or list_all_kaseya_bms_queues_lookups. Without these, the agent will guess IDs, resulting in persistent 400 Bad Request errors. A robust agent implementation requires the LLM to search the lookup table, map the string to the ID, and then construct the final POST request.

Strict Rate Limiting and the IETF Spec

Kaseya BMS enforces rate limits to prevent abusive polling. If your agent gets stuck in a loop trying to summarize 500 tickets, the upstream API will reject requests with an HTTP 429 Too Many Requests error.

Truto does not magically absorb or retry these rate limit errors. When the upstream Kaseya BMS API returns a 429, Truto passes that error directly to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) following the IETF specification. It is your responsibility as the developer to write the retry and exponential backoff logic in your agent's execution loop, reading the ratelimit-reset header to know exactly how many seconds to pause before allowing the LLM to continue.

Hero Tools for Kaseya BMS AI Agents

Instead of manually defining JSON schemas for hundreds of Kaseya BMS endpoints, Truto automatically exposes them as standard tools. Below are the highest-leverage tools for building autonomous IT workflows.

1. list_all_kaseya_bms_servicedesk_tickets

This is the core observation tool for any IT agent. It allows the LLM to query the service desk using specific filters like account, status, priority, and date ranges.

"Fetch all open service desk tickets assigned to the network queue that were created in the last 24 hours. Filter for Critical priority."

2. create_a_kaseya_bms_rmm_ticket

When a monitoring system detects an anomaly that Kaseya hasn't natively caught, or when an AI agent determines a cascading failure is occurring, this tool allows the agent to explicitly create an RMM-tracked ticket under a specific integration type.

"Create a new RMM ticket for the server failure on WIN-SVR-01. Set the integration type to our primary Datto instance and attach the memory dump logs to the description."

3. list_all_kaseya_bms_tickets_status

Because RMM actions are asynchronous, this tool is mandatory for workflow validation. The agent passes the job_id returned from a previous action to verify if the script executed successfully or if the ticket state actually changed.

"Check the job status for RMM ticket resolution job ID 89441. If it is still pending, wait. If it failed, retrieve the error log."

4. update_a_kaseya_bms_assets_deactivate_by_id

During employee offboarding or incident response to a compromised machine, isolating the endpoint is the first step. This tool deactivates one or more RMM assets for a given integration type.

"We have a confirmed malware alert on laptop L-902. Deactivate the asset immediately via the RMM endpoint to cut off its network access."

5. create_a_kaseya_bms_ticketresolution_generate

Writing detailed resolution notes is the bane of every IT engineer's existence. Kaseya BMS natively supports generating resolutions, and exposing this tool allows the AI agent to trigger the generation based on the ticket's audit logs and time entries.

"Ticket #4092 is ready to be closed. Generate a formal ticket resolution summarizing the troubleshooting steps and append it to the ticket."

6. create_a_kaseya_bms_todo

Complex tickets require checklists. This tool lets the LLM break down a vague user request (e.g., "Setup new hire") into concrete, trackable service call to-dos on the Kaseya BMS ticket.

"For the new hire onboarding ticket #5011, create three to-dos: 1) Provision Active Directory account, 2) Assign Microsoft 365 license, 3) Image and ship laptop."

7. create_a_kaseya_bms_action_notification

If an AI agent hits a roadblock or identifies a VIP user issue, it needs a way to escalate. This tool triggers an action notification to alert human technicians instantly.

"The CEO's email is not syncing. I cannot resolve this automatically. Trigger an action notification to the Tier 3 escalation team immediately."

To view the complete inventory of available Kaseya BMS endpoints, comprehensive JSON schemas, and query parameter definitions, visit the Kaseya BMS integration page.

Workflows in Action

Individual tools are useful, but chaining them together creates autonomous systems that replace manual IT triage. Here are three realistic ways AI agents use these tools in production.

Triage and Resolve Known RMM Alerts

MSPs are drowned in low-level alerts like "Disk space below 10%". An AI agent can handle these autonomously without human intervention.

"Check the RMM queue for disk space alerts. If the C: drive is full due to temp files, execute the cleanup protocol, verify the job, and close the ticket."

1. The agent calls list_all_kaseya_bms_servicedesk_tickets filtering for active RMM alerts containing "disk space".
2. It reviews the asset details attached to the ticket.
3. The agent triggers a remediation script (via a generic webhook or RMM integration).
4. The agent calls create_a_kaseya_bms_tickets_resolve to close the ticket in Kaseya BMS.
5. The agent calls list_all_kaseya_bms_tickets_status to ensure the resolution job cleared the queue successfully.

Automated Employee Offboarding

Offboarding requires meticulous asset tracking and access revocation. Missed steps lead to security breaches. Agents execute this flawlessly.

"Offboard John Doe. Deactivate his assigned laptop, close his pending IT requests, and notify the security team."

1. The agent calls list_all_kaseya_bms_hardwareasset_searchselects using John Doe's contact ID to find his assigned laptop.
2. It calls update_a_kaseya_bms_assets_deactivate_by_id to disable the machine.
3. It calls list_all_kaseya_bms_servicedesk_tickets to find any open tickets where John is the requester.
4. It loops through the results, calling create_a_kaseya_bms_todo to add a note that the user was offboarded, followed by create_a_kaseya_bms_resolve.
5. It calls create_a_kaseya_bms_action_notification to alert the SOC team that offboarding is complete.

VIP Ticket Escalation and Summarization

When a critical issue drags on for days, incoming engineers need a summary. The agent handles context gathering and escalation.

"Review ticket #9902 for the CFO. Read all the notes, generate a summary, and escalate to the Tier 3 queue."

1. The agent calls list_all_kaseya_bms_servicedesk_ticket_notes to ingest the history of the conversation.
2. The agent calls create_a_kaseya_bms_ticketsummary_generate to synthesize the notes into a cohesive summary.
3. The agent calls list_all_kaseya_bms_queues_lookups to find the exact ID for the "Tier 3 Escalation" queue.
4. The agent calls create_a_kaseya_bms_assignticket using the retrieved queue ID to move the ticket.

Building Multi-Step Workflows

To run these workflows in your application, you need to connect Truto's dynamically generated tools to your agent framework. The following example demonstrates how to fetch the Kaseya BMS tools, bind them to a LangChain agent, and implement a robust execution loop that explicitly handles HTTP 429 Rate Limit errors using Truto's standardized IETF headers.

Truto does not retry rate limit errors for you. If Kaseya BMS says "Too Many Requests", Truto passes that 429 response back to you. You must catch it and back off.

import { ChatOpenAI } from "@langchain/openai";
import { AgentExecutor, createOpenAIToolsAgent } from "langchain/agents";
import { TrutoToolManager } from "truto-langchainjs-toolset";
import { 
  ChatPromptTemplate, 
  MessagesPlaceholder 
} from "@langchain/core/prompts";
 
async function runKaseyaAgent(prompt: string) {
  // 1. Initialize the Truto Tool Manager with your API key
  const trutoManager = new TrutoToolManager({
    apiKey: process.env.TRUTO_API_KEY
  });
 
  // 2. Fetch all available tools for a specific Kaseya BMS integrated account
  const kaseyaTools = await trutoManager.getTools(
    process.env.KASEYA_INTEGRATED_ACCOUNT_ID
  );
 
  // 3. Initialize the LLM and bind the tools
  const llm = new ChatOpenAI({
    modelName: "gpt-4-turbo",
    temperature: 0,
  });
  
  const llmWithTools = llm.bindTools(kaseyaTools);
 
  // 4. Create the system prompt instructing the agent on API quirks
  const promptTemplate = ChatPromptTemplate.fromMessages([
    ["system", `You are an elite IT service desk AI agent. 
      Your job is to manage Kaseya BMS operations.
      IMPORTANT RULES:
      - When setting statuses, priorities, or queues, you MUST use the lookup tools first to find the correct integer ID. Do not guess IDs.
      - If you execute an RMM action, use the status tool to verify the job finished.
      - If you encounter an error, explain what failed.`],
    ["human", "{input}"],
    new MessagesPlaceholder("agent_scratchpad"),
  ]);
 
  const agent = await createOpenAIToolsAgent({
    llm: llmWithTools,
    tools: kaseyaTools,
    prompt: promptTemplate,
  });
 
  const agentExecutor = new AgentExecutor({
    agent,
    tools: kaseyaTools,
  });
 
  // 5. Execute with a robust Retry Loop handling 429 Rate Limits
  let attempts = 0;
  const maxAttempts = 5;
 
  while (attempts < maxAttempts) {
    try {
      const result = await agentExecutor.invoke({
        input: prompt,
      });
      console.log("Workflow Complete:", result.output);
      break; // Success, exit loop
 
    } catch (error: any) {
      // Check if the error is a 429 passed through by Truto
      if (error.status === 429 || error.message.includes("429")) {
        attempts++;
        
        // Extract the standardized IETF rate limit header passed by Truto
        // Fallback to 10 seconds if the header is missing or unparseable
        const resetTimeSecs = parseInt(error.headers?.['ratelimit-reset'] || "10", 10);
        
        console.warn(`[Rate Limit Hit] Kaseya BMS returned 429. Truto passed headers: limit=${error.headers?.['ratelimit-limit']}, remaining=${error.headers?.['ratelimit-remaining']}`);
        console.warn(`Waiting ${resetTimeSecs} seconds before retry ${attempts}/${maxAttempts}...`);
        
        await new Promise(resolve => setTimeout(resolve, resetTimeSecs * 1000));
      } else {
        // It's a different error (e.g., 400 Bad Request, 401 Unauthorized), fail immediately
        console.error("Agent execution failed with non-retryable error:", error);
        throw error;
      }
    }
  }
}
 
// Example execution
runKaseyaAgent(
  "Find ticket #1029. Lookup the ID for the 'Closed' status. Move the ticket to that status."
);

This architecture completely abstracts away the complexities of pagination and authentication logic, allowing your team to focus strictly on prompt engineering, agent orchestration, and business logic. The TrutoToolManager handles the transformation of Kaseya's OpenAPI specs into LLM-compatible JSON schema descriptions.

Wrapping Up

Building AI agents that reliably orchestrate IT workflows in Kaseya BMS requires more than just API keys. You have to handle asynchronous RMM job queues, map string concepts to integer IDs via lookup tables, and respect strict rate limits without losing state.

By leveraging Truto to generate these tools dynamically, you eliminate the need to write and maintain hundreds of lines of brittle JSON schemas and pagination handlers. Your AI agents gain immediate, structured access to Kaseya BMS, allowing them to triage alerts, resolve tickets, and offboard employees autonomously.