Context
Agentic API already has typed ResponsesTool declarations, request-scoped tool routing, and a gateway execution loop. Draft PR #34 also demonstrates the intended file_search flow with OGX: normalize the built-in tool into a model-visible function, execute search in the gateway, inject the result, and continue inference.
The remaining architectural gap is to make that ownership model explicit and general across Responses tool types. Related vLLM work in vllm-project/vllm#34487 currently includes both typed Harmony handling and OGX execution; external tool execution should instead live in Agentic API.
Desired ownership boundary
- vLLM/inference providers: render tool definitions, generate tokens, and parse model output into tool-call shapes.
- Agentic API: validate declarations, choose the upstream representation, route calls, execute gateway-owned tools, emit canonical typed Responses items/events, and continue the agent loop.
- Clients: execute client-owned function/custom/namespace calls.
- External backends such as OGX: remain behind Agentic API executors; credentials and network access never enter vLLM core.
Provider capability must not change execution ownership. A backend may support a native typed file_search declaration/call, but Agentic API still performs the search.
Proposed design
Extend the existing tool framework so each supported Responses tool type defines:
- Public declaration validation.
- Upstream representation:
- default: normalize to a function declaration;
- optional: forward a native declaration when the configured upstream advertises support.
- Call recognition and normalization into one internal invocation type.
- Ownership and executor selection.
- Canonical output-item, streaming-event, and continuation-input encoding.
Keep executor configuration separate from upstream capabilities. For example:
- executor mapping:
file_search -> ogx
- upstream capability: native
file_search declarations/calls supported or unsupported
The request-scoped registry must retain the original tool type and configuration so a generic upstream function_call can be restored to file_search_call. Ambiguous name collisions, including a custom function named file_search alongside the built-in, must fail validation rather than route heuristically.
First implementation slice: file_search + OGX
Adapt/rebase the useful pieces of #34 onto the current ToolHandler / GatewayExecutor framework:
- Complete
FileSearchToolParam validation, including OpenAI-compatible search options.
- Normalize
file_search to a model-visible function for generic vLLM backends.
- Add a file-search executor slot and OGX implementation in Agentic API.
- Add canonical
file_search_call output types and streaming lifecycle events.
- Execute OGX, inject the tool result, and continue the existing gateway loop.
- Surface missing configuration, backend failures, malformed payloads, and incomplete calls explicitly.
- Do not add OGX clients, credentials, or execution loops to vLLM core.
Native typed calls can be added as a compatible upstream representation later without changing execution ownership.
Acceptance criteria
Related
Context
Agentic API already has typed
ResponsesTooldeclarations, request-scoped tool routing, and a gateway execution loop. Draft PR #34 also demonstrates the intendedfile_searchflow with OGX: normalize the built-in tool into a model-visible function, execute search in the gateway, inject the result, and continue inference.The remaining architectural gap is to make that ownership model explicit and general across Responses tool types. Related vLLM work in vllm-project/vllm#34487 currently includes both typed Harmony handling and OGX execution; external tool execution should instead live in Agentic API.
Desired ownership boundary
Provider capability must not change execution ownership. A backend may support a native typed
file_searchdeclaration/call, but Agentic API still performs the search.Proposed design
Extend the existing tool framework so each supported Responses tool type defines:
Keep executor configuration separate from upstream capabilities. For example:
file_search -> ogxfile_searchdeclarations/calls supported or unsupportedThe request-scoped registry must retain the original tool type and configuration so a generic upstream
function_callcan be restored tofile_search_call. Ambiguous name collisions, including a custom function namedfile_searchalongside the built-in, must fail validation rather than route heuristically.First implementation slice: file_search + OGX
Adapt/rebase the useful pieces of #34 onto the current
ToolHandler/GatewayExecutorframework:FileSearchToolParamvalidation, including OpenAI-compatible search options.file_searchto a model-visible function for generic vLLM backends.file_search_calloutput types and streaming lifecycle events.Native typed calls can be added as a compatible upstream representation later without changing execution ownership.
Acceptance criteria
file_searchdeclaration works through a generic function-only vLLM backend.file_search_callitems/results.tool_choice: "none"prevents declaration and execution.file_searchare not misclassified; ambiguous declarations are rejected.Related