Inngest Agent Example
June 18, 2026 ยท View on GitHub
Universally Triggered Agent Harness
A durable AI agent built with Inngest and pi-ai. No framework. Just a think/act/observe loop โ Inngest provides durability, retries, and observability, while pi-ai provides a unified LLM interface across providers.
Simple TypeScript that gives you:
- ๐ Durable agent loop โ every LLM call and tool execution is an Inngest step
- ๐ Automatic retries โ LLM API timeouts are handled by Inngest, not your code
- ๐ Singleton concurrency โ one conversation at a time per chat, no race conditions
- โก Cancel on new message โ user sends again? Current run cancels, new one starts
- ๐ก Multi-channel โ Slack, Telegram, and more via a simple channel interface
- ๐ Local development โ runs on your machine via
connect(), no server needed
Architecture
Channel (e.g. Telegram) โ Inngest Cloud (webhook + transform) โ WebSocket โ Local Worker โ LLM (Anthropic/OpenAI/Google) โ Reply Event โ Channel API
The worker connects to Inngest Cloud via WebSocket. No public endpoint. No ngrok. No VPS. Messages flow through Inngest as events, and the agent processes them locally with full filesystem access.
Sidecar: Orchestration-Aware Agent Loops
The core agent handles conversations. But conversations are ephemeral โ the agent forgets, the process restarts, the context window rolls over. The sidecar is what makes Utah's output durable.
A separate process (utah-sidecar) dynamically loads Inngest functions from disk, connects to Inngest Cloud via WebSocket, and runs them independently. The agent can write a new .ts file to the functions directory and the sidecar hot-reloads it automatically โ no restart, no deploy, no human intervention.
The key idea: the agent doesn't just run inside loops โ it authors new loops and deploys them to the orchestration engine. Each deployed function is a durable skill that runs on its own schedule, with its own retry logic, completely independent of whether the agent is in a conversation.
โโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโ
โ Core Agent โ โ Sidecar โ
โ app: "ai-agent" โ โ app: "utah-sidecar" โ
โ โ โ โ
โ handleMessage โ โ workspace/functions/โ
โ sendReply โ โ *.ts (dynamic) โ
โ subAgent โ โ + heartbeat (auto) โ
โ etc. โ โ + file watcher โ
โโโโโโโโโโฌโโโโโโโโโโโโโ โโโโโโโโโโฌโโโโโโโโโโโโโโโ
โ โ
โ connect() via WebSocket โ
โโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโ
โ
โโโโโโโโโโผโโโโโโโโโ
โ Inngest Cloud โ
โ events, crons, โ
โ retries, state โ
โโโโโโโโโโโโโโโโโโโ
Both processes connect to Inngest independently. They share nothing except the event bus.
How it works
- The sidecar reads
workspace/functions/*.ts, dynamically imports each file, and registers the exported Inngest functions - A
fs.watch()monitors the directory โ on any change, a 2-second debounce fires, the existing WebSocket closes, functions are re-imported with cache-busting, and a new connection opens - A heartbeat function is auto-injected (runs every 30 minutes) so the sidecar always has at least one registered function
- No process restart needed โ the agent writes a file, the sidecar picks it up
The agent writes its own skills
The agent can author new Inngest functions โ cron jobs, event handlers, multi-step workflows โ by writing a .ts file to workspace/functions/. The sidecar deploys them automatically.
Some example functions that the main agent might write to extend itself: morning-triage, daily-meeting-digest, nightly-workspace-commit, weekly-review. You can also create "loops" with review functions that use LLMs to review and iterate on functions, for example: inbox-triage-review, cold-email-learner.
Each function is durable โ retried on failure, observable in the Inngest dashboard, independently scheduled. Skills compound. The agent builds infrastructure for itself.
Agent skills as persistent knowledge
Agent skills are markdown reference docs (with name/description frontmatter) that appear in the agent's system prompt. The agent can create its own skills to persist knowledge across conversations.
This creates a self-referential system:
- The Inngest Functions skill teaches the agent how to write sidecar functions (templates, triggers, step API, best practices)
- The Sidecar Management skill teaches file operations for managing the functions directory
- When the agent learns a new pattern, it can write a new skill and a new function โ persisting both the knowledge and the automation
The agent is ephemeral. Its output is durable.
Communication
Sidecar functions talk back to the main agent by sending agent.message.received events:
await step.sendEvent("alert-agent", {
name: "agent.message.received",
data: {
channel: "system",
sessionKey: "system-alerts",
message: "Alert: something needs attention",
},
});
This means a cron job can monitor something, detect a problem, and start a conversation with the agent โ which can then use its tools to investigate and respond. The loops feed each other.
Prerequisites
- Node.js 23+ (uses native TypeScript strip-types)
- LLM API key (e.g. Anthropic API key (console.anthropic.com))
- Inngest account (app.inngest.com)
- At least one channel configured (see Channels below)
Setup
1. Create an Inngest Account
- Sign up at app.inngest.com
- Go to Settings โ Keys and copy your:
- Event Key (for sending events)
- Signing Key (for authenticating your worker)
2. Configure and Run
git clone https://github.com/inngest/utah
cd utah
npm install # or pnpm
cp .env.example .env
Edit .env with your keys:
ANTHROPIC_API_KEY=sk-ant-...
INNGEST_EVENT_KEY=...
INNGEST_SIGNING_KEY=signkey-prod-...
Then add the environment variables for your channel(s) โ see setup guides below.
Start the worker:
# Production mode (connects to Inngest Cloud via WebSocket)
npm start
# Development mode (uses local Inngest dev server)
npx inngest-cli@latest dev &
npm run dev
On startup, the worker automatically sets up webhooks and transforms for each configured channel.
Channels
The agent supports multiple messaging channels. Each channel has its own setup guide:
- Telegram โ Fully automated setup. Just add your bot token and run.
- Slack โ Requires creating a Slack app and configuring Event Subscriptions.
Project Structure
src/
โโโ worker.ts # Entry point โ connect() or serve()
โโโ client.ts # Inngest client
โโโ config.ts # Configuration from env vars
โโโ agent-loop.ts # Core think โ act โ observe cycle
โโโ setup.ts # Channel setup orchestration
โโโ lib/
โ โโโ llm.ts # pi-ai wrapper (multi-provider: Anthropic, OpenAI, Google)
โ โโโ tools.ts # Tool definitions (TypeBox schemas) + execution
โ โโโ context.ts # System prompt builder with workspace file injection
โ โโโ session.ts # JSONL session persistence
โ โโโ memory.ts # File-based memory system (daily logs + distillation)
โ โโโ compaction.ts # LLM-powered conversation summarization
โโโ functions/
โ โโโ message.ts # Main agent function (singleton + cancelOn)
โ โโโ send-reply.ts # Channel-agnostic reply dispatch
โ โโโ acknowledge-message.ts # Message acknowledgment (typing indicator, etc.)
โ โโโ heartbeat.ts # Cron-based memory maintenance
โ โโโ failure-handler.ts # Global error handler with notifications
โโโ channels/
โโโ types.ts # ChannelHandler interface
โโโ index.ts # Channel registry
โโโ setup-helpers.ts # Inngest REST API helpers for webhook setup
โโโ <channel-name>/ # A channel implementation (see README for setup)
โโโ handler.ts # ChannelHandler implementation
โโโ api.ts # API client
โโโ setup.ts # Webhook setup automation
โโโ transform.ts # Webhook transform
โโโ format.ts # Formatting for channel messages
workspace/ # Agent workspace (persisted across runs)
โโโ SOUL.md # Agent personality and behavioral guidelines
โโโ USER.md # User information
โโโ MEMORY.md # Long-term memory (agent-writable)
โโโ memory/ # Daily logs (YYYY-MM-DD.md, auto-managed)
โโโ sessions/ # JSONL conversation files (gitignored)
How It Works
The Agent Loop
The core is a while loop where each iteration is an Inngest step:
- Think โ
step.run("think")calls the LLM via pi-ai'scomplete() - Act โ if the LLM wants tools, each tool runs as
step.run("tool-read") - Observe โ tool results are fed back into the conversation
- Repeat โ until the LLM responds with text (no tools) or max iterations
Inngest auto-indexes duplicate step IDs in loops (think:0, think:1, etc.), so you don't need to track iteration numbers in step names.
Event-Driven Composition
One incoming message triggers multiple independent functions:
| Function | Purpose | Config |
|---|---|---|
agent-handle-message | Run the agent loop | Singleton per chat, cancel on new message |
acknowledge-message | Show "typing..." immediately | No retries (best effort) |
send-reply | Format and send the response | 3 retries, channel dispatch |
agent-heartbeat | Distill daily logs into long-term memory | Cron (every 30 min) |
global-failure-handler | Catch errors, notify user | Triggered by inngest/function.failed |
Workspace Context Injection
The agent reads markdown files from the workspace directory and injects them into the system prompt:
| File | Purpose |
|---|---|
SOUL.md | Agent personality, behavioral guidelines, tone, boundaries |
USER.md | Info about the user (name, timezone, preferences) |
MEMORY.md | Curated long-term memory (agent-writable) |
Edit these files to customize your agent's personality and knowledge. The agent can also update MEMORY.md using the write tool to remember things across conversations.
Memory System
The agent has a two-tier memory system:
- Daily logs (
workspace/memory/YYYY-MM-DD.md) โ append-only notes written via theremembertool during conversations - Long-term memory (
workspace/MEMORY.md) โ curated summary distilled from daily logs by the heartbeat function
The agent-heartbeat function runs on a cron schedule (default: every 30 minutes). It checks if daily logs have accumulated enough content, then uses the LLM to distill them into MEMORY.md. Old daily logs are pruned after a configurable retention period (default: 30 days).
Conversation Compaction
Long conversations get summarized automatically so the agent doesn't lose context or hit token limits:
- Token estimation: Uses a chars/4 heuristic to estimate conversation size
- Threshold: Compaction triggers when estimated tokens exceed 80% of the configured max (150K)
- LLM summarization: Old messages are summarized into a structured checkpoint (goals, progress, decisions, next steps)
- Recent messages preserved: The most recent ~20K tokens of conversation are kept verbatim
- Persisted: The compacted session replaces the JSONL file, so it survives restarts
Compaction runs as an Inngest step (step.run("compact")), so it's durable and retryable.
Context Pruning
Long tool results bloat the conversation context and cause the LLM to lose focus. The agent uses two-tier pruning:
- Soft trim: Tool results over 4K chars get head+tail trimmed (first 1,500 + last 1,500 chars)
- Hard clear: When total old tool content exceeds 50K chars, old results are replaced entirely
- Budget warnings: System messages are injected when iterations are running low
Adding New Channels
The agent is channel-agnostic. Each channel implements a ChannelHandler interface (src/channels/types.ts) with methods for sending replies, acknowledging messages, and setup. Each channel directory follows the same structure:
src/channels/<name>/
โโโ handler.ts # ChannelHandler implementation (sendReply, acknowledge)
โโโ api.ts # API client for the channel's platform
โโโ setup.ts # Webhook setup automation
โโโ transform.ts # Plain JS transform for Inngest webhook
โโโ format.ts # Markdown โ channel-specific format conversion
To add Discord, WhatsApp, or any other channel:
- Create a new directory under
src/channels/following the structure above - Implement the
ChannelHandlerinterface inhandler.ts - Write a webhook transform that converts the channel's payload to
agent.message.received - Register the channel in
src/channels/index.ts
The agent loop, reply dispatch, and acknowledgment functions are all channel-agnostic โ no changes needed outside src/channels/.
Key Inngest Features Used
connect()โ WebSocket-based worker- Singleton execution โ one run per chat at a time
- Step retries โ automatic retry on LLM API failures
- Event-driven functions โ compose behavior from small focused functions
- Webhook transforms โ convert external payloads to typed events
- Checkpointing โ near-zero inter-step latency
Acknowledgments
This project uses pi-ai (@mariozechner/pi-ai) by Mario Zechner for its unified LLM interface and @mariozechner/pi-coding-agent for it's. standard tools. pi-ai provides a single complete() function that works across Anthropic, OpenAI, Google, and other providers โ making it easy to swap models without changing any agent code. It's a great library.
License
Apache-2.0