Skip to content

Add AI Gateway tool calling support#363

Open
IzumiSy wants to merge 3 commits into
izumis/ai-gateway-openai-sdkfrom
izumis/ai-gateway-tool-calling
Open

Add AI Gateway tool calling support#363
IzumiSy wants to merge 3 commits into
izumis/ai-gateway-openai-sdkfrom
izumis/ai-gateway-tool-calling

Conversation

@IzumiSy

@IzumiSy IzumiSy commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Motivation

The previous AI Gateway transport migration made AppShell rely on the OpenAI SDK for OpenAI-compatible streaming, but useAIChat() was still limited to plain text request/response flows.

The next step is to let AppShell consumers register AI Gateway tools directly, while keeping the public API centered on Tailor Platform's AI Gateway instead of leaking provider SDK concepts into application code.

This PR is stacked on top of izumis/ai-gateway-openai-sdk so the tool-calling diff stays focused on the hook, tool definitions, and Gateway-facing message contract.

Design Decision

Keep the public API AI Gateway-first

useAIChat() now accepts a unified tools object that can contain both local executable tools and provider tools. Local tools are defined with defineAIChatTool(...) plus aiToolSchema.*, while provider tools start with aiProviderTool.openai.webSearch(...).

This keeps AppShell's contract centered on AI Gateway concepts instead of exposing OpenAI SDK tool types directly.

Keep public messages text-first

The public messages array remains focused on user/assistant text messages, with optional assistant sources for provider-backed results such as web search. Tool-call and tool-result messages are kept in the internal transcript only, so AppShell can run local tool loops without forcing consumers to render low-level tool protocol details.

Normalize tool execution responsibilities

Local tools are converted to normalized AI Gateway type: "function" definitions, validated with Standard Schema, executed inside AppShell, and then fed back into the internal transcript. Provider tools are passed through as normalized AI Gateway type: "provider" definitions and are not executed locally.

This keeps AppShell responsible only for local tool orchestration while leaving provider-specific behavior on the AI Gateway side.

Summary

  • add defineAIChatTool(...), aiToolSchema.*, and aiProviderTool.openai.webSearch(...)
  • extend useAIChat() to handle local tool loops while keeping public messages user/assistant text-first
  • extend the low-level AI Gateway client to emit tool-call events and optional assistant sources
  • add tests, exports, docs, and a changeset for the new AI Gateway tool-calling support

@IzumiSy IzumiSy requested a review from a team as a code owner July 3, 2026 14:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant