Connect Inngest to AI Agents: Automate Function Calls & Signals

You want to connect Inngest to an AI agent so your internal systems can independently debug failed function runs, send signals to long-running workflows, evaluate step traces, and orchestrate event-driven architectures based on historical context. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to manually code dozens of endpoints or maintain complex API wrappers.

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

Building AI agents is easy. Connecting them to external developer platforms is hard. Giving an LLM access to external execution 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 complex as Inngest.

If you decide to build the integration yourself, you own the entire API lifecycle. Inngest's event-driven architecture introduces highly specific integration challenges that break standard LLM assumptions.

The Asynchronous State Trap

Inngest does not operate like a standard REST CRUD application. It is a durable execution engine. When an agent queries a function run, it does not get a simple HTTP 200 with a static payload. Runs can be paused, waiting for signals, sleeping, or executing complex step functions. The API returns deeply nested state objects containing execution histories and step outputs. If you hand-code this integration, you have to write complex prompts to teach the LLM exactly how to traverse a trace tree just to figure out why a single step failed. When the LLM inevitably hallucinates the JSON path, the agent loop crashes.

Event to Function Resolution

Inngest triggers functions based on events. If an AI agent wants to find out what happened when a user signed up, it cannot simply query GET /users/123. It needs to query the event payload, find the associated runs, and then query the specific run IDs across different environments and apps. Direct API tools push this orchestration burden onto the LLM context window. The model has to remember the precise correlation between event_id, app_id, and function_id.

Signaling and Complex Payloads

Sending a signal to resume a paused Inngest function requires exact schema matching. If an agent calls create_a_inngest_signal, it must format the payload precisely as the waiting step function expects. Standard REST API wrappers do not provide the LLM with enough schema context to formulate this payload correctly, leading to rejected signals and stalled production workflows.

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.

A unified tool layer collapses these operational quirks behind one stable schema. Your agent sees deterministic functions with strict JSON schemas. That gives you three concrete safety wins:

1. Smaller attack surface for hallucination. The LLM only ever chooses from stable function names. It never invents API paths or query parameters.
2. Deterministic input validation. Every tool has a strict JSON schema. Invalid arguments are rejected before they hit the Inngest API, so a broken tool call fails fast instead of creating phantom events.
3. Isolated authentication. Your agent framework never touches the raw Inngest environment keys. It uses a single token to talk to the unified tool layer, which proxies the request safely.

High-Leverage AI Tools for Inngest

The Truto /tools endpoint dynamically exposes Inngest proxy APIs as fully formatted LLM tools. Instead of building one tool per endpoint, you retrieve exactly what your agent needs at runtime.

Here are the highest-leverage tools available for orchestrating Inngest environments.

Get Single Inngest Run

Retrieves a single Inngest function run by ID. This returns the run summary including status, duration, queued time, trigger, and output. It is the primary tool for checking execution state.

"Look up the status of run ID 01HGRB... and tell me if it finished successfully or if it is currently waiting for a signal."

List All Inngest Run Traces

Gets the trace tree for a single Inngest function run. It returns the root span including step IDs, durations, inputs, outputs, and any child steps. This is critical for automated debugging.

"Fetch the run traces for 01HGRB... and analyze the outputs of the child steps. Identify which specific step threw the timeout error."

Create an Inngest Signal

Resumes an Inngest function awaiting a signal (via step.waitForSignal) by sending data to the waiting function run.

"The onboarding function run 01HGRB... is waiting for a manual approval signal. Send a signal with the name 'user.approved' and include the approver ID in the payload."

Create an Inngest Cancellation

Creates a bulk cancellation in Inngest, canceling all functions in a given time range matching an optional expression. This is essential for incident response when a bad event causes a runaway function loop.

"We deployed a bad configuration. Cancel all runs for the sync-billing function in the production app that started within the last 30 minutes."

List All Inngest Event Runs

Lists Inngest function runs triggered by a specific event ID. This allows an agent to trace a single user action (the event) to all downstream architectural side effects (the runs).

"Find all the function runs that were triggered by event ID evt_9876... and summarize their current completion statuses."

Create an Inngest Run Rerun

Reruns a function run in Inngest, creating a new run using the original run's triggering event data.

"The database was down, causing run 01HGRB... to fail. Rerun that specific execution now that the database is back online."

To view the complete inventory of available tools, required parameters, and strict JSON schemas, visit the Inngest integration page.

Workflows in Action

Providing an LLM with access to Inngest tools is only useful if it can chain them together to solve complex engineering problems. Here is how agents use these tools in real-world scenarios.

Scenario 1: Automated Incident Triage

Persona: Platform Engineer

When a critical background job fails, engineers spend valuable time looking up run IDs, expanding step traces, and correlating inputs. An agent can completely automate this triage process.

"A user reported their data export failed. The event ID is evt_445566. Find the failed run, analyze the step traces, and tell me exactly which step failed and what the input payload was."

Agent Execution Steps:

1. The agent calls list_all_inngest_event_runs using the provided event ID.
2. It parses the resulting JSON array, identifying the specific run ID that has a status of Failed.
3. The agent calls list_all_inngest_run_traces using that run ID.
4. It traverses the returned trace tree, locating the child step with the error status, and extracts the input and error objects.

Outcome: The engineer receives a concise summary of the exact variable that caused the failure, without ever logging into a dashboard.

Scenario 2: Autonomous Workflow Remediation

Persona: DevOps Admin

When downstream APIs go offline, dozens of function runs might fail or hang. Once the outage is resolved, an agent can identify and restart the affected workloads.

"Our Stripe webhook endpoint was down for the last hour. Find all failed runs for the process-payment-webhook function and rerun them."

Agent Execution Steps:

1. The agent calls list_all_inngest_app_functions to get the internal ID for the process-payment-webhook function.
2. (Assuming a paginated fetch) The agent retrieves recent failed runs associated with that function.
3. The agent iterates over the failed run IDs, calling create_a_inngest_run_rerun for each one.

Outcome: The agent autonomously recovers the system state, turning a manual click-ops task into a single natural language command.

Building Multi-Step Workflows

To build these multi-step workflows, you need to bind Truto's tools to an agent framework. The following approach works across LangChain, LangGraph, CrewAI, and the Vercel AI SDK.

Managing API Rate Limits

When operating agents at scale, rate limiting becomes a primary concern. Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API (like Inngest) returns an HTTP 429, Truto passes that error directly to the caller.

Truto does normalize the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (your agent execution loop) is strictly responsible for inspecting these headers, pausing execution, and applying exponential backoff.

sequenceDiagram
    participant Agent as AI Agent (LangChain)
    participant Truto as Truto Proxy
    participant Upstream as Inngest API

    Agent->>Truto: Call tool (create_a_inngest_run_rerun)
    Truto->>Upstream: Forward request
    Upstream-->>Truto: 429 Too Many Requests
    Truto-->>Agent: 429 Error (Normalized Headers)
    Note over Agent: Agent catches 429<br>Reads ratelimit-reset<br>Sleeps thread
    Agent->>Truto: Retry tool call
    Truto->>Upstream: Forward request
    Upstream-->>Truto: 200 OK
    Truto-->>Agent: Execution Result JSON

Implementation with LangChain

Using the truto-langchainjs-toolset SDK, fetching and binding these tools requires very little boilerplate. The SDK handles the API requests to Truto's /tools endpoint and maps the JSON schemas into compatible LangChain tool objects.

import { ChatOpenAI } from "@langchain/openai";
import { AgentExecutor, createToolCallingAgent } from "langchain/agents";
import { ChatPromptTemplate } from "@langchain/core/prompts";
import { TrutoToolManager } from "truto-langchainjs-toolset";
 
async function runInngestAgent() {
  // 1. Initialize the Truto Tool Manager with your tenant and token
  const trutoManager = new TrutoToolManager({
    trutoTenantId: process.env.TRUTO_TENANT_ID,
    trutoToken: process.env.TRUTO_TOKEN,
  });
 
  // 2. Fetch all available Inngest tools for a specific integrated account
  // This queries the GET /integrated-account/<id>/tools endpoint
  const inngestTools = await trutoManager.getTools(
    process.env.INNGEST_INTEGRATED_ACCOUNT_ID
  );
 
  // 3. Initialize the LLM
  const llm = new ChatOpenAI({
    modelName: "gpt-4o",
    temperature: 0,
  });
 
  // 4. Create the system prompt
  const prompt = ChatPromptTemplate.fromMessages([
    ["system", "You are a senior DevOps agent. You manage Inngest environments. When executing tools, if you receive a 429 error, inform the user you are backing off."],
    ["human", "{input}"],
    ["placeholder", "{agent_scratchpad}"],
  ]);
 
  // 5. Bind the tools to the agent
  const agent = createToolCallingAgent({
    llm,
    tools: inngestTools,
    prompt,
  });
 
  // 6. Execute the workflow
  const agentExecutor = new AgentExecutor({
    agent,
    tools: inngestTools,
    // Ensure the executor handles errors gracefully rather than crashing the loop
    handleParsingErrors: true,
  });
 
  const result = await agentExecutor.invoke({
    input: "Check the status of Inngest run 01HGRBXXXX. If it is paused waiting for a signal, send a signal named 'manual.continue' to resume it."
  });
 
  console.log(result.output);
}
 
runInngestAgent();

The Execution Flow

When you run the code above, the architecture handles several complex abstractions automatically.

flowchart TD
    A["User Prompt"] --> B["Agent Executor"]
    B -->|"Reasons about schema"| C["Selects get_single_inngest_run_by_id"]
    C --> D["Truto Proxy API"]
    D --> E["Inngest Upstream"]
    E -->|"Returns Run State JSON"| D
    D -->|"Validates output"| B
    B -->|"Sees status == Paused"| F["Selects create_a_inngest_signal"]
    F --> D
    D --> E
    E -->|"Returns 200 OK"| D
    D --> B
    B --> G["Final Response to User"]

The LLM does not need to know how to construct raw HTTP headers, how to handle base URLs, or how to authenticate with the Inngest API. It simply interacts with the strictly defined JSON schema provided by the Truto tools endpoint.

Moving Past Manual Integration Layers

Giving AI agents access to your underlying infrastructure platforms is a requirement for modern platform engineering. However, building and maintaining the connective tissue between an LLM framework and complex event-driven APIs is a massive engineering sink.

By leveraging a unified tool layer and dynamic proxy APIs, you decouple the agent's logic from the vendor's API specifics. Your models interact with a clean, standardized schema, your infrastructure stays secure behind proxy boundaries, and your engineering team avoids writing hundreds of lines of brittle integration code.