veadk frontend is a self-contained launcher: in the default mode it serves this React UI and the agent API from a single process on the same origin, so there is no separate backend to deploy and no cross-origin setup.
What it can do
- Create agents: custom configuration is the available project-creation flow, producing a runnable VeADK project (
agent.py,requirements.txt, and so on) that you can preview, edit, and download. Intelligent, template, and workflow entries are marked as coming soon and cannot be selected. - Multimodal messages: upload images, TXT, Markdown, PDF, and video; both user attachments and model-returned media can be previewed and restored from history.
- Chat and debug: multi-turn conversations showing thinking, tool calls, token usage and timing; built-in tools (web search, image generation, video generation, memory retrieval, knowledge-base retrieval) display dedicated icons and running status while executing; conversations also render the A2UI rich-UI cards an agent returns.
- Agent picker: switch agents from the top-left; hover an agent to see its model and mounted tools.
- Agent information rail: after the first message, the conversation’s right workspace shows the current agent’s description, model, tools, skills, and an optional multi-agent topology. On narrower screens it opens from a title-bar button as a drawer so the transcript is not overlapped.
- Skills and sub-agents: type
/to select a mounted skill or@to delegate the turn to an eligible sub-agent. - Skill center: select skills from Skill Hub, a local upload, or an AgentKit SkillSpace while creating an agent.
- Session history: auto-saved, time-sorted, reopen or delete.
- Smart search: Session searches the current agent’s message history, Web calls its mounted web-search tool, and Knowledge and Memory perform semantic retrieval through the configured backends. The interface enables only sources available to the agent and labels results with the index or source name and backend type.
- Message feedback: when connected to a cloud AgentKit Runtime, the like/dislike controls below each answer write the current question, answer, and feedback state to AgentKit evaluation sets. Each agent gets stable
{agent_name}_good_caseand{agent_name}_bad_casesets; changing or cancelling a rating updates the item idempotently. Feedback is associated with the Runtime’s actual app name and automatically falls back to the alternate region when the primary region query fails. A “View evaluation cases” button next to the like/dislike controls opens the agent’s evaluation case list and previews the sample for the current message. If the standard name is reserved but hidden by the service, Studio uses and reuses a deterministic suffixed name. If a Runtime does not expose Session state updates, the browser keeps a compatibility cache. - Add an AgentKit agent: paste a URL and API key to connect a remote agent over the ADK protocol; it then appears in the picker.
- Studio deployment: inspect generated code, configure the region, channel, network, and environment variables, deploy to AgentKit, and monitor the task from the same workbench.
- Tracing: view the call flame graph for the current session.
- Login: SSO or a local username.
Complete tool OAuth authorization
When an MCP or another tool needs OAuth credentials, Frontend displays an authorization card in the conversation. Starting authorization opens the identity provider in a new window. After the callback returns to Frontend, the current tool call resumes automatically without resending the message. If the page cannot capture the callback automatically, the UI asks for the complete callback URL. The callback URL registered with the identity provider must match the tool configuration and point to an address that reaches the current Frontend. If the browser blocks the authorization window, allow pop-ups for the site and retry.Run
Build the UI once, then serve the UI and the agent API together from a single process.1
Build the UI
veadk frontend. When VeADK is installed via pip, a built UI is already bundled in the package, so you can run it directly.2
Launch
Dev mode (hot reload)
Use--vite to serve only the API and allow CORS from the Vite dev server (http://localhost:5173, falling back to http://localhost:5174). Add --dev to load local agents instead of cloud AgentKit runtimes.
The veadk frontend command
If the built UI directory is missing, the command asks you to run
npm run build. Use --vite while developing the React frontend, optionally with --dev for local agents.Multimodal attachments and storage
The composer accepts PNG, JPEG, WebP, GIF, TXT, Markdown, PDF, MP4, WebM, and QuickTime files. The default per-file limit is 20 MB. PDFs are rendered to page images before model invocation; the required dependencies are installed by default starting in 1.0.5. Attachment bodies are stored separately from ADK Sessions, while Session Events keep stable references. Local temporary storage is the default; use TOS when media must survive process or host replacement.Use skills and sub-agents
Type/ in the composer to search skills mounted on the current agent, or @ to select an eligible sub-agent. Selections appear as removable chips and are not sent as ordinary text. After choosing a sub-agent, the skill list switches to the target agent’s own skills.
Deploy with Studio
veadk studio launches a UI focused on creating and managing agents. Before deployment, review the generated source and configure the region, message channel, network, and environment variables; Studio then creates an AgentKit Runtime.
veadk studio deploy deploys Studio itself to VeFaaS. Without --iam-role, the command creates or reuses the default service role and attaches read-only policies required to inspect model, logging, tracing, knowledge, memory, and identity resources. When you pass a custom role, the command does not alter its policies.
Authentication
Sessions and memory are scoped by the ADKuser_id, which comes from the signed-in user. On startup the command loads a .env file from the current directory or its parents, so the environment variables below can be placed in .env.
SSO — enable by passing the pool and client. The UI shows a login page and redirects through the identity provider, then uses the user identifier returned by the userinfo endpoint as the user_id. The pool and client can be given either by name or by UID.
/web/auth-config, /favicon.ico, /assets, and /skillhub, so the app loads and shows its own login page instead of being bounced to the identity provider. The login button’s label and icon are config-driven.
Third-party / custom OAuth2 (env vars) — without a VeIdentity user pool, set OAUTH2_CLIENT_ID (and the secret) to enable GitHub, Google, or any OIDC login. Endpoints are resolved in this order: a built-in preset (OAUTH2_PROVIDER=github or google), then OIDC discovery (set OAUTH2_ISSUER), then explicit endpoints (OAUTH2_AUTHORIZE_URL, etc.).
The GitHub preset only needs the client credentials:
OAUTH2_PROVIDER=google; for any OIDC provider (Keycloak, Auth0, Okta, and so on) set OAUTH2_ISSUER plus the client credentials. A full example lives at examples/front_with_sso/.
When connecting to an AgentKit Runtime protected by custom_jwt, the server forwards the OAuth access token already validated for the current session. Its issuer must match the Runtime discovery URL, and the client ID must be included in the Runtime allowed_clients list.
No SSO (local username) — without those flags, the login page asks for a username (letters and digits, up to 16 characters), stored locally and used as the user_id. In this case the server always reports an unauthenticated state and an empty provider list, and the app renders its local username login.
Login state is cached: SSO via the
veadk_session cookie, local mode via localStorage. The session is created lazily on the first message or attachment upload, not on page load. Once the first message is sent, the conversation view renders it immediately while the server session initializes in the background; during initialization the session ID is shown as “Initializing”. Logout is a local logout — it clears the session and returns to the login page.When SSO is enabled and the sign-in expires during use, a “Login expired” dialog appears. Choose “Sign in again” to open the login page in a separate popup; the current editing context is preserved, and once sign-in completes the action that triggered the prompt is retried automatically. The popup is isolated from the editor and cannot access it. This applies to both
veadk frontend and veadk studio.Frontend security restrictions
VeADK Frontend can be deployed on a public endpoint, so it restricts user-controlled addresses and paths:- The project-creation flow does not execute code submitted by the browser. Test generated code in a controlled local environment before deployment.
- The remote AgentKit proxy requires an API key and accepts only HTTPS
volceapi.comhosts. - AgentKit deployment files must remain inside the current project directory. Absolute paths and relative paths that escape it are rejected.
- Static files can be read only from the built UI directory; path traversal cannot read other host files.
Rendering flow
The frontend talks to the Google ADK API server: it lists available agents, creates a session, and receives the agent’s output as a live stream. When the agent returns an A2UI message, the frontend parses its UI instructions, creates and incrementally updates the corresponding surface, then renders the matching React components by type. A registry maps each component type to a renderer, so adding a new component type only requires registering a renderer for it.Adding a custom (enterprise) component
A custom component has two halves that share one catalog id. For the backend half, see A2UI; the frontend half is below. Frontend half — drop in a new directory; it auto-registers, with no central edit:src/a2ui/components/RevenueChart/index.ts
src/a2ui/components/RevenueChart/RevenueChart.tsx
Unknown components with no registered renderer fall back to a collapsible JSON view, so a catalog/renderer mismatch never crashes the UI.