[PR #331] docs: add native Google Vertex AI provider RFC #326

New Issue

2026-06-06T22:10:14-04:00

yindo commented

2026-06-06 22:10:14 -04:00

📋 Pull Request Information

Original PR: https://github.com/vxcontrol/pentagi/pull/331
Author: @mason5052
Created: 6/3/2026
Status: 🔄 Open

Base: main ← Head: codex/issue-321-vertex-provider-rfc

📝 Commits (2)

bd7c14f docs: add native Google Vertex AI provider RFC
5c96891 docs: address review feedback on Vertex AI RFC

📊 Changes

1 file changed (+229 additions, -0 deletions)

View changed files

➕ examples/proposals/vertex_ai_provider.md (+229 -0)

📄 Description

Summary

Add examples/proposals/vertex_ai_provider.md, a planning RFC for a future native Google Vertex AI provider (vertex). RFC/docs only - no code, schema, migration, frontend, or provider runtime changes, and no new env vars or types. Every VERTEX_* key and type named is explicitly labeled a candidate.

Problem

Issue #321 requests a native Vertex AI provider with service-account / ADC auth, opened after #310 clarified that Vertex AI is not natively supported today (the only Google option, gemini, targets AI Studio and takes an API key, not GCP project credentials). The issue already contains a full implementation outline and four open questions, and the author explicitly asks for maintainer direction on adapter strategy and Gemini-vs-Claude scope before implementing. Per PentAGI's recent contribution pattern (and the lesson from #268), a planning RFC is the right first step for provider-sized work rather than a speculative implementation PR.

Solution

A self-contained RFC under examples/proposals/ (matching the existing mcp_client_integration.md / flow_concurrency.md style) that:

Distinguishes the current options - AI Studio gemini, direct Anthropic, AWS Bedrock, and the custom OpenAI-compatible LiteLLM-proxy workaround - from the proposed native vertex provider.
Recommends a staged approach - v1 Gemini-on-Vertex with ADC / service-account auth; Claude-on-Vertex deferred to a maintainer decision, with the note that it likely belongs on the Anthropic adapter (Vertex auth/endpoint mode) rather than the Gemini-shaped path because the message schema differs.
Models auth on the existing Bedrock multi-auth precedent (ADC default chain plus a service-account file), and flags that service-account JSON is sensitive and must be file-mounted / secret-managed, never pasted into UI or written to logs.
Captures config/migration touch points (the CLAUDE.md provider checklist, the REST Valid() whitelist, and the PROVIDER_TYPE enum-swap migration pattern) so the eventual implementation size is clear, and restates the issue's open questions for maintainers.

All wording is framed as proposed/candidate/future; the RFC states up front that native Vertex support does not exist today.

User Impact

Gives maintainers a concrete, reviewable artifact to settle the adapter-strategy and Gemini-vs-Claude-scope questions before any code lands.
Documents, in one place, why the LiteLLM-proxy workaround is currently needed and what a native provider would replace.
No runtime impact whatsoever - documentation only.

Test Plan

git diff --check clean.
RFC/docs-only diff: a single new file examples/proposals/vertex_ai_provider.md. No code, schema, migration, generated, frontend, or provider runtime files changed.
Confirmed no overlap with open PR #328 (which touches config.go, providers.go, provider/provider.go, server/models/providers.go, and minimax/*); this RFC touches none of those.
Confirmed no existing vertex provider package, proposal, or open PR exists.
Verified the referenced facts against main: the 10 current provider types, the AI Studio gemini API-key path, the Bedrock multi-auth fields, and the 20260227_120000_add_cn_providers.sql enum-swap migration.
Verified all wording is hedged (proposed / candidate / future / RFC) and never claims native Vertex support exists.

Refs #321

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/vxcontrol/pentagi/pull/331 **Author:** [@mason5052](https://github.com/mason5052) **Created:** 6/3/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `codex/issue-321-vertex-provider-rfc` --- ### 📝 Commits (2) - [`bd7c14f`](https://github.com/vxcontrol/pentagi/commit/bd7c14f8540bb4d251ec5916379d8c66078d5f3c) docs: add native Google Vertex AI provider RFC - [`5c96891`](https://github.com/vxcontrol/pentagi/commit/5c968919ec1989c35164a53875469d058b8aa835) docs: address review feedback on Vertex AI RFC ### 📊 Changes **1 file changed** (+229 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `examples/proposals/vertex_ai_provider.md` (+229 -0) </details> ### 📄 Description ## Summary Add `examples/proposals/vertex_ai_provider.md`, a planning RFC for a future native Google Vertex AI provider (`vertex`). RFC/docs only - no code, schema, migration, frontend, or provider runtime changes, and no new env vars or types. Every `VERTEX_*` key and type named is explicitly labeled a candidate. ## Problem Issue #321 requests a native Vertex AI provider with service-account / ADC auth, opened after #310 clarified that Vertex AI is not natively supported today (the only Google option, `gemini`, targets AI Studio and takes an API key, not GCP project credentials). The issue already contains a full implementation outline and four open questions, and the author explicitly asks for maintainer direction on adapter strategy and Gemini-vs-Claude scope **before** implementing. Per PentAGI's recent contribution pattern (and the lesson from #268), a planning RFC is the right first step for provider-sized work rather than a speculative implementation PR. ## Solution A self-contained RFC under `examples/proposals/` (matching the existing `mcp_client_integration.md` / `flow_concurrency.md` style) that: - **Distinguishes the current options** - AI Studio `gemini`, direct Anthropic, AWS Bedrock, and the custom OpenAI-compatible LiteLLM-proxy workaround - from the proposed native `vertex` provider. - **Recommends a staged approach** - v1 Gemini-on-Vertex with ADC / service-account auth; Claude-on-Vertex deferred to a maintainer decision, with the note that it likely belongs on the **Anthropic** adapter (Vertex auth/endpoint mode) rather than the Gemini-shaped path because the message schema differs. - **Models auth on the existing Bedrock multi-auth precedent** (ADC default chain plus a service-account file), and flags that service-account JSON is sensitive and must be file-mounted / secret-managed, never pasted into UI or written to logs. - **Captures config/migration touch points** (the `CLAUDE.md` provider checklist, the REST `Valid()` whitelist, and the `PROVIDER_TYPE` enum-swap migration pattern) so the eventual implementation size is clear, and restates the issue's open questions for maintainers. All wording is framed as proposed/candidate/future; the RFC states up front that native Vertex support does not exist today. ## User Impact - Gives maintainers a concrete, reviewable artifact to settle the adapter-strategy and Gemini-vs-Claude-scope questions before any code lands. - Documents, in one place, why the LiteLLM-proxy workaround is currently needed and what a native provider would replace. - No runtime impact whatsoever - documentation only. ## Test Plan - [x] `git diff --check` clean. - [x] RFC/docs-only diff: a single new file `examples/proposals/vertex_ai_provider.md`. No code, schema, migration, generated, frontend, or provider runtime files changed. - [x] Confirmed no overlap with open PR #328 (which touches `config.go`, `providers.go`, `provider/provider.go`, `server/models/providers.go`, and `minimax/*`); this RFC touches none of those. - [x] Confirmed no existing `vertex` provider package, proposal, or open PR exists. - [x] Verified the referenced facts against `main`: the 10 current provider types, the AI Studio `gemini` API-key path, the Bedrock multi-auth fields, and the `20260227_120000_add_cn_providers.sql` enum-swap migration. - [x] Verified all wording is hedged (proposed / candidate / future / RFC) and never claims native Vertex support exists. Refs #321 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

yindo added the pull-request label 2026-06-06 22:10:14 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#326