AI SDK

Used the core SDK for streaming text, server-side catalog tools, and the client chat hook. Streaming wiring, history limits, tool steps, and error parts behaved as expected during local server checks.

What worked

Streaming helpers and tool-call flow mapped cleanly onto a server route plus chat panel.

Added the AI SDK and Anthropic provider package, built a server chat route with validation and streaming plus a client chat panel, and verified compile and route behavior with placeholder configuration.

What worked

Provider abstraction made model selection an environment setting, streaming primitives fit the existing app router and React UI, and version checks helped pick a compatible release line.

What got in the way

Live streaming against the real provider was not exercised because no live key was available, so end-to-end answer quality and stream behavior remain unverified.

Installed the core AI package plus provider package, added a small config seam with env-driven model names and wrapper functions for classification and drafting, then wired them into a new assistant API route and search UI.

What worked

One interface covered both cheap and strong models, model names stayed out of page code, and install plus build integration went through cleanly.

Evaluated the dedicated gateway provider package, inspected its exports and peer and dependency ranges, and removed it after a model-interface mismatch with the installed core SDK major. No live gateway call was made through it.

What got in the way

Installed provider exposed a newer model interface than the installed core SDK expected, so type checking failed and the package was removed without shipping.

Used the provider-agnostic chat SDK and hosted-model provider to stream assistant answers from the server route. Installation and build succeeded, though identifying the current streaming API required inspecting installed types.

What worked

Provider abstraction kept the model choice to one string and streaming integration compiled cleanly into the production build.

What got in the way

Public type declarations needed manual inspection to pick the correct streaming helper for the installed major version.

Used the streaming text helper, message conversion utilities, OpenAI compatible provider client, and UI stream response to implement validation, system grounding, and token streaming from the server route.

What worked

Streaming response helper and provider configuration worked with minor type adjustments during implementation.

Used as the ready-made conversation framework for a provider-neutral helper with streaming, full-history follow-ups, and chained account-scoped tool calls. Switching models stayed behind one wrapper.

What worked

Conversation loop, streaming, client chat state, and multi-step tool orchestration worked without custom transport code. Type checks and production build passed, and the stub-model harness exercised the real tool code successfully.

What got in the way

Provider API surface was hard to discover from docs alone; I had to inspect installed type declarations to confirm transport, message conversion, streaming response, and tool definition names.

Reviewed docs for tool-loop agents and human-approval patterns to see if they could provide routing and write confirmation. Decided against adoption because the relevant major line needed a newer runtime and module format than the API used.

What worked

Approval and per-agent model concepts mapped well to the required confirmation gate and model-swap needs.

What got in the way

Reconciling major-version behavior and runtime prerequisites took extra checking.

Reviewed documentation to design an account-aware, multi-step chat helper that could work across model providers without custom agent plumbing. Docs made provider swapping and tool-calling patterns clear enough to recommend this SDK over provider-locked or heavier alternatives.

What worked

Documentation clearly described provider-neutral streaming and tool definition patterns, which mapped well to scoped account lookups, persisted conversation history, and multi-step tool calls.

Installed major version 4 core plus gateway and OpenAI provider packages to build streaming responses with history limits, catalog grounding and model fallback. The dedicated gateway provider required core version 5 and broke type checks, so switched to the OpenAI provider pointed at the gateway.

What worked

Streaming helpers, message validation and provider switching worked once versions aligned. Package metadata inspection helped resolve peer constraints.

What got in the way

Provider and core version mismatch forced an uninstall and reinstall cycle before checks passed.

Read reference documentation for streaming text and tool-calling loops to evaluate a standard approach. Decided to hand-roll a small streaming tool loop to keep confirmation and trace semantics fully owned and avoid a new dependency.

Installed the SDK and provider package and wired a retrieval-first assistant route and widget around one model constant. Type checking and production build passed and provider swap looks one line. Live calls stayed on deterministic fallback, so generation was not exercised.

What worked

Central model constant and small generate API kept the integration contained.

What got in the way

Live generation path was not exercised because no key was configured, so real model behavior remains unverified.

Installed the current major SDK and used it to build the server chat call with gateway provider options and conversation affinity. Type definitions helped confirm option shapes, and typecheck plus production build passed after integration.

What worked

Current package installed cleanly, server call pattern was compact, and validation plus error mapping integrated without major rework.

Used the streaming SDK and gateway provider to build a grounded chat route and client UI with streaming, suggestions and error states, grounding replies in the existing product catalog.

What worked

Streaming helpers and provider setup worked after checking installed types and exports. Type checking and production build passed with the new route and UI included.

What got in the way

Correct streaming response helper and provider options required inspecting installed type definitions; version differences made the right pattern less obvious from memory alone.

Installed the core package and the OpenAI and Anthropic provider packages, then called streamText with a tool from a server route. An env var selects the provider factory. Docs and the installed exports disagreed on the stop helper, so I checked the package and used the v7 name. The Svelte guide targets a newer Svelte major, so the chat UI was hand-built. A local stand-in for the Anthropic provider completed a tool round-trip and a follow-up that still carried the transcript. Live model APIs stayed unexercised.

What worked

streamText, tool definitions, and a plain text stream kept tool calls on the server. Both provider factories were usable from the installed types. The Anthropic provider accepted a custom base URL, so a local stand-in could exercise streaming, tool use, and a later turn that still had the transcript. The step limiter behaved as the installed helper described once I read it.

What got in the way

A migration note said the step-count helper had been renamed, but the installed build still exported both names. The reference pages I opened left the stop helper, the Svelte 4 chat UI, and the provider event stream unclear, so I read declaration files and the provider bundle. There is no SQLite transcript store, and the resumable-stream addons expect Redis. Engines require Node 22, so a Node 20 production image had to be bumped. The OpenAI provider was wired from types and never executed.

Used as the core framework for a provider-switchable assistant with multi-step tool calling across customer records, history, and recent activity plus pass-through conversation context. Provider adapters for two model vendors and schema-defined tools avoided custom plumbing.

What worked

Provider switching through environment configuration worked, multi-step tool chaining worked in offline probes, and tool plus schema definitions integrated cleanly with existing data models.

What got in the way

API surface for tool definition, schemas, and step limits was hard to discover from installed types and required repeated inspection of declaration files.

Installed the core SDK, the gateway provider, and the React bindings, then used them for a streaming chat route, a catalog lookup tool, and shopper-safe errors. Typecheck and a production build passed. The gateway base URL, budget error shape, and tool helper were clear only after reading the installed packages.

What worked

Streaming, tool calling, and the React chat hook fit the route and client component, and the project typechecked. A live call went out through the gateway provider, and the failure arrived on the UI message stream so the page could show a retry instead of the upstream error text. Differing package majors installed together without a resolution failure.

What got in the way

The gateway provider defaulted to a v4 base path while the docs used for the plan said v1. A budget response was not its own error type; a 402 looked likely to collapse into a generic internal error, so detection had to inspect status and message text. The tool helper was hard to find in the main typings, and an expected error module file was not in the package.

Used the core 'ai' package (v7) and the React bindings (v4) to build a streaming chat route with two catalogue tools, message validation and a client widget that renders tool results as product cards. Typecheck, build, local route smoke tests and direct tool runs all passed.

What worked

Streaming chat, tools with zod schemas, step limits, message validation, and typed tool parts with clear states made the server-plus-UI flow simple. The bundled .d.ts files were detailed enough to confirm the API surface without external docs. The gateway is the default provider when you pass a plain model string. Errors in the stream let me show visitors a friendly message.

What got in the way

The major-version API changes (renamed helpers and new fields) didn't match what I knew, so I read the installed type definitions several times before writing code.

Installed the core package and its React hooks package and used them to build a streaming chat route with server-side tools, message validation and a chat widget. The docs ship inside the package, so I could read the getting-started guide, tool-usage guide and v7 migration guide offline and check exact API names in the type definitions. Typecheck and production build passed. Requests were validated and streamed correctly up to the gateway call.

What worked

Docs bundled with the package made it easy to learn a major version I didn't know well. Typed tool parts, the message-validation helper and the step-count stop condition fit a tool-calling chat well. Error streams send the client a generic message and keep the details in server logs.

What got in the way

The new major version renamed things (for example, system prompt became instructions), so I had to grep the type definitions to confirm parameter names. It requires Node 22+, which meant adding an engines constraint that could change deployment settings. Building mock stream chunks for an end-to-end tool-loop test looked fiddly, so I tested the tool functions directly.

Installed the Anthropic provider with the rest of the SDK and selected a Claude model string for the dev server, with the matching key left as an environment variable. The app typechecked after that wiring. No provider key was available, so the package never sent a request.

What worked

Install succeeded in the same command as the core SDK, and configuration was a model string plus a key variable. The project still typechecked with that model selected.

What got in the way

Provider-specific docs were not fetched; setup was inferred from the core SDK's model-string pattern. Authentication, streaming, and error responses were not observed.

Reviewed docs and feature notes for streaming, multi-step tool use, human confirmation, and telemetry to map requirements to a reusable foundation. Informed the final custom loop design rather than being imported directly.

What worked

Capability mapping for streaming, tool orchestration, confirmation gating, and tracing was clear enough to guide the architecture.

Installed the core AI SDK and used it for a tool loop, confirmation before writes, and a UI message stream. Docs for approvals, the app-router setup, the agent class, and the stream helper were enough to implement that path. Aligning them with the installed v7 types took repeated reads of the declaration files, because a stop-condition name had changed and some helpers were not where earlier examples suggested.

What worked

With a mock model, a write paused until confirmation, then ran only after a matching approval. A forged confirmation raised a specific invalid-approval error and did not call the write. Changing the approved time also blocked the write. The stream-response helper and generate result messages were present once the installed signatures were followed.

What got in the way

Published pages and search results still left the current stop-condition name and tool-helper export unclear, so the installed declarations had to be searched by hand. No live model request was sent, so streaming from a real provider was not observed.

Installed the workflow adapter and wired WorkflowAgent to a gateway model string and step-scoped tools, following the agent docs. The project typechecked and the app build included that workflow. No agent stream was executed.

What worked

The adapter exposed an agent constructor, a stream method, and a stop condition that matched the durable-agent guide, so a custom loop was unnecessary. The declared version installed cleanly beside the core AI SDK.

What got in the way

Tool durability is not applied by the adapter. Docs say to mark each execute function as a step and pass it directly, but confirming the caller does not wrap that call required reading the published JavaScript. Stop-condition naming was also ambiguous until the types were opened. Runtime retries were not observed.