The Demo I Wish I'd Had: OpenAI's Agents SDK... serverless!

How do you deploy an agent-powered application that users can actually use, with resilient execution and as little infrastructure management as possible? That is the opening problem in Brook Riggio’s walkthrough of full-stack AI engineering in a serverless environment. Calling a model is only part of the application; the surrounding system must accept requests, coordinate work and deliver results.

The infrastructure falls into four layers, each with its own crowded field of choices:

This is a map of the choices confronting a developer, not a claim that every product in a row provides interchangeable capabilities. The practical difficulty comes from making the selected layers work together.

Choosing familiar tools does not automatically produce a reliable integration. Riggio describes repeatedly struggling to assemble this stack in production: generated code might almost work, while documentation for individual products still leaves the connections unclear. Understanding the boundaries between the layers is part of the engineering work, especially when reference implementations are scarce.

Riggio’s preferred combination begins with Next.js 15 for the application. Its built-in streaming, server actions, file-based and nested routing, and integration with Vercel provide the web-facing foundation. The OpenAI Agents SDK supplies agent behavior: native tool calling, multi-agent calls, tracing and evaluation hooks. OpenAI’s backing is part of his selection rationale, while the open-source SDK’s support for interchangeable models avoids tying every inference call to one provider.

Inngest takes responsibility for orchestration. Events trigger workflows defined in code, without requiring the developer to maintain JSON state-machine documents. On-demand execution avoids managing warm servers, automatic retries help handle failures, and step-level observability makes it possible to see which operation ran or failed. Its Vercel integration connects that orchestration layer to the chosen hosting environment.

Vercel completes the stack. Push-triggered preview deployments let teammates review a working application on a branch; merging to main then deploys the integrated changes. This makes deployment a routine part of development instead of a separate infrastructure exercise.

The surrounding services matter too: an edge network, CDN support and integrated options for Postgres, Redis and blob storage cover needs beyond inference. Vercel’s alignment with Next.js, together with application tooling such as next-forge, provides an ecosystem for the rest of the product. Riggio presents this as his preferred working combination, not a universal winner. Even with these pieces selected, developers still need enough integration knowledge to guide generated code toward a functioning application.

The architecture starts with a user connecting to Next.js. Before launching new work, the application can check storage: is the work already complete, or is a cached result available? If new work is needed, it sends an event to Inngest. The orchestrator then manages calls to Python serverless functions containing the agents.

Python is the implementation used throughout this demonstration. Riggio describes the Agents SDK as Python-only in the recording; that restriction is historical, since a TypeScript SDK is now available. Here, Vercel recognizes and hosts the Python functions, which call OpenAI for inference. Results return to the orchestration layer and can be persisted so the client can retrieve them. The web request initiates the work; stored output provides the route back to the interface.

The concrete application is a newsletter generator. It turns this architecture into a visible sequence: request material on a topic, let agents produce a newsletter, and make the finished result available to the user.

The Serverless Agent Architecture Starter provides the reference application and README. Its goals are serverless scalability, support for long-running agent workflows and usage-based costs without idle servers. Long-running workflow support comes from organizing the work into tasks; it does not remove the execution limit of an individual cloud function. Pydantic supports typing and validation on the Python side, while TypeScript serves the Next.js application.

Local development uses three processes, each in its own terminal:

1. Start the Python agents.
2. Start the Next.js application.
3. Start the Inngest development server.

The Inngest development environment supplies the local orchestration view. With all three running, the web interface can initiate work while the developer watches the workflow execute.

At localhost:3000, the application accepts a comma-separated list of topics and tries to generate a newsletter about their intersection. Riggio enters AI engineering and Seattle. Submitting the request opens a results page that polls the data store for an answer. Although he describes this as checking a database, the concrete store in this example is Vercel Blob.

While the page waits, the Inngest development interface exposes the work in progress. One agent call has completed and returned data; a second agent call follows, then the workflow saves output to Blob and finalizes the run. The interface makes the individual operations visible instead of presenting newsletter generation as one opaque request.

Each operation still has to fit within its cloud function’s configured execution duration. Riggio tentatively cites up to one minute on the free plan, with longer durations on paid plans. That is a talk-time estimate, not a current platform guarantee; Vercel’s duration limits have since changed. Breaking work into steps gives the overall workflow room to continue across bounded function executions.

When polling finds the stored output, the page renders the newsletter about Seattle and AI’s transformation of engineering. The demonstrated run reaches a formatted result, and the user can return to generate another newsletter. The connection between the asynchronous agents and the interface is now explicit: the agents finish their work, the workflow persists it, and the next successful read lets the page display it.

The code tour begins with the project layout. An Inngest endpoint served by the application connects the orchestration service to the workflow code and makes step-by-step execution observable. Newsletter API endpoints called by Inngest then invoke the Python agents in the top-level api directory. In the demonstrated layout, Vercel discovers files there and serves them as independent functions. Workflow definitions live in an Inngest folder under the source directory, with distinct events able to trigger different workflows.

FastAPI exposes separate endpoints for the research and formatting agents. Riggio then points to the entry-point line and directory structure that let Vercel detect the Python application automatically. The repository shown in the recording has no vercel.json, a detail he emphasizes after struggling with generated deployment configurations. The current companion repository includes that file and explicit Python routing, so the recording’s configuration-free layout should be read as the demonstrated version rather than instructions for today’s checkout.

The workflow definition keeps its high-level steps at the top, with helper implementations below. Each step calls a helper and checks the returned result, leaving the overall sequence easy to scan:

1. Call the research agent.
2. Pass the research to another agent to format the newsletter.
3. Save the formatted newsletter to Blob storage so the frontend can retrieve it.

This separates the orchestration—the order of operations and their dependencies—from the details of calling an endpoint or storing content.

Code outside step.run may execute more than once. Inngest can re-enter the workflow function to determine which step should run next. Initialization or other surrounding code must therefore not assume that it executes only once per newsletter request. This is particularly consequential for side effects: putting an operation beside the steps does not make it part of a durable step.

The demonstrated awaited step.run calls execute sequentially and return values that later steps consume. Research output is checked before it enters formatting; formatted output is checked before it is saved. Inngest’s durable execution model persists successful step results for reuse during re-entry, while failed steps can retry. That provides resumable sequencing, not a universal guarantee that external side effects happen exactly once.

The completed result appears in the Inngest dashboard, closing the loop from event to persisted newsletter. The entire application fits in a Next.js repository deployed to Vercel. Its responsibilities remain separate: serverless hosting supplies the execution environment, orchestration manages workflow progress and recovery, and the Agents SDK supplies the agent behavior. Riggio then shows the application running at a Vercel URL.

Deployment details provide a useful check that the mixed-language application was packaged as intended. In the initial deployment view, the API agents folder appears as a Python function, with Python 3.12 shown for this deployment. Full build logs are available for troubleshooting. The runtime display is evidence about the demonstrated deployment, rather than a requirement to assume for every subsequent checkout.

The final shell demonstration uses the Vercel CLI. It supports signing in, connecting the project, retrieving environment variables for local use and deploying the application. Riggio identifies two credentials to supply for this example: an OpenAI API key and a Vercel Blob storage token. These are not the whole deployed environment: the companion repository’s current setup also uses the Vercel Inngest integration to provision INNGEST_EVENT_KEY and INNGEST_SIGNING_KEY. With configuration in place, the shell demonstration starts the build process.

The newsletter is a reference implementation to adapt. Riggio closes by inviting developers to explore the open-source repository, contribute changes and replace its agents with their own workflows. The surrounding structure—application, event-driven orchestration, serverless agent endpoints and persisted results—can remain while the work performed by the agents changes. He asks builders to link their derived projects back so the repository can collect examples of what others build with the same foundation.