Connect DoiT to AI Agents: Automate CloudFlows and FinOps

You want to connect DoiT to an AI agent so your internal engineering and FinOps teams can independently analyze cloud spend, trigger CloudFlows, investigate anomaly reports, and manage support tickets based on historical context. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to maintain complex API wrappers for DoiT's unique Cloud Analytics data models.

Giving a Large Language Model (LLM) read and write access to your DoiT instance is an engineering challenge. You either spend weeks building, hosting, and maintaining a custom connector that understands the nuances of cloud cost allocation and Server-Sent Events (SSE) streaming, or you use a managed infrastructure layer that handles the boilerplate for you. If your team uses ChatGPT, check out our guide on connecting DoiT to ChatGPT, or if you are building on Anthropic's models, read our guide on connecting DoiT 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 DoiT, bind them natively to an LLM using LangChain (or any framework like LangGraph, CrewAI, or Vercel AI SDK), and execute complex FinOps workflows. For a deeper look at the architecture behind this approach, refer to our research on architecting AI agents and the SaaS integration bottleneck.

The Engineering Reality of Custom DoiT Connectors

Building AI agents is straightforward. Connecting them to external SaaS APIs that manage critical cloud infrastructure and billing is hard. Giving an LLM access to external FinOps data sounds simple in a prototype, but in production, this approach collapses entirely when facing the realities of the DoiT API.

If you decide to build a point-to-point DoiT integration yourself, you own the entire API lifecycle. DoiT's API introduces several highly specific integration challenges that break standard LLM assumptions.

The Cloud Analytics Payload Complexity

Unlike a standard CRM where retrieving a contact yields a flat JSON object, DoiT's Cloud Analytics endpoints return deeply nested, dynamically projected configurations. When an agent requests a Cloud Analytics report, the response payload contains complex config objects, varying dimensions, attributions, and content-type-specific attributes. If you pass this raw schema to an LLM, the model wastes massive amounts of context window parsing FinOps metadata it does not need. Worse, when writing data back - like updating an alert or a budget - the LLM frequently hallucinates the required nested JSON structure, causing HTTP 400 Bad Request errors.

Handling Anomaly Reporting and Attribution Arrays

FinOps automation relies heavily on reacting to cost anomalies. The DoiT anomalies API returns records containing arrays of attribution, billingAccount, costOfAnomaly, and platform structures. Teaching an LLM to accurately filter these anomalies by severity or start time requires complex prompt engineering. If the integration layer does not strictly validate the LLM's query parameters before making the HTTP request, the agent will frequently construct invalid time-range queries that the upstream API rejects.

Event-Driven FinOps and SSE Streaming

DoiT features advanced endpoints like the Ava assistant API (/ava/ask) and CloudFlow refinement endpoints that stream responses via Server-Sent Events (SSE). Standard REST fetch implementations in basic agent frameworks block or fail when encountering SSE streams. You have to build custom transport layers to capture the incremental build events, buffer them, and feed them back to the agent in a consumable format.

Why a Unified Tool Layer Matters for Agent Safety

Before writing a line of integration code, decide what layer your agent talks to. This choice determines how safe your production system will be.

Direct API tools (one tool per raw DoiT endpoint) look convenient, but they push provider quirks directly into the LLM's context. The model has to remember that DoiT requires specific UUID formats, that CloudFlow triggers require a strictly formatted JSON payload corresponding to the specific node, and that rate limits might interrupt a critical data extraction loop. Every one of those quirks is a hallucination waiting to happen.

Using Truto's /tools endpoint collapses the DoiT API behind a unified tool layer. Your agent sees simple, deterministic function names. This provides three concrete safety wins:

1. Smaller attack surface for hallucination. The LLM only ever chooses from stable function names with explicitly defined parameters. It never invents undocumented FinOps query parameters.
2. Deterministic input validation. Every tool has a strict JSON schema. Invalid arguments are rejected before they hit the DoiT servers, so a broken tool call fails fast instead of generating silent errors.
3. Standardized rate limit handling. Factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors automatically. When an upstream API returns an HTTP 429, Truto passes that error to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. This means your agent infrastructure only needs to write one retry/backoff logic handler for HTTP 429s across all integrated platforms, rather than maintaining custom backoff logic for every distinct API.

DoiT Hero Tools for AI Agents

When building an AI agent for FinOps and cloud management, you do not need to expose every endpoint. You need high-leverage operations. Here are the core DoiT tools you should bind to your agent.

List Detected Anomalies

This tool (list_all_doi_t_anomalies) retrieves cost anomaly records, including attribution, billing accounts, platform, severity level, and the financial impact. It is the starting point for any automated FinOps triage workflow.

"Check our DoiT account for any high-severity AWS cost anomalies that occurred in the last 48 hours. Summarize the affected billing accounts and the total cost of the anomaly."

Get Cloud Analytics Report

This tool (get_single_doi_t_analytics_report_by_id) pulls the exact configuration and results of a specific Cloud Analytics report. It is essential for pulling historical spend data into the LLM's context.

"Fetch the weekly GCP spend report (ID: rep_8x9a2b) and analyze the cost trends. Are there any unexpected spikes in Cloud SQL usage?"

Trigger a CloudFlow

This tool (create_a_doi_t_cloudflow_trigger) executes a published DoiT CloudFlow via a webhook trigger node. This allows the agent to take autonomous action, such as pausing non-critical staging environments when budgets are exceeded.

"The staging cluster cost anomaly has been verified. Trigger the 'Pause Staging Workloads' CloudFlow (Trigger ID: trg_55m2p) and pass the cluster ID in the payload."

List Support Tickets

This tool (list_all_doi_t_support_tickets) retrieves ongoing support tickets across platforms. Agents use this to check if an infrastructure issue or billing dispute is already being handled by DoiT engineering.

"Before escalating this AWS billing anomaly, check our active DoiT support tickets to see if the FinOps team has already opened a case regarding the S3 transfer costs."

Get Billing Invoice Details

This tool (get_single_doi_t_billing_invoice_by_id) fetches the full line-item details of a specific invoice, including status, total amount, balance, and currency.

"Pull invoice INV-2025-04-102. What is the current balance amount, and what are the top three line items by cost?"

Update Cloud Analytics Budget

This tool (update_a_doi_t_analytics_budget_by_id) modifies an existing budget definition. An agent can use this to dynamically adjust alerting thresholds based on projected spend changes.

"Increase the amount of the Q3 Marketing AWS budget (ID: bud_9k2m1) by 15% to accommodate the new campaign traffic, and save the changes."

For the complete inventory of available DoiT tools and their exact JSON schemas, review the DoiT integration page.

Building Multi-Step Workflows

Connecting DoiT to an agent framework requires fetching the dynamic tool schemas from Truto and binding them to the LLM. This approach works natively across LangChain, LangGraph, CrewAI, and the Vercel AI SDK.

Because Truto dynamically generates these tools based on the active resources for a specific integrated account, your agent automatically inherits any custom fields or specific configurations present in that customer's DoiT environment.

Fetching and Binding Tools

Using the @trutohq/truto-langchainjs-toolset SDK, you initialize the TrutoToolManager, pass the Integrated Account ID, and retrieve the tools.

import { ChatOpenAI } from "@langchain/openai";
import { TrutoToolManager } from "@trutohq/truto-langchainjs-toolset";
import { HumanMessage } from "@langchain/core/messages";
 
async function runFinOpsAgent() {
  // 1. Initialize the LLM
  const llm = new ChatOpenAI({
    modelName: "gpt-4o",
    temperature: 0,
  });
 
  // 2. Initialize the Truto Tool Manager with your DoiT integrated account ID
  const toolManager = new TrutoToolManager({
    integratedAccountId: process.env.DOIT_INTEGRATED_ACCOUNT_ID,
    trutoApiKey: process.env.TRUTO_API_KEY,
  });
 
  // 3. Fetch all DoiT tools dynamically
  const tools = await toolManager.getTools();
  
  // 4. Bind the DoiT tools to the LLM
  const llmWithTools = llm.bindTools(tools);
 
  console.log(`Successfully bound ${tools.length} DoiT tools to the agent.`);
 
  // 5. Execute an autonomous query
  const response = await llmWithTools.invoke([
    new HumanMessage("Find any severe cost anomalies from the last week and summarize the affected platforms.")
  ]);
 
  // The agent returns a tool_calls array requesting 'list_all_doi_t_anomalies'
  console.log(response.tool_calls);
}
 
runFinOpsAgent();

Handling Rate Limits and Execution Errors

When building a production-grade agent loop, you must handle API rate limits gracefully. As noted, Truto passes HTTP 429 Too Many Requests errors directly to the caller, alongside standardized ratelimit-reset headers. The agent executor loop must catch these errors and apply backoff logic.

// Example of a robust execution loop with HTTP 429 handling
async function executeToolWithBackoff(tool, args, maxRetries = 3) {
  let attempt = 0;
  
  while (attempt < maxRetries) {
    try {
      // Execute the bound Truto tool
      const result = await tool.invoke(args);
      return result;
    } catch (error) {
      if (error.status === 429) {
        // Truto normalizes rate limit headers per IETF specs
        const resetTimeStr = error.headers['ratelimit-reset'];
        const resetSeconds = resetTimeStr ? parseInt(resetTimeStr, 10) : (2 ** attempt);
        
        console.warn(`Rate limited by upstream DoiT API. Retrying in ${resetSeconds} seconds...`);
        await new Promise(resolve => setTimeout(resolve, resetSeconds * 1000));
        attempt++;
      } else {
        // Unhandled API error (e.g., 400 Bad Request, 401 Unauthorized)
        throw new Error(`Tool execution failed: ${error.message}`);
      }
    }
  }
  throw new Error("Max retries exceeded for DoiT tool execution.");
}

Workflows in Action

When you give an LLM deterministic access to DoiT, you can automate workflows that usually require hours of cross-referencing dashboards and support portals. Here are two concrete examples of how FinOps administrators and DevOps teams use these tools.

1. The Autonomous FinOps Triage Agent

When a sudden spike in cloud spend occurs, DevOps engineers typically scramble to identify the resource, check if it is expected, and shut it down if it is a runaway process. An AI agent handles this autonomously.

"Review the latest cost anomalies. If you find a severe anomaly related to our 'staging-k8s' cluster, check our active support tickets to see if we already reported it. If there is no active ticket, trigger the 'Pause Staging Workloads' CloudFlow."

Step-by-Step Execution:

1. list_all_doi_t_anomalies: The agent queries the anomalies endpoint, filtering for high severity records in the past 24 hours. It identifies a $4,500 spike attributed to the staging Kubernetes cluster.
2. list_all_doi_t_support_tickets: The agent checks current open tickets to ensure a human hasn't already escalated this specific spike to DoiT support.
3. create_a_doi_t_cloudflow_trigger: Finding no active ticket, the agent formats a JSON payload containing the cluster ID and calls the webhook trigger for the CloudFlow designed to scale down the staging environment.

Outcome: The runaway cost is halted within minutes of the anomaly detection, without requiring human intervention outside of an automated Slack alert summarizing the agent's actions.

sequenceDiagram
    participant User as FinOps Admin
    participant Agent as AI Agent
    participant Truto as Truto Tool Manager
    participant DoiTAPI as DoiT API

    User->>Agent: "Check anomalies and pause staging if severe"
    Agent->>Truto: Call list_all_doi_t_anomalies()
    Truto->>DoiTAPI: GET /anomalies
    DoiTAPI-->>Truto: Return anomaly data (Staging spike detected)
    Truto-->>Agent: JSON context
    Agent->>Truto: Call list_all_doi_t_support_tickets()
    Truto->>DoiTAPI: GET /support/tickets
    DoiTAPI-->>Truto: Return empty list
    Truto-->>Agent: JSON context
    Agent->>Truto: Call create_a_doi_t_cloudflow_trigger(trigger_id, payload)
    Truto->>DoiTAPI: POST /cloudflows/trigger
    DoiTAPI-->>Truto: 200 OK (Flow started)
    Truto-->>Agent: Success confirmation
    Agent-->>User: "Anomaly detected. Staging workloads paused via CloudFlow."

2. Multi-Cloud Invoice Reconciliation

Accounting teams waste days at the end of the month reconciling AWS and GCP spend against active budgets and historical reports. An agent can pre-process this reconciliation.

"Fetch the latest DoiT billing invoice for this month. Cross-reference the total amount against our 'Q3 Cloud Ops' budget and the 'Monthly Global Spend' Cloud Analytics report. Give me a summary of any budget overruns."

Step-by-Step Execution:

1. list_all_doi_t_billing_invoices: The agent fetches the most recent invoice record to get the invoice ID.
2. get_single_doi_t_billing_invoice_by_id: The agent retrieves the full line items to isolate specific platform costs.
3. get_single_doi_t_analytics_budget_by_id: The agent pulls the definition and current status of the 'Q3 Cloud Ops' budget.
4. get_single_doi_t_analytics_report_by_id: The agent pulls the latest generated analytics report to compare granular service costs against the high-level invoice.

Outcome: The user receives a concise Markdown summary highlighting that while the total invoice is under the overall budget, the specific line item for GCP BigQuery has exceeded its allocated threshold in the analytics report.

Moving Beyond Manual Integration Maintenance

Giving AI agents access to complex infrastructure APIs like DoiT requires more than just generating API keys and writing fetch wrappers. The sheer complexity of nested FinOps schemas, SSE streaming endpoints, and multi-cloud attribution arrays creates an unacceptable attack surface for LLM hallucinations.

By leveraging Truto's /tools paradigm, you abstract away the API boilerplate. Your agent framework receives clean, deterministic JSON schemas and standardized rate limit headers, allowing your engineers to focus on building autonomous logic rather than untangling DoiT's reporting configurations.