AI SDK 7 Needs UI Contracts

Vercel's AI SDK 7 release is not just another agent-library update. The useful signal for builders is that production AI features are moving from "send prompt, render text" toward explicit UI contracts: typed message parts, resumable streams, dynamic tools, MCP integrations, and agent sessions that survive real user behaviour.

That matters if you are building lead-intake copilots, internal operations agents, ecommerce assistants, research tools, booking flows, or browser automation around AI. The fragile part is no longer only the model call. It is the contract between the model, your server route, your UI, your tools, and your measurement layer.

What changed

The fresh evidence is strong enough to publish because it is a same-day platform release with multiple primary signals. Vercel's launch post says AI SDK 7 makes AI apps more reliable and type-safe, with a redesigned message system, resumable streams, dynamic tools, MCP support, and agent harness work. The matching Vercel changelog marks AI SDK 7 as available on June 25. The npm registry also shows the ai package at version 7.0.0, with 7.0.0 published on 2026-06-25.

The release is interesting because the headline features are not just new model wrappers. They are application-boundary features:

• Typed message parts make the UI-to-server contract more explicit than a loose text transcript.
• Resumable streams acknowledge that users reload tabs, mobile connections drop, and long-running agent work should not disappear.
• Dynamic tools make tool availability part of runtime state, not a static list copied into every request.
• MCP support brings external tool servers into the same product surface as your own app tools.
• Agent harnesses continue the direction Vercel introduced earlier: coding and workflow agents are runtime processes with sessions, approvals, sandboxes, and native state, not just chat completions.

That is a bigger product lesson than "upgrade your dependency." If AI features are now interactive software, the seams around those features need the same engineering discipline as forms, checkout, search, and account management.

Why this matters for builders and operators

Most small-business AI features fail in boring ways. The model answers well in a demo, then production users expose the missing edges: the stream dies when the phone sleeps, the assistant calls a tool twice, a CRM note contains the wrong lead id, the chat transcript cannot be replayed for support, or an automation completes but nobody can explain which data it touched.

AI SDK 7's direction points at those edges. Builders should stop treating the chat UI as a textarea plus response bubble. For any useful AI-enabled workflow, the UI is a state machine:

1. the user says what they want;
2. the app resolves identity, permissions, and context;
3. the model emits text, tool calls, structured parts, or agent status;
4. the server executes approved work;
5. the UI renders progress and recoverable state;
6. analytics records what happened in business terms.

If that contract is implicit, the system becomes hard to debug. If it is explicit, you can test it, measure it, and decide where humans need to stay in the loop.

Website audit item: inspect the AI boundary

For a normal website audit, I would check Core Web Vitals, forms, accessibility, schema, analytics, conversion paths, and security headers. For a site with an AI assistant or agentic workflow, I would now add an AI boundary audit.

The audit asks five practical questions.

What can a message contain?

Do not assume messages are only strings. Modern AI UIs carry text, tool calls, files, citations, errors, reasoning summaries, approval requests, progress states, and structured outputs. If those are all squeezed into one content field, you will eventually lose information or render the wrong thing.

Define the allowed message parts for your product. A local-service quote assistant might allow:

• user text;
• extracted job details;
• file or image references;
• calendar availability proposals;
• quote-draft status;
• handoff notes for a human operator.

An ecommerce assistant might allow:

• product references;
• comparison tables;
• discount eligibility checks;
• cart-change proposals;
• delivery estimate lookups;
• return-policy explanations.

The important part is not copying Vercel's exact abstractions. It is deciding which parts are first-class in your product and which ones are not allowed.

Which streams must be resumable?

Resumable streams sound like developer ergonomics until you map them to business workflows. A product recommendation can fail gracefully. A lead-qualification workflow that has already written to a CRM cannot simply vanish because the user refreshed the page.

Classify streams by consequence:

Stream type	Example	Resume requirement
Low consequence	blog summary, FAQ answer	nice to have
Medium consequence	product comparison, draft email	should resume or regenerate safely
High consequence	booking, quote, CRM update, payment-adjacent workflow	must resume, reconcile, or require human review

For high-consequence flows, store enough server-side state to answer: did the tool run, did the user approve it, what id was created, and what should the UI show after reconnecting?

Which tools are available right now?

Static tool lists are a common source of agent mistakes. A tool should be available only when the user, page, account, and workflow state make it safe.

Examples:

• A booking assistant should not expose create_booking until the user has selected a valid slot and supplied required contact details.
• A Shopify support assistant should not expose issue_refund unless the operator is authenticated, the order is eligible, and the refund amount is within policy.
• A website-audit agent should not expose crawl_site for arbitrary domains if the product is scoped to verified properties.
• A content agent should not expose publish_page until a draft has passed brand, legal, and SEO checks.

Dynamic tools are useful because real permissions are dynamic. The product should make that visible in code, logs, and UI.

Where do external MCP tools fit?

MCP support is exciting, but it also widens the trust boundary. An MCP server can represent a CRM, browser, filesystem, analytics account, ecommerce backend, or internal tool. That means it should be treated like an integration, not a plugin someone casually adds to a chat route.

Before connecting an MCP server to a customer-facing assistant, document:

• what data the server can read;
• what data it can write;
• whether calls are idempotent;
• which user or service identity it runs as;
• how approvals are captured;
• how failures are surfaced to support;
• how the server is disabled during an incident.

This connects directly to the broader credential-control work I wrote about in Credentials Need a Kill Switch. Tool access and credential revocation are the same operating system viewed from different angles.

What will support see after something goes wrong?

If a customer says, "the AI booked the wrong time" or "the assistant changed my order," a support person should not have to read raw model transcripts and guess.

Log the product events:

• assistant_message_created
• tool_offered
• tool_approved
• tool_started
• tool_completed
• tool_failed
• human_handoff_requested
• workflow_resumed
• workflow_reconciled

Attach stable ids: user id, session id, message id, tool call id, external object id, and approval id. Avoid logging secrets or unnecessary personal data. The goal is traceability, not surveillance.

CRO and SEO implications

For marketers and operators, the immediate temptation is to add an AI assistant to every landing page. The better move is to use AI only where it reduces decision friction or captures better intent than a normal form.

Good candidates:

• complex product finders;
• quote-request triage;
• booking flows with constraints;
• troubleshooting before support handoff;
• guided website audits;
• internal sales-assist tools that prepare a human follow-up.

Weak candidates:

• generic "ask me anything" chat bubbles;
• assistants that repeat page content already visible above the fold;
• checkout flows where speed and trust matter more than conversation;
• bots that hide the actual contact, quote, or booking path.

Measure AI features against normal conversion behaviour. For a lead site, compare assistant-assisted visitors with direct form submitters on qualified lead rate, response time, booking completion, and spam rate. For ecommerce, measure add-to-cart rate, product-return rate, support contacts, and time to decision. Do not celebrate chat volume by itself.

There is also a search implication. AI assistants can answer questions that should maybe be pages. If users repeatedly ask the same buying question, turn the answer into crawlable, structured content. The assistant is a discovery instrument; the website still needs durable pages for search, sharing, accessibility, and trust.

Build checklist before upgrading

Use this checklist before treating AI SDK 7 as a quick dependency bump.

• Inventory every AI route, tool, provider, and UI surface.
• Define allowed message parts for each workflow.
• Decide which streams must resume and what state must be stored.
• Gate tools by user, account, page, workflow state, and approval status.
• Separate read-only tools from write tools.
• Give every tool call a stable id and idempotency strategy.
• Add product-event logging for tool offers, approvals, completion, failure, and resume.
• Review MCP servers as integrations with credentials, scopes, and revocation plans.
• Write support-facing explanations for common failure states.
• Measure outcomes, not chat usage.

What to avoid

Do not let the SDK upgrade become a permission upgrade. A cleaner API is not a reason to give an assistant access to more systems than the workflow requires.

Do not make every tool available on every turn. Agents are better when the product narrows the safe action space.

Do not rely on the model transcript as your audit log. Transcripts are useful context, but product events should be structured, searchable, and tied to business objects.

Do not ship resumable UI without reconciliation. If a stream resumes after a write action, the app needs to know whether the external action already happened.

Do not hide the human path. For local-service, ecommerce, and consulting sites, the assistant should accelerate qualified contact, not trap people in a novelty interface.

The useful framing

The practical lesson from AI SDK 7 is that AI apps now need contracts at the edges. The model contract says what can be generated. The UI contract says what can be rendered. The tool contract says what can be done. The analytics contract says what the business can learn. The support contract says how humans recover when automation gets messy.

That is good news for serious builders. It moves AI features away from demo magic and toward normal product engineering: typed interfaces, recoverable workflows, scoped tools, observable events, and deliberate guardrails.