Skip to main content
VeADK Java can connect to AgentKit in two forms:
  • AgentKit Runtime HTTP example: starts a lightweight HTTP process with /invoke, /ping, /health, /readiness, and /liveness. Use it to verify that an Agent can be called as an AgentKit Runtime.
  • AgentKit Server example: uses ADK Web and exposes /run, /run_sse, /list-apps, and session-management APIs. Use it when you want ADK Web’s native session and execution behavior.
Before deployment, validate locally that the model, tools, knowledge base, memory, and observability paths work through Agent.builder() and Runner.

Before deployment

  • Use JDK 17 or later.
  • Pin a VeADK Java Maven version, source commit, or release version.
  • Put model, AgentKit, knowledge-base, memory, tool, and observability credentials in platform secrets. Do not store them in the repository or image.
  • Confirm that the runtime image can reach the model service, AgentKit tool service, retrieval backends, and observability backend.
  • Before connecting the cloud runtime, verify the entry class and environment variables with a local HTTP call.

Run locally

Build the example module and copy runtime dependencies:
The minimal runtime needs an accessible model name and model credential. The credential should come from a secret; the command below only shows the variable name:
The local process listens on 127.0.0.1:8000 by default. Set AGENTKIT_STREAMING=true to return Server-Sent Events:
To run the ADK Web style AgentKit Server, use this entry class:

Call the HTTP API

The basic Runtime exposes these health and invocation APIs: You can call the local Runtime with AgentKit CLI:
local-placeholder is only for local verification. In cloud deployments, use the credential issued by the gateway or platform.

Sessions and concurrency

/invoke selects the conversation through request headers: user_id and session_id select conversation context; they are not authenticated identity. In production, authenticate requests at a trusted gateway and forward only trusted user and session information to the Runtime. The basic Runtime keeps sessions in memory, so conversation state is lost when the process restarts. Configure a stable session service or memory backend in the Agent when conversations must survive restarts. Also test concurrency before launch: overlapping requests for the same user_id / session_id return 409 SessionBusy, and a full worker pool returns 503.

Container entry point

The example image uses eclipse-temurin:17-jre, places the jar at /app/app.jar, places dependencies under /app/lib/, and starts this default entry point:
The container sets AGENTKIT_BIND_HOST=0.0.0.0 and PORT=8000 by default, and runs as 10001:10001. Example build and run commands:
To run AgentKit Server from the same image, override the entry class:

Custom Agent

When AGENTKIT_AGENT_CLASS is not set, the example Runtime creates a built-in Agent from environment variables. To reuse an Agent from your application code, provide a class that contains public static BaseAgent ROOT_AGENT and inject its fully qualified class name:
In this mode, configure the model, tools, instructions, knowledge base, memory, and callbacks in the Java code behind ROOT_AGENT. The Runtime loads that Agent, accepts HTTP requests, and closes the Agent when the process exits.

Environment variables

Tool credentials should also be injected as secrets: Adding a tool name to AGENTKIT_TOOLS does not provision the backing service. Confirm service permission, network connectivity, and secret injection before deployment.

AgentKit CLI templates

AgentKit CLI provides Java lifecycle templates for generating or wrapping Runtime projects: Template availability depends on the installed CLI version. Check it before use:

Production checklist

For cloud deployment, check at least these items:
Last modified on October 20, 2026