The runtime determines how an agent’s inner loop runs — how each turn calls the
model, interprets intent, and invokes tools. The default runtime is built on
Google ADK’s execution flow and works out of the box; you can also switch the
execution backend or inject shared processing logic into the flow, without
changing the agent itself.
Default runtime
The ADK runtime is the default and needs no extra configuration:
Switch the execution backend
Use runtime to select the inner-loop execution backend:
Use the Codex runtime
The Codex runtime requires openai-codex, which is not installed with VeADK by
default. Install the required dependencies before using it:
By default, the Codex runtime does not request interactive approval and can execute commands, read and write files, and access the network from its host or container. Enable it only for trusted workloads. In production, use a least-privilege isolated container and restrict the credentials, files, and network destinations it can access.
The model name, API endpoint, and API key still come from the agent’s model
configuration:
Tools and skills use the standard Agent configuration; the Codex runtime does
not require a separate registration path:
- function tools in
tools are exposed as callable tools to the model;
- an MCPToolset in
tools supports tool discovery and invocation;
- skills loaded through
SkillToolset or VeADK’s legacy entry are made available through the Codex skill mechanism.
When the Codex runtime calls the model backend, it retries transient failures
such as rate limits, server errors, overloads, and timeouts. It retries at most
twice by default. Use these environment variables to change the behavior:
Request processing
Without touching business logic, you can inject shared cross-cutting processing
into each run. Pass a processor to run_processor, for example to enforce login
via identity authentication:
When unset, the default processor is used and behavior is unchanged. VeADK ships
AuthRequestProcessor as a ready-made implementation for identity authentication.
Custom processors
Every processor subclasses the abstract base BaseRunProcessor and implements
its process_run(runner, message) method. That method returns a decorator
wrapping the run’s event stream, letting you:
- inject logic before and after the whole run (auth, logging, monitoring);
- intercept, rewrite, or inject events produced during the run;
- build control logic such as retries on top of that.