Skip to main content
VeADK ships a production-grade React frontend — an enterprise agent-application workbench that talks to agents over the Google ADK API server: create, debug, manage, and use agents from the UI. 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. See Studio for other creation flows and availability.
  • 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, sub-agent handoffs, token usage and timing; conversations render ECharts and Mermaid charts (with source-code switching and zoom), image zoom, video and audio playback, file previews, and long-running task progress; 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.
  • Stop generation: while an agent is replying, the composer’s send button becomes a stop button; clicking it cancels only the active response, preserves any content already received, and immediately enables the next turn in the same session. This applies to both the veadk frontend and veadk studio conversation pages, including sandbox conversations.
  • Context usage meter: a context usage indicator beside the Send button shows the current model’s context window occupancy. Hovering or focusing it expands a 100-cell usage map that breaks down the context into system and tool overhead (estimated), input and history, output and reasoning, and remaining capacity. System and tool usage is an estimate because the model’s usage metadata does not report it separately. The context window size is determined by the cloud provider and model name. This applies to both the veadk frontend and veadk studio agent conversation pages.
  • 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_case and {agent_name}_bad_case sets; 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.
  • Export conversation: export all inputs and outputs up to an assistant reply as a PNG image or PDF file, with download or copy-to-clipboard support (copy is available only for PNG). This applies to both the veadk frontend and veadk studio conversation pages.
  • 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.

Running

Complete installation and model configuration. The distribution includes the UI, so Node.js and a frontend build are not required. Prepare an agent directory with agent.py, __init__.py, and an exported root_agent. See A2UI project setup for the layout
At http://127.0.0.1:8000, select a local agent, send text, and confirm a reply. --agents-dir alone does not select the local list; --dev is required. To use cloud Runtimes, omit --dev and configure the selected provider’s AK/SK
Configure SSO or a trusted gateway before exposing the service to other devices. gateway mode relies on upstream verification; prevent direct access that bypasses the gateway

Dev mode (hot reload)

Use this mode when editing frontend source. Start the backend from the VeADK source root, then start Vite in frontend from a separate terminal. Run npm run build for a production build and point --frontend-dir at the output 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.

Component preview

The frontend directory includes a standalone component preview page for browsing the shared component library. The preview runs without a backend service, organized into Foundation, Base, Block, AI App, Node, and Layout groups, sorted by component name within each group. Foundation includes a frontend development specification page and design tokens. Each component page provides an in-page table of contents with #component/section links for jumping to variant sub-sections and the parameter table. The preview also offers light/dark theme switching and parameter tables generated from TypeScript interfaces. This entry point is independent of the Studio production build and does not replace existing pages.

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.
Local mode uses /tmp, so files can disappear when the process or host is recycled. Use TOS for durable media and restrict bucket access by user permissions.

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 ADK user_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.
Enabling VeIdentity SSO requires the process to have access to Volcengine credentials. The middleware protects the API while exempting the UI shell, /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:
Google is the same with 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.
When deploying to a runtime or public host, the OAuth callback must point at an externally reachable URL: set OAUTH2_REDIRECT_URI to the public callback URL and register the same value in your OAuth app. The cookie Secure flag is enabled automatically when that URL is HTTPS.
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.com hosts.
  • 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.
These restrictions do not replace authentication. Public deployments should still enable SSO or a trusted upstream gateway and use least-privilege cloud credentials. When you need only creation and management features, use the Studio agent workbench.

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
A newly added component directory is discovered and registered automatically, with no central configuration file to edit.
Unknown components with no registered renderer fall back to a collapsible JSON view, so a catalog/renderer mismatch never crashes the UI.
Last modified on September 19, 2026