Skip to content

Add AI Gateway tool calling support#363

Draft
IzumiSy wants to merge 6 commits into
mainfrom
izumis/ai-gateway-tool-calling
Draft

Add AI Gateway tool calling support#363
IzumiSy wants to merge 6 commits into
mainfrom
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
@IzumiSy IzumiSy marked this pull request as draft July 6, 2026 05:42
Base automatically changed from izumis/ai-gateway-openai-sdk to main July 8, 2026 05:31
IzumiSy added 5 commits July 8, 2026 15:05
…ponsibilities

- Extract runAssistantLoop as a pure async generator (assistant-loop.ts)
  that yields events instead of calling session callbacks
- Extract tool execution logic into tool-execution.ts
- Introduce ChatRequestContext class to encapsulate per-request state
  (transcript staging + streaming turn buffer)
- Reduce useAIChat hook to thin React orchestrator with single applyEvent
  dispatch point for all state transitions
- Remove the 12-method AIChatSessionRequest god-interface
@IzumiSy IzumiSy force-pushed the izumis/ai-gateway-tool-calling branch from 29987b9 to 4f114b9 Compare July 8, 2026 06:07
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