August 2026 Summaries

Inngest’s Python SDK is presented as a managed, event-driven alternative to Celery-style background-job systems for Python 3.10+ applications using FastAPI, Flask, Django, Tornado, and DigitalOcean Functions. It enables developers to define sync or async durable functions triggered by events or cron schedules, with automatic retries, step-level checkpointing and memoization, long delays without occupied threads, waits for external events, parallel execution, and configurable concurrency, rate limits, and debouncing without operating Redis, a broker, or separate workers. The article demonstrates integrating an HTTP handler into existing web applications, sending events from synchronous or asynchronous code, using a local development server and visual run explorer, and deploying through ordinary HTTPS-based application hosting, including serverless platforms. It compares Inngest favorably with Celery and ARQ for workflow durability, observability, event waiting, and infrastructure simplicity, while acknowledging dependence on Inngest’s managed cloud platform, with enterprise self-hosting available. Suggested applications include ecommerce automations, webhook handling, AI pipelines, scheduled work, and incremental migrations from Celery; the SDK also supports Pydantic, typed code, direct testing of core logic, recovery after redeployments, and payload-size limits that encourage storing large data externally.

Inngest’s approach to AI agent evaluations frames evals as individual, targeted measurements of behavior or outcomes, such as user satisfaction, instruction following, tool use, structured-output validity, cost, or completion of an intended action. The article recommends starting with a narrow metric, often using live user feedback such as thumbs-up or thumbs-down scores, and using deferred scoring to connect later events like approvals, ticket closures, or repeat questions back to the original agent run. Inngest supports online evaluations on production traffic and offline evaluations against fixed datasets, with online methods positioned as an accessible starting point and offline testing becoming more valuable for regression checks as systems mature. Scores can be viewed alongside execution data and AI metadata in the Inngest dashboard, while experiments can split traffic between models, prompts, retrieval configurations, or other changes to identify which option produces better outcomes. The article also distinguishes operational observability, including latency, token usage, and model activity, from evaluations of whether an agent’s results were effective, arguing that both are necessary for improvement.

Inngest’s rerun-from-step feature lets developers manually restart a completed workflow at a chosen step, preserving memoized outputs from earlier steps while re-executing only the selected step and those that follow. Unlike automatic retries, which occur after failures during an active run, this capability can be triggered after successful or failed runs through the dashboard, CLI, or REST API and can use edited step inputs. The feature is presented as especially useful for AI workflow development, where prompt tuning often requires repeated experimentation and full reruns unnecessarily repeat prior model calls. In an example involving three sequential model calls, rerunning only the final reply-generation step across ten iterations reduces illustrative costs from $15 to $6. Avoiding full reruns can also prevent duplicate external side effects such as emails or charges, conserve rate-limited API capacity, and eliminate delays caused by earlier wait steps. By managing state at the step level, the approach aims to make iterative workflow testing safer, faster, and less expensive without requiring extensive custom idempotency or bookkeeping logic.