A reusable tool loop agent keeps model logic in one place while routes and interfaces handle their own concerns.
2
A persistent named sandbox gives an agent a workspace that survives requests, allowing it to plan, inspect files, execute code, and build on earlier work.
3
Memory works well as files that the agent reads and writes, especially when repeatable tasks become Python scripts it can reuse later.
Summary
Nico Albanese builds an agent with AI SDK v6, starting with a ToolLoopAgent, a Next.js route, and the useChat hook. He adds provider-executed web search and shows how the agent definition can drive end-to-end types in the route and UI. The central part of the workshop is a persistent Vercel Sandbox. Albanese explains how named sandboxes can survive inactivity by snapshotting their file systems, so later requests can return to the same workspace. A bash tool gives the agent access to that workspace. The agent then uses a memories.md file for persistent information and generates Python scripts for repeatable tasks such as fetching weather data. Albanese also discusses context preparation, call options, sub-agents, input caching, and compaction. He is candid about prompt mistakes and memory failures during the demo. The talk ends with a larger internal system built from these same patterns, including durable workflows and background sub-agents.
AI SDK v6 keeps agent logic separate from application routes
Albanese says earlier applications often put the model logic directly in a chat route, where tools and system prompts could grow into 2,000 lines of code. AI SDK v6 introduces a more object-oriented way to define agents with a ToolLoopAgent. The agent can live once in a shared library and be used from a Next.js app, a Bun server, or another plain JavaScript application. The route only handles concerns such as receiving messages and streaming the response. He describes the agent runtime as one of the building blocks for managing the loop and context between steps.
Provider-executed tools add context without application-side execution code
Albanese separates tools into custom tools, provider-defined tools, and provider-executed tools. Custom tools include a description, input schema, and execute function. Provider-defined tools come with schemas and descriptions that the model provider has trained its models to use. Provider-executed tools run inside the provider's infrastructure. Web search is the example used in the workshop. The application opts into the provider's search tool, and the provider executes it when the agent chooses it, then adds the result to the message state. This speeds up the demo, although it ties the tool to one provider.
Typed agent messages let the UI understand tool calls
When web search runs, the initial UI gives the user no indication that the agent is working through another step. Albanese adds a UI case for the web search tool, then replaces an untyped tool payload with a message type inferred from the agent definition. The inferAgentUIMessage helper derives types from the tools attached to the agent. The route handler declares that message type, and useChat uses the same type on the client. The UI can then inspect the web search input and output without treating them as unknown values. Albanese presents the agent definition as the source of truth for this type flow.
A file system changes how an agent follows through on long tasks
Albanese describes an internal Vercel agent that had access to many company systems but often used only a few tools before returning a partly hallucinated answer. Adding a file system and instructions changed its behavior. The agent created a plan file with the objective at the top, followed that plan, and checked off work as it progressed. It also kept research in a separate directory. The initial request stayed available in the plan instead of being buried in a growing context window. Albanese says the result was an artifact that showed what the agent did and what work went into the task.
Named sandboxes preserve a workspace across agent requests
Ordinary remote sandboxes are ephemeral. They may live for a limited period, then disappear. Vercel's named sandboxes give each sandbox a name and allow it to have multiple sessions. Code refers to the sandbox by name. Vercel routes the request to an active instance or starts a new one when needed. After inactivity, the sandbox can be stopped while its file system is snapshotted. A later request starts from that snapshot, so the agent can return to the same state without application code managing archives, storage, and sandbox replacement. Albanese says the feature is in beta during the workshop.
Context should be shaped at message conversion or before each step
The default useChat behavior sends the full message history with every request. Albanese says applications can instead send only the most recent message and rebuild the history on the server. Developers can also alter messages during conversion to model messages, removing UI-specific fields or changing data parts. For more control, AI SDK provides prepareStep, a callback that runs before each agent step. It receives the messages, context, model, step number, and prior step data. The callback can return modified parameters, such as a sliding window containing only the most recent five messages. Albanese warns that summarization and compaction are lossy.
Call options and runtime context pass a sandbox into independent tools
The sandbox changes on each agent invocation, so Albanese defines a call option schema with Zod and makes the sandbox an expected option. The route obtains a sandbox by name and passes it to the agent. A prepareCall function runs once at the start of the agent run and moves the sandbox from call options into runtime context. Tools can read that context during execution, which keeps the bash tool independent from the specific agent that calls it. The pattern also supports other structured inputs, such as a customer ID or membership type that could change the model or agent behavior.
Bash gives the agent a general way to inspect, modify, and run its workspace
Albanese argues that bash is often enough for an agent because models are good at generating shell commands. The bash tool has a description, an input schema, and an execute function. Its execute function takes the command from the model, retrieves the sandbox from runtime context, runs the command, and returns standard output, errors, and the exit code. The workshop first runs commands such as ls -la in the Vercel Sandbox. Albanese then adds instructions explaining when the agent should use bash, since merely giving the model a tool does not tell it when or how to use it.
Files and generated scripts give the agent persistent memory and reusable skills
The workshop stores agent memory in memories.md. Before each run, the application reads the file and injects its contents into the agent's instructions. The prompt tells the agent to add important facts the user shares and to read and write the file. During the demo, the agent records Albanese's name and his work on AI SDK, while also showing how vague or conflicting instructions can cause it to save trivial greetings or even remove memories. Albanese then instructs the agent to turn repeatable tasks into Python scripts and record those scripts in the memory file. After creating a weather script, the agent can reuse it for another weather request.
"The core building blocks for building agents in 2026 are an agent runtime, the tools itself that you're passing into that runtime, and then finally a computer or some kind of sandbox file system for the agent to be able to persist state or execute code within its run."17:35
Who should watch
You are building an agent in a JavaScript or Next.js application and want a reusable tool loop with typed messages and streamed UI responses.
Your agent loses track of long tasks or needs a workspace that persists between requests, sessions, or sandbox restarts.
You are deciding how to implement memory, context pruning, bash execution, generated scripts, or sub-agents.
