Summary
Since 0.6.0, agents-cli deploy (agent_runtime target) creates/updates the ReasoningEngine resource without class_methods in the spec. The unified container itself serves everything fine (playground, A2A, /api/reasoning_engine), but the vertexai client generates the AgentEngine wrapper's Python methods from spec.class_methods. With it empty:
adk_app = client.agent_engines.get(name=...)
adk_app.operation_schemas() # -> []
adk_app.async_create_session(user_id="u_1") # AttributeError: 'AgentEngine' object has no attribute 'async_create_session'
This breaks the documented flow in Use an ADK agent → Create session for every project deployed with agents-cli >= 0.6.0. Downstream report: google/adk-python#6369 (adk-python itself is not at fault — adk deploy agent_engine sets class_methods unconditionally in cli_deploy.py).
Root cause
The 0.6.0 unified-container change dropped the class-methods generation from src/google/agents/cli/deploy/agent_runtime.py: generate_class_methods_from_agent(), _introspect_agent_via_subprocess(), and the "class_methods": ... entry in the deploy config were all removed (git log -S class_methods — 0.5.x still had them). The comment in the current code says:
# Agent Engine builds and serves the container over HTTP, so no entrypoint
# module or class-method spec is needed — just the image build config.
That's true for serving, but spec.class_methods is also the client-side contract: vertexai's agent_engines.get() runs _register_api_methods_or_raise() (vertexai/_genai/_agent_engines_utils.py), which iterates operation_schemas() — backed by spec.class_methods — and returns early when it's empty, so none of the session/query methods get created on the returned object.
Meanwhile the scaffolded container does serve the full contract (app_utils/reasoning_engine_adapter.py dispatches to AdkApp.register_operations()), so the resource metadata and the runtime disagree. The playground keeps working, which is what makes this easy to miss.
Note for anyone landing here from the ADK issue: is_a2a in agents-cli-manifest.yaml is a red herring. At deploy time it only picks the Agent Card URL in the success message and the local metadata file — flipping it to false and redeploying changes nothing about the registered operations. Projects deployed with <= 0.5.x are unaffected, which is why older deployments still work.
Suggested fix
DeployConfig.class_methods is still plumbed through _start_deploy_operation() → client.agent_engines._create_config(...); it's just never populated. So the fix looks small — populate it again in deploy_agent_runtime():
config_kwargs["class_methods"] = ... # the contract the unified container serves
either by restoring the 0.5.x introspection, or by declaring the standard AdkApp contract statically (the same list adk-python sets unconditionally as _AGENT_ENGINE_CLASS_METHODS in cli_deploy.py, which is what the container's reasoning-engine adapter serves anyway).
Environment
- agents-cli 0.6.0 through 1.1.0 (0.5.x deploys still register class_methods)
- google-adk 2.4.0
Workaround
The resource-level call reported to work in the ADK thread: client.agent_engines.sessions.create(name=..., user_id=...) — it doesn't depend on spec.class_methods. Existing resources can also be fixed up by any deploy path that writes class_methods on update.
Summary
Since 0.6.0,
agents-cli deploy(agent_runtime target) creates/updates the ReasoningEngine resource withoutclass_methodsin the spec. The unified container itself serves everything fine (playground, A2A,/api/reasoning_engine), but thevertexaiclient generates theAgentEnginewrapper's Python methods fromspec.class_methods. With it empty:This breaks the documented flow in Use an ADK agent → Create session for every project deployed with agents-cli >= 0.6.0. Downstream report: google/adk-python#6369 (adk-python itself is not at fault —
adk deploy agent_enginesetsclass_methodsunconditionally incli_deploy.py).Root cause
The 0.6.0 unified-container change dropped the class-methods generation from
src/google/agents/cli/deploy/agent_runtime.py:generate_class_methods_from_agent(),_introspect_agent_via_subprocess(), and the"class_methods": ...entry in the deploy config were all removed (git log -S class_methods— 0.5.x still had them). The comment in the current code says:That's true for serving, but
spec.class_methodsis also the client-side contract: vertexai'sagent_engines.get()runs_register_api_methods_or_raise()(vertexai/_genai/_agent_engines_utils.py), which iteratesoperation_schemas()— backed byspec.class_methods— and returns early when it's empty, so none of the session/query methods get created on the returned object.Meanwhile the scaffolded container does serve the full contract (
app_utils/reasoning_engine_adapter.pydispatches toAdkApp.register_operations()), so the resource metadata and the runtime disagree. The playground keeps working, which is what makes this easy to miss.Note for anyone landing here from the ADK issue:
is_a2ainagents-cli-manifest.yamlis a red herring. At deploy time it only picks the Agent Card URL in the success message and the local metadata file — flipping it tofalseand redeploying changes nothing about the registered operations. Projects deployed with <= 0.5.x are unaffected, which is why older deployments still work.Suggested fix
DeployConfig.class_methodsis still plumbed through_start_deploy_operation()→client.agent_engines._create_config(...); it's just never populated. So the fix looks small — populate it again indeploy_agent_runtime():either by restoring the 0.5.x introspection, or by declaring the standard AdkApp contract statically (the same list adk-python sets unconditionally as
_AGENT_ENGINE_CLASS_METHODSincli_deploy.py, which is what the container's reasoning-engine adapter serves anyway).Environment
Workaround
The resource-level call reported to work in the ADK thread:
client.agent_engines.sessions.create(name=..., user_id=...)— it doesn't depend onspec.class_methods. Existing resources can also be fixed up by any deploy path that writesclass_methodson update.