Vercel AI SDK: the client's model may change, but the tools you write stay

Users of an LLM application may wait 5, 10 or even 40 seconds watching a spinner. The official Vercel AI SDK documentation cites exactly that detail when explaining why streaming is necessary. For an FDE, those few dozen seconds are often enough to deflate a client demo.

The AI SDK is a TypeScript toolkit built by Vercel for creating AI applications and agents; the vercel/ai repo describes it as a free, open-source library from the team behind Next.js. The AI SDK 5 announcement of 31 July 2025, by Lars Grammel, Nico Albanese and Josh Singh, said the library had more than 2 million weekly downloads.

For FDEs, what matters more than that figure is a very familiar situation: the client wants to see something working this week, but has not yet decided whose model to use. The AI SDK is designed for precisely that case.

One API for every provider

The README describes the AI SDK as a “provider-agnostic” toolkit, meaning it is not tied to any single model provider. Its core, AI SDK Core, brings four jobs under one API: generating text, generating structured objects, calling tools and building agents. According to the Providers and Models page, this unified interface lets you change provider while keeping the same calling code.

The AI SDK 5 announcement is more specific: moving to another provider requires changing a single line. According to the README, requests go through Vercel AI Gateway by default, so you can pass the model as a simple string. If you want to call a provider directly, there are dedicated packages such as @ai-sdk/openai, @ai-sdk/anthropic and @ai-sdk/google.

On the interface side, the README lists React, Svelte, Vue, Angular and Next.js as supported frameworks. An FDE building both the agent backend and the chat screen can therefore write both ends in one language.

Building an order-lookup agent

Imagine you are working for a logistics company. They want customer service staff to type “where is order 4471?” and get an answer based on real data, not one the model has made up.

The documentation defines a tool as an object the model can call to perform a specific task. When the model decides it needs a tool, it emits a tool call; if the tool has an execute function, the SDK runs it automatically. The sketch below only illustrates the structure of the agent (identifiers are in Vietnamese: lookupOrder means “look up order”, orderId means “order ID”); check exact function names and parameters against the documentation on ai-sdk.dev.

// Structural sketch, not code that runs verbatim
const lookupOrder = {
  description: 'Look up the current location of an order by order ID',
  execute: async ({ orderId }) => callInternalApi(orderId), // the client's API
};

const result = await runAgent({
  model: '<provider>/<model-name>', // the only line to change when switching models
  tools: { lookup_order: lookupOrder },
  stopWhen: /* stop condition, e.g. after a number of steps */,
  prompt: 'Where is order 4471?',
});

The first lesson lies in the description line: the model relies on it to choose a tool, so a vague description will make it call the wrong one or none at all. The second lies in execute, where the agent touches the client’s real systems; handle the case where the order ID does not exist, rather than leaving the model to guess.

The third lesson is the loop. An agent can call a tool, read the result, then call again without ever stopping. AI SDK 5 added two mechanisms for controlling the loop, stopWhen and prepareStep; the practical advice is always to set a stop condition through stopWhen before letting the agent touch real data.

Finally, turn on streaming so the answer appears progressively rather than all at once after several tens of seconds. If next week the client switches provider over price or data policy, you change only the model declaration. The tools, the loop and the interface all stay as they are.

What the library does not solve

The same API does not mean the models answer the same way. One line changes the provider, but each model chooses tools differently and writes answers in its own style. So each time you switch models, rerun your test questions before telling the client that everything is fine.

The data path is the second question to raise early. Requests go through Vercel AI Gateway by default, so with clients in finance or healthcare, ask from the start whether they will accept an intermediary layer. If not, the packages that call providers directly are the safer route.

Last comes language. This is a TypeScript toolkit, so if the client’s engineering team works entirely in Python, adding a new stack may cost more in maintenance than it delivers. Ask clearly which team will own this code after you leave before recommending it.

What to learn first

A sensible order is tools first, the loop next, streaming last. Tools are where the agent touches the client’s real systems, and so where errors are most likely. Once you can write a reliable execute function, stopWhen and prepareStep become much easier to understand.

On a CV, a line saying “used AI SDK” says little. Describe the outcome instead, for example: “built a provider-agnostic agent, switched between two models without rewriting tool logic, bounded the loop with stopWhen”.

When reading FDE job descriptions, look for phrases such as “multi-model”, “streaming UI” or “TypeScript agents”, because those are where this skill is used directly.

The choice of model is often only a temporary decision for the client; the tools and loop controls you write for them will be used for much longer.