Browse · Writeups
Shipping agents means building the application around them
Durable workflows, streaming interfaces, operational context, and external security controls turn an agent loop into a usable application.
Source and teaching reviews passed · Human editorial review pending.
The workflow you already built
A queue tracks unfinished work. A database remembers its state. A cron job checks that nothing has become stuck. In the Ship AI conversation with Malte Ubl, published October 31, 2025, this arrangement introduces the problem workflows solve: transaction-processing systems need to track progress and keep work moving, whether through an explicit abstraction or an ad hoc equivalent. Ubl credits Temporal with productizing that category.
Vercel’s Workflow Development Kit makes workflows an everyday programming construct, with agents embedded inside programs that can persist progress, resume execution, and stream output. Ubl connects this design to Vercel’s broader method: build agents for customers and internal operations, then extract abstractions from the problems those applications expose.
Durable execution lets a program pause and resume—even across waits lasting days—while failed steps can retry automatically. Serverless code can therefore behave like a long-running program without executing continuously. Ubl says suspended waiting incurs no charge; active computation is a separate matter.
Human approval makes the mechanism concrete. A webhook is a URL another system can call to signal an event: 1. At an approval step, the workflow creates a temporary webhook URL, stores it in a database, and waits for it to be called. 2. An approval interface reads pending items from that database. 3. A user returns hours later and approves an item; the system calls its webhook. 4. The wait resolves and the workflow continues. The database supplies the human’s work queue. The webhook connects the decision to the suspended program.
Open source and durability as code
The host argues that valuable production workflows make ownership, auditability, and self-hosting consequential features of the open-source kit. The two disagree about how often customers will exercise that option: the host expects many to value it without using it; Ubl expects people to run the software themselves and welcomes that.
Portability fits Vercel’s commercial strategy. Ubl describes broadly usable libraries and deployment adapters as a way to grow adoption, with Vercel monetizing a share of the resulting market. In his account, that proportional share stays relatively constant as the market expands, so use outside Vercel can still enlarge the opportunity.
The companion article describes use workflow as the annotation that makes a TypeScript function durable, adding persisted progress, automatic retries, and observability. In the conversation, Ubl finds this directive syntax elegant but expresses no strong general preference for it. Decorators could express similar behavior, and broader decorator support could let TypeScript understand workflow annotations without Vercel’s existing plugin.
Model autonomy and application integration
AI SDK, Vercel’s software development kit for AI applications, already let developers build agents by combining streaming text generation with tools in a loop. Version 5 added controls for preparing each step and choosing the tools available on each iteration. AI SDK 6 beta introduced a direct agent abstraction, moving a feature described as experimental in version 5 toward stable use. It packages patterns developers had repeatedly assembled themselves.
The rationale for starting low level is that AI application patterns are still emerging. A framework that controls execution and asks developers to fill predefined slots risks committing to the wrong structure. AI SDK’s builders credit their restraint with accommodating the move from chatbots to agents without rewriting the SDK.
The host challenges this rationale, suggesting that framework builders favor composable primitives while model labs favor model-controlled reasoning and tool calls. The response separates model autonomy from application integration: a model can choose the next action inside an agent loop while the SDK helps embed that loop in an application. The responding speaker supports model-controlled execution and says their own agents use it.
Streaming—delivering output incrementally—illustrates the application problem. A response that takes 30 seconds makes incremental delivery much more useful than one that takes a few milliseconds. That is an illustrative contrast, not a benchmark. AI SDK’s value here is making streaming applications easier to build, alongside whatever authority the model has over its tools.
A small API surface also has to accommodate enterprise users who need explicit controls and configurable defaults. Using the framework in real applications helps expose which controls matter. v0, Vercel’s application-building tool, supplies the example: AI SDK was extracted from it, the two diverged, and substantial work later brought v0 back onto the SDK. That migration exposed difficulties the team could address for other users.
This internal use is presented as a founding Vercel principle: test abstractions in applications before offering them to users. The host points out why it is difficult to sustain—framework bugs and maintenance can consume the time needed to build those applications.
Investigate the alert before waking the human
Vercel Agent is a hosted agent product, distinct from Vercel’s custom internal agents. Its proposed advantage is the platform’s existing application context: runtime data, error logs, preview deployments, development-server setup, and configured secrets. These integrations reduce the onboarding work needed to make an agent useful in an unfamiliar project.
Vercel had shipped a code-review agent and recently announced a DevOps agent that investigates production anomalies. It can construct and execute queries against operational data, inspect logs, and show the graphs it examined. Vercel describes explanations often being ready when a user opens an anomaly, saving minutes of investigation; these are product-experience claims without a measured success rate.
The larger proposal changes the recall–precision tradeoff in alerting: catching more incidents tends to produce more false alarms, while reducing false alarms can miss real incidents. A newsletter sent by a team in Asia, for example, might create a benign traffic spike that wakes someone elsewhere overnight.
An agent could make aggressive detection more tolerable by investigating before anyone is paged. The proposal allows roughly two minutes to inspect time series, request IP addresses, and error messages, then decide whether the incident warrants immediate escalation or can wait until the next day.
A participant who has not tried the product questions both the reliability of language models on time series and how an agent would learn someone’s escalation preferences. The architectural answer is that anomaly detection runs outside the large language model (LLM). A separate pipeline operates over Vercel’s time-series database; the agent investigates detected anomalies with query tools and follows up in textual logs. How it should learn escalation preferences remains unresolved, especially when the next incident differs from the last.
The agent’s scope was a small part of site reliability engineering (SRE). Increased-error-rate investigations were described as effective; autonomous firewall changes and Domain Name System (DNS) migrations were considered too risky at that stage. The DevOps agent also lacked source-code access. Adding it to interpret errors and sometimes open a fixing pull request was a future plan.
Find repetitive work that still needs judgment
For internal agents, the project-selection rule is to ask employees which parts of their jobs they most dislike. The target is tedious work with small textual judgments: repetitive enough to consume substantial time, but still requiring interpretation. Vercel presented three internal agents and open-sourced two as starting points for adaptation.
The examples involve different judgments and limits on authority: - Lead qualification: use LinkedIn and Google tools with qualification criteria to process contact-sales requests, including recognizing messages that should go to support. - Abuse review: gather the reported website, account age, and billing history before a human opens the ticket. Flagging a page that resembles a Facebook login is a judgment the human can check; the human retains the final decision. - Data analysis: answer warehouse questions using structured documentation of the data’s meaning, beyond access to its schema.
The data analyst agent makes context preparation central. Its builders considered schema access insufficient and created a structured way to document data semantics—what the data means. The agent was open source and reported as successful internally, though no accuracy measurements were given.
An Agent on Every Desk helps customer organizations develop the same capability. Forward deployed engineers—engineers who work directly with customers on implementation—help choose and build a feasible, valuable first project. The approach is aimed particularly at large companies facing a daunting initial deployment. For startups, the suggested path is to adapt an open-source example with a coding assistant.
The program asks customers to commit to three agents: 1. Vercel builds the first. 2. The customer builds the second with Vercel’s support. 3. The customer builds the third independently, with help still available. The intended result is an organization able to build its own custom agents.
Python support and two ways to wait
The Python announcement concerned deployment and platform access. Vercel had recently shipped zero-configuration deployment for Flask and FastAPI, plus a Python SDK for its API. AI SDK remained TypeScript-only. Hiring and infrastructure investment supported the Python expansion, including execution through Fluid Compute.
Fluid Compute and workflows handle waiting at different execution levels. Between workflow steps, nothing executes; resuming a step carries overhead. The example is FFmpeg processing followed by an AI model call. With Fluid Compute, the virtual machine remains running, providing a more responsive execution model.
Fluid Compute’s active CPU pricing is presented as useful when a Python backend spends time waiting for a model—30 seconds in the example. The pricing distinction concerns active processing versus waiting; it is not a complete account of all possible charges.
The case for supporting Python alongside JavaScript and TypeScript is that both communities are large and relevant. Vercel’s virtual-machine infrastructure is described as capable of supporting additional languages, with PHP and Ruby eventual intentions and no timetable. The difficult work is making deployment and tooling feel native to each ecosystem.
Build on existing strengths
The leadership advice is to choose AI products that extend a company’s capabilities and customer credibility. Vercel’s early bets fit that test: v0 began with webpage creation, while AI SDK extended its framework expertise into AI applications. v0’s full-stack capabilities came later with Sonnet models.
A question about changing manager-to-engineer ratios yields no measured staffing trend. The organizational principle offered instead is a strong individual-contributor career path, modeled on Google’s: engineers should be able to reach top levels and increase compensation without becoming managers. Engineering excellence, the argument goes, does not reliably predict management suitability.
Move security outside the generated app
Vercel encourages all employees to contribute code. That ambition leads to the closing technical problem: how to keep applications secure when more people can build them with AI. Vercel describes ongoing work based on a threat model that assumes both the developer and the AI may make serious mistakes. The goal is a security baseline independent of application quality.
The proposed architecture moves authentication and control over which data a person can see outside the application. An employee might build an app in v0 and deploy it to coworkers, but only the appropriate people should gain access, and each should see only the appropriate data. Those boundaries should survive incorrect application code.
This remained work in progress with large companies, without a release date or measured security results. Another participant offers WorkOS as a nearby comparison and calls for infrastructure that lets people build applications safely with AI. The closing ambition is to expand who can create software while moving essential access controls beyond the code they generate.