Brook Riggio combines Next.js, OpenAI's Agents SDK, Inngest, and Vercel to run long AI workflows on serverless infrastructure.
2
Inngest breaks the newsletter workflow into retryable steps, so each agent task can fit within a serverless function's time limit while preserving state between steps.
3
The demo shows a practical project structure, local development setup, deployment process, and observability path for a production AI app on Vercel.
Summary
Brook Riggio presents a serverless architecture for applications that use OpenAI's Agents SDK. His preferred stack uses Next.js for the client, Python functions for the Agents SDK, Inngest for event-driven orchestration, and Vercel for hosting. The central problem is that sizeable agent jobs do not fit cleanly into one serverless request. Inngest breaks the work into steps, retries failed steps, and records progress so the frontend can read completed results from storage. Riggio demonstrates the approach with a newsletter generator that researches topics, formats the result, and saves it to Vercel Blob. He also walks through the repository structure, three-terminal local setup, automatic Python function deployment, environment variables, and build logs. The talk is especially useful because it covers a subtle execution issue: code outside an Inngest step may run again when the workflow resumes, while code inside step.run is sequenced and tracked.
A useful serverless AI stack needs separate client, agent, orchestration, and hosting layers
Riggio frames the deployment problem as combining a client application, an agent framework, an orchestration layer, and a serverless cloud environment. He lists many choices across each layer, including Next.js, OpenAI's Agents SDK, Temporal, AWS Step Functions, Inngest, Lambda, Vertex, and Vercel. His concern is that there is little reference code showing how a particular combination works in production. After trying several combinations, he chooses Next.js with Vercel hosting, OpenAI's Agents SDK for agents, Inngest for orchestration, and Vercel for serverless deployment.
OpenAI's Agents SDK provides the agent features Riggio wants while allowing model changes
Riggio says he adopted OpenAI's Agents SDK when it was announced. He points to native tool calling, one-shot and multi-agent calls, built-in tracing, and evaluation hooks. Those features give the application visibility into agent behavior. He also values OpenAI's support for the SDK and the ability to interchange models, so using the framework does not force the entire application into one model ecosystem.
Inngest turns a long agent job into observable, event-triggered steps
Inngest is Riggio's orchestration choice because workflows start from events rather than manually managed state-machine documents. It runs work on demand, includes automatic retries, and exposes step-level observability. In the demo, the frontend triggers an event, Inngest coordinates Python functions that run the agents, and the completed result is written to storage. The frontend can then check the database or cache and display the result after the workflow finishes.
The demo uses Python functions for agents and Next.js for the surrounding application
The OpenAI Agents SDK is Python-only in the setup Riggio presents. Vercel detects Python functions and hosts them automatically. The Next.js app handles the user interface and checks whether work is already complete. The Python functions perform inference through OpenAI and return results to Inngest. In the newsletter example, one agent researches the requested topics and another formats the newsletter before the final content is saved for the frontend.
Breaking the newsletter workflow into steps keeps individual tasks inside serverless limits
Riggio demonstrates a newsletter generator that accepts a comma-separated list of topics. The example asks about AI engineering in Seattle, then starts a workflow that checks storage while the agent calls run. Inngest breaks the job into individual steps, allowing each step to use the available cloud-function runtime rather than forcing the whole job into one request. The result is saved to Vercel Blob and appears in the Next.js page as a formatted newsletter.
The repository structure makes the orchestration and deployment boundaries visible
The project places the Inngest endpoint and workflow definitions inside the Next.js repository. Newsletter API endpoints connect Inngest to the Python agents, which live in a top-level API directory. Vercel treats each file in that directory as an independent function. The agents use FastAPI, and a single line at the bottom of the app is enough for Vercel to start the function. Riggio notes that the repository does not need a vercel.json file for this arrangement.
Step boundaries matter because workflow code outside a step can run more than once
Riggio structures the workflow with each step declared clearly at the top and each step calling a function defined below. The example has three steps: call the research agent, format the newsletter with another agent, and save the output to Blob storage. He warns that code outside step.run can execute multiple times when Inngest returns to the workflow to determine which step should run. Code inside the steps runs in order and passes results to the next step.
Deployment needs only the project environment, an OpenAI key, and Vercel Blob storage credentials
Vercel displays the Python agent as a Python 3.12 function and provides build logs for troubleshooting. Riggio deploys from the terminal with the Vercel CLI, which can sign in, connect the project, and pull production environment variables for local use. For this example, the required secrets are an OpenAI API key and a Vercel Blob storage token. The repository is open source and intended to be adapted with other agent workflows.
"One thing to remember is that every step.run will be invoked in order, but code that's outside of step.run may well be executed multiple times."14:11
Who should watch
You are building an agent workflow on Vercel and need a way to handle jobs that exceed a single serverless request.
Your application needs retries, step-by-step visibility, and persistent results without running a dedicated always-on server.
You want a concrete repository structure for connecting a Next.js frontend, Python-based OpenAI agents, Inngest workflows, and Vercel deployment.
