Inngest Utah: Durable AI Agent Harness with Dynamic Skill Deployment

What changed

Inngest has introduced Utah, an open-source project designed as a "Universally Triggered Agent Harness." This project aims to provide a durable AI agent loop, inspired by concepts similar to OpenClaw, but built using Inngest for reliability and pi-ai for a unified LLM interface across providers like Anthropic, OpenAI, and Google. Utah is implemented in TypeScript and focuses on a core think/act/observe cycle where each LLM call and tool execution is treated as an Inngest step. This approach inherently provides automatic retries for LLM API timeouts and ensures singleton concurrency for conversations, preventing race conditions. A key feature is the "cancel on new message" functionality, which allows a new user message to cancel the current agent run and initiate a new one. Utah also supports multi-channel communication, including Slack and Telegram, through a simple channel interface. A significant architectural component is the "sidecar" process, which dynamically loads Inngest functions from disk and connects to Inngest Cloud via WebSocket. This allows the agent to author new Inngest functions—such as cron jobs, event handlers, or multi-step workflows—by simply writing a .ts file to a designated directory. The sidecar automatically hot-reloads these new functions without requiring a process restart or manual deployment. This enables the agent to build its own infrastructure and skills, persisting knowledge not only in conversation memory but also as executable code.

Why it matters for builders

Utah offers AI builders a powerful mechanism for creating agents that are not only conversational but also capable of persistent learning and self-evolution. The core innovation lies in the agent's ability to author and deploy its own durable Inngest functions. This means an agent can learn a new pattern or requirement and translate it into a new skill—a scheduled task, an event listener, or a complex workflow—that runs independently with Inngest's built-in retry and observability features. This capability transforms agents from static entities into dynamic systems that can expand their own operational capabilities over time. Furthermore, the agent can create "skills" as markdown reference documents, which are then injected into its system prompt, creating a self-referential loop where the agent can learn about its own functionalities and how to improve them.

Practical impact

AI builders can leverage Utah to develop sophisticated agents that manage complex, long-running processes or adapt to changing requirements autonomously. The project's architecture, which separates the core agent from the dynamically loaded sidecar functions, allows for modular development and easy extension. Builders can start by cloning the repository, installing dependencies, and configuring their LLM API keys and Inngest account credentials. The setup involves cloning the repository, running npm install, and updating the .env file with necessary API keys (e.g., Anthropic, Inngest Event Key, Inngest Signing Key). For local development, builders can use inngest-cli dev alongside npm run dev. The project supports multiple channels like Telegram and Slack, with specific setup guides available. Builders can experiment with the agent's ability to write new functions by modifying the workspace/functions/ directory and observing the sidecar's hot-reloading. This allows for rapid prototyping of new agent capabilities, such as automated daily digests, workspace commits, or review loops for generated code.

Caveats and source limits

The provided source material details the architecture and functionality of Utah but does not include specific benchmark results, pricing information for Inngest services beyond account creation, or definitive release dates beyond a published_at timestamp in the metadata. The project is presented as an example and harness, implying it is intended for developers to build upon. While it mentions support for multiple LLM providers via pi-ai, the exact performance characteristics or limitations when using different providers are not detailed. The source also focuses on the technical implementation and agent capabilities, with less emphasis on the user experience for end-users interacting with the agent through various channels. The GitHub repository metrics (stars, forks) are present but do not constitute performance benchmarks.