Skip to content

Connect ComplyCube to AI Agents: Power Global KYC and AML Workflows

Learn how to connect ComplyCube to AI agents using Truto's dynamic tool layer. Build autonomous KYC, AML, and identity verification workflows safely.

Riya Sethi Riya Sethi · · 9 min read
Connect ComplyCube to AI Agents: Power Global KYC and AML Workflows

You want to connect ComplyCube to an AI agent so your internal systems can independently execute Know Your Customer (KYC) checks, orchestrate document verification, and manage Anti-Money Laundering (AML) risk profiles based on real-time data. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to manually build and maintain rigid API wrappers for complex identity workflows.

Giving a Large Language Model (LLM) read and write access to your ComplyCube instance is an engineering headache. You either spend weeks building, hosting, and maintaining a custom connector that understands the nuances of multi-step document uploads and strict immutability rules, or you use a managed infrastructure layer that handles the boilerplate for you. If your team uses ChatGPT, check out our guide on connecting ComplyCube to ChatGPT, or if you are building on Anthropic's models, read our guide on connecting ComplyCube 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 ComplyCube, bind them natively to an LLM using LangChain (or any framework like LangGraph, CrewAI, or Vercel AI SDK), and execute complex compliance operations. 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 ComplyCube Connectors

Building AI agents is easy. Connecting them to external SaaS APIs safely is hard. Giving an LLM access to external compliance data sounds simple in a prototype. You write a Node.js function that makes a fetch request and wrap it in an @tool decorator. In production, this approach collapses entirely, especially with an ecosystem as highly regulated and strictly structured as ComplyCube.

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

Multi-Step Orchestration Traps

ComplyCube is fundamentally designed to prevent fraudulent data entry, which means its API requires sequential orchestration. An agent cannot simply fire a single payload to a /run-kyc-check endpoint. It must first create a Client entity. Then, it must create a Document entity linked to that client. Following that, it must upload images (front and back) to that document entity, strictly adhering to size constraints (34 KB to 4 MB) and allowed formats (JPG, PNG, PDF). Only after these prerequisites are met can the agent execute a Check.

When LLMs interact directly with raw REST APIs, they routinely hallucinate monolithic endpoints. They will attempt to POST base64 image strings directly into the client creation payload, causing hard failures. You have to write massive system prompts to teach the LLM the exact sequence of dependencies.

Immutability and State Management

Compliance systems enforce strict audit trails. In ComplyCube, once a live photo or video is used to perform a liveness check, it cannot be deleted via the API. Standard CRUD assumptions fail here. If an agent tries to clean up temporary test data by calling a generic DELETE method on a used asset, the API will reject it. Instead, the agent must be taught the distinction between deleting an unused asset and calling the specific Redact endpoints for used assets to satisfy data privacy requirements (like GDPR) without breaking the immutable audit log.

Managing Strict Rate Limits in Agent Loops

Identity verification involves heavy, asynchronous background processing. Consequently, APIs in this space are fiercely rate-limited to protect compute resources. When an autonomous agent hits a loop—perhaps iterating through a queue of 50 new user signups—it will rapidly exhaust ComplyCube's rate limits.

A critical architectural note: Truto does not retry, throttle, or apply backoff on rate limit errors. When ComplyCube returns an HTTP 429 Too Many Requests error, Truto passes that error directly back to the caller. Truto normalizes the upstream rate limit information into standardized IETF headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). The LLM caller (your agent loop) is entirely responsible for reading these headers, pausing execution, and applying exponential backoff. For developers managing high-volume pipelines, understanding how to handle API rate limits and webhooks from dozens of integrations is essential. Do not assume the integration layer will magically absorb rate limit violations for you.

Why a Unified Tool Layer Matters for Compliance Agents

Direct API tools (one custom-coded tool per raw ComplyCube endpoint) push provider quirks into the LLM's context window. Every quirk is a hallucination waiting to happen.

Truto solves this by abstracting the underlying integration into Resources and Methods. These Methods map to Proxy APIs that handle the underlying authentication, pagination, and parameter processing. Truto then translates these Proxy APIs into a predefined JSON schema exposed via the /integrated-account/<id>/tools endpoint.

By routing your agent through a unified tool layer, your agent sees strictly typed tools like create_a_comply_cube_client and comply_cube_documents_upload_image with deterministic JSON schemas.

This provides three concrete safety wins:

  1. Smaller attack surface. The LLM only ever chooses from stable function names. Invalid arguments are rejected by the strict JSON schema validation before they ever hit ComplyCube.
  2. Documentation-driven context. Truto automatically feeds the parameter descriptions directly into the agent's context, leveraging LLM function calling for integrations to teach it exactly what inputs are required (e.g., "personDetails is required when type is person").
  3. Framework Agnosticism. Because the tools are fetched dynamically at runtime via a standardized API, they work natively with LangChain, LangGraph, CrewAI, Vercel AI SDK, or custom-built control loops.

Connecting ComplyCube Tools to Your Agent

Let's look at exactly how to fetch ComplyCube tools and bind them to an agent using the Truto LangChain.js SDK.

First, you establish a connection to a specific integrated account. When a user authenticates their ComplyCube workspace through Truto, you receive an integrated-account-id.

import { ChatOpenAI } from "@langchain/openai";
import { TrutoToolManager } from "truto-langchainjs-toolset";
import { AgentExecutor, createToolCallingAgent } from "langchain/agents";
import { ChatPromptTemplate } from "@langchain/core/prompts";
 
// 1. Initialize the Truto Tool Manager with the specific ComplyCube account ID
const toolManager = new TrutoToolManager({
  trutoToken: process.env.TRUTO_API_KEY,
  integratedAccountId: "complycube-account-id-123",
});
 
// 2. Fetch the tools dynamically
const tools = await toolManager.getTools();
 
// 3. Initialize your LLM
const llm = new ChatOpenAI({
  modelName: "gpt-4o",
  temperature: 0,
});
 
// 4. Create the prompt instruction
const prompt = ChatPromptTemplate.fromMessages([
  ["system", "You are a compliance operations agent managing KYC and AML workflows in ComplyCube. Adhere strictly to the required tool sequences for document uploads and checks."],
  ["placeholder", "{chat_history}"],
  ["human", "{input}"],
  ["placeholder", "{agent_scratchpad}"],
]);
 
// 5. Bind tools to the agent
const agent = createToolCallingAgent({
  llm,
  tools,
  prompt,
});
 
const agentExecutor = new AgentExecutor({
  agent,
  tools,
  maxIterations: 10,
});

You now have an agent fully equipped with ComplyCube capabilities. Next, we will examine the high-leverage tools available for the agent to use.

ComplyCube AI Agent Tools

Truto automatically exposes dozens of ComplyCube endpoints as ready-to-use tools. Below are the hero tools essential for building autonomous KYC and AML workflows.

create_a_comply_cube_client

Creates a new entity (person or company) in ComplyCube. This is the foundational prerequisite step for any subsequent identity verification action. The agent knows that if type is set to person, it must provide personDetails.

"We have a new customer onboarding: Jane Doe, email jane@example.com. Create a new person client in ComplyCube and return the generated Client ID."

create_a_comply_cube_document

Creates the metadata shell for a document (e.g., passport, driving license) linked to a specific Client ID. This does not upload the image, but readies the system to receive attachments.

"Create a new passport document record for client ID 5f8a... issued by the United Kingdom."

comply_cube_documents_upload_image

Attaches binary image data to the previously created document shell. The agent understands constraints based on the tool schema, such as specifying whether the image is the front or back of the document, and handling file sizes between 34 KB and 4 MB.

"Upload the front side of the driver's license image to document ID 6b9c... The file is named license_front.jpg."

create_a_comply_cube_check

Executes a compliance check against a specific Client ID. The agent can trigger different types of checks depending on the context, such as standard document verification or extensive AML screening.

"Run an extensive screening check on client ID 5f8a... to verify them against global watchlists and PEP databases."

comply_cube_clients_get_risk_profile

Retrieves the calculated risk profile for a ComplyCube client, providing the agent with signals to either auto-approve, flag for manual review, or outright reject an onboarding application.

"Fetch the current AML risk profile for client ID 5f8a... If their political exposure risk is HIGH, escalate this to the compliance team in Slack."

comply_cube_checks_redact

Redacts selected attributes and images from a ComplyCube Document Check. This is crucial for privacy workflows where the agent must destroy PII after a successful verification, without deleting the immutable audit trail of the check itself.

"The user requested account deletion under GDPR. Go to ComplyCube and redact all images associated with document check ID 8e2d..."

For the full list of available ComplyCube operations, schemas, and required parameters, visit the ComplyCube integration page.

Building Multi-Step Workflows

To build resilient AI agents, your framework must gracefully handle the realities of network transit, specifically HTTP 429 Rate Limits. Because Truto acts as a transparent proxy for rate limit errors, you must architect your agent's execution loop to interpret these errors and back off accordingly.

Here is how an agent architecture interacts with Truto and ComplyCube during a standard execution loop.

sequenceDiagram
    participant Agent as AI Agent Loop
    participant Truto as Truto Proxy Layer
    participant CC as ComplyCube API

    Agent->>Truto: call tool: create_a_comply_cube_client
    Truto->>CC: POST /clients
    CC-->>Truto: 201 Created (clientId)
    Truto-->>Agent: JSON Schema Response
    Agent->>Truto: call tool: create_a_comply_cube_check
    Truto->>CC: POST /checks
    alt Rate Limit Exceeded
        CC-->>Truto: HTTP 429 Too Many Requests
        Truto-->>Agent: HTTP 429 (with ratelimit-reset header)
        note over Agent: Agent suspends execution<br>Applies exponential backoff
        Agent->>Truto: retry tool: create_a_comply_cube_check
        Truto->>CC: POST /checks
        CC-->>Truto: 201 Created (checkId)
        Truto-->>Agent: JSON Schema Response
    end

When writing your LangChain or LangGraph node execution logic, inspect tool call responses for status 429. If detected, parse the ratelimit-reset header returned by Truto, pause the agent's thread for the specified duration, and re-invoke the exact same tool payload.

Workflows in Action

Once connected, your agent can execute complex compliance ops completely autonomously. Here are two concrete examples of how this looks in production.

Scenario 1: Automated KYC Onboarding Pipeline

When a new high-value user signs up, the system triggers the agent to orchestrate the entire identity verification pipeline.

"A new user (John Smith, john.smith@example.com) just uploaded their UK passport. Orchestrate their KYC flow in ComplyCube. First, create their client record. Then, create a passport document. Next, attach the provided base64 image data to the front of the document. Finally, initiate a standard document check and report the status back to me."

Agent Execution Trace:

  1. The agent calls create_a_comply_cube_client passing the person details.
  2. Using the returned id, it calls create_a_comply_cube_document setting type to passport and issuingCountry to GBR.
  3. It calls comply_cube_documents_upload_image using the document ID and the image payload.
  4. It finishes by calling create_a_comply_cube_check specifying a document_check type.
  5. The agent synthesizes the response, outputting: "Client created and passport check initiated. Current check status is 'pending'."

Scenario 2: Data Subject Access Request (DSAR) Redaction

When your privacy team receives a GDPR right-to-be-forgotten request, an agent can securely scrub PII without destroying the immutable compliance log.

"User ID 99342 has requested full account deletion. Locate their client ID in ComplyCube, redact all document images associated with their completed checks, and redact any live photos. Do not attempt to delete the checks themselves."

Agent Execution Trace:

  1. The agent searches internal databases to map User ID 99342 to the ComplyCube Client ID.
  2. It calls list_all_comply_cube_checks for that Client ID to retrieve check histories.
  3. Iterating through the results, it calls comply_cube_checks_redact on each applicable document_check ID.
  4. It calls list_all_comply_cube_live_photos, looping through the results and calling comply_cube_live_photos_redact.
  5. The agent outputs: "All PII images and live photos have been successfully redacted for the client. The base check audit logs remain intact for regulatory review."

Moving Fast Without Breaking Compliance

Integrating AI agents with ComplyCube requires extreme precision. Hardcoding REST wrappers leaves you vulnerable to schema drift and prompts injection. By leveraging Truto's /tools API, you give your agents a strict, type-safe interface for managing KYC and AML operations.

Stop writing boilerplate HTTP fetch requests. Start building autonomous compliance engines.

FAQ

Does Truto automatically handle ComplyCube rate limits for my AI agent?
No. Truto does not retry, throttle, or apply backoff. When ComplyCube returns an HTTP 429, Truto passes that error to your agent, alongside IETF standard rate limit headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset). Your agent loop is responsible for handling the backoff strategy.
Can I delete a ComplyCube live photo using an AI agent once a check is completed?
No. ComplyCube enforces strict immutability for compliance audit trails. Once a live photo or video is used to perform a check, it cannot be deleted. You must instruct your agent to use the redact tool instead to obscure PII.
Do I have to use LangChain to connect ComplyCube tools?
No. While this guide uses LangChain.js as an example, Truto's /tools endpoint returns standard JSON schemas that can be bound to any framework, including LangGraph, CrewAI, Vercel AI SDK, or custom-built LLM control loops.

More from our Blog