Give Your Agent a Computer — Nico Albanese, Vercel

May 12, 20261:08:535,612 views

Summary

Nico Albanese, a developer advocate at Vercel, leads a hands-on workshop at AI Engineer Europe 2026 demonstrating how to build a persistent, self-improving AI agent using Vercel's AI SDK v6 and named sandbox infrastructure. The workshop builds incrementally from a basic chat interface to a full agent with a dedicated computer, file-based memory, and the ability to generate and store reusable Python scripts.

The session begins with project setup using the Vercel CLI, OIDC-based authentication via AI Gateway, and a fresh Next.js application. Albanese walks through installing the AI SDK v6 alongside @ai-sdk/react and Zod, then introduces AI SDK v6's new object-oriented `ToolLoopAgent` API — a departure from the flat `generateText`/`streamText` paradigm of SDK v4. The agent definition in `agent.ts` becomes a single reusable object that encapsulates model selection (GPT-4o-mini by default, via the AI Gateway global provider), system instructions, and tools. The route handler in `app/api/chat/route.ts` uses `createAgentUIStreamResponse`, abstracting streaming concerns away from agent logic.

Albanese introduces three tool categories in AI SDK v6: custom tools (developer-defined with description, Zod schema, and execute function), provider-defined tools (where providers like Anthropic supply optimized descriptions, e.g., the bash tool or computer use), and provider-executed tools (server-side execution, e.g., OpenAI web search). He demonstrates the provider-executed web search tool from `@ai-sdk/openai`, showing how passing a `userLocation` object like `{ type: 'approximate', city: 'London' }` improves geographically relevant results with zero additional code.

A significant portion addresses end-to-end type safety: using `inferAgentUIMessage` to derive a typed message type from the agent definition, then passing it as a generic to `useChat` in the React client. This yields fully typed tool call inputs and outputs in the UI rendering switch/case, enabling proper component rendering for web search and bash tool states.

The workshop's centrepiece is Vercel's new persistent named sandboxes, currently in beta. Unlike ephemeral sandboxes (which expire after hours or days), named sandboxes persist state via filesystem snapshots: when a sandbox is idle, Vercel snapshots the filesystem and spins it down; on the next request, it restores from that snapshot, making it feel like a continuously running machine. Albanese contrasts this with his prior approach of manually tarring the entire filesystem after each request and storing in blob storage. The agent receives a `bash` tool that runs commands inside the sandbox, injected via AI SDK's runtime context system — analogous to React Context — rather than passing the sandbox instance directly to each tool.

Albanese introduces `callOptionSchema` (a Zod schema defining per-call structured inputs) and `prepareCall` (a one-time setup function that runs before each agent invocation to inject the sandbox into runtime context). This pattern supports multi-tenant use cases, e.g., routing different Vercel plan tiers to different models.

For memory, Albanese implements a `memories.md` file in the sandbox. `prepareCall` reads this file and injects its contents into the system prompt before each run. The agent is instructed to write important user facts — but not trivial interactions like greetings — to `memories.md` using the bash tool. Live demos show the memory persisting across sessions after a page refresh.

The final evolution is self-improvement: the agent is instructed to generate reusable Python scripts for repeatable tasks and record their descriptions in `memories.md`. A live demo shows the agent fetching London weather, writing a Python script to do so, and then reusing that script when asked for San Francisco weather in a subsequent message, all within a single assistant turn using only the bash tool.

Albanese closes by previewing a production-grade multi-agent coding system he built on these exact patterns, used by 23 engineers at Vercel. It has processed 3.8 billion tokens, maintains a 90–91% cache token read ratio, uses durable Vercel Workflows so each LLM step is retriable on failure, and has contributed to approximately 350 pull requests. One agent ran for 104 minutes, made 316 tool calls, changed 29 files, and used only 32% of GPT-4's million-token context window — without any compaction.

Key Takeaways

•Giving an agent a persistent file system fundamentally changes its behavior: it stays on task, references its own plan file, and builds on prior work across sessions.
•Named persistent sandboxes in Vercel (beta) solve ephemeral sandbox lifecycle management by snapshotting the filesystem on idle and restoring it on the next request — eliminating manual tar/blob workarounds.
•AI SDK v6's runtime context (analogous to React Context) allows tools to be defined independently of the agent while still accessing per-run state like a sandbox instance.
•Use `callOptionSchema` + `prepareCall` to inject structured, per-invocation inputs (e.g., sandbox, user tier) into the agent runtime in a type-safe way.
•The `prepareStep` callback runs before each step in the agent loop, enabling dynamic context manipulation (e.g., sliding-window message pruning) without breaking the full message history returned at the end.
•With million-token context windows, aggressive message compaction is often counterproductive — it invalidates the input cache and can cause the model to lose original instructions. A 90%+ cache read ratio is more valuable than pruning.
•A single bash tool is often sufficient for an agent to perform a wide range of tasks; models in 2026 are highly capable bash command generators.
•File-based memory (memories.md) combined with deterministic injection into the system prompt is a practical alternative to vector-based memory for most agent use cases.
•Instruct agents to generate and store reusable scripts for repeatable tasks, creating a self-accumulating tool library within the sandbox.
•Sub-agents offloaded to separate context threads can complete substantial work (e.g., 30,000 tokens used) while returning only a summary (e.g., 500 tokens) to the main thread, keeping the primary context lean.

Transcript

I now have my live deployment here and I can continue to dashboard and I've got my project. One out of five things for the production checklist. Is that all? Were you able to get that? Cool. So we're going to jump over to the repository on GitHub that clicking that big repo button. And then I'm going I'm going to quit out of Slack and all these things and I'm going to jump into a terminal. Head over to directory that I'm happy with. And I'm happy to pop this in and I'm going to get clone that oo...