Design Google ADK Python agents with ak:google-adk-python

Use ak:google-adk-python when the deliverable is a Python agent or agent system built with Google's Agent Development Kit. The Skill covers agent and workflow architecture, tools and MCP, A2A communication, sessions and memory, callbacks and plugins, evaluation, and deployment preparation.

The packaged guidance is not a framework lock. ADK releases and provider APIs can change independently of the Kit, so verify the installed google-adk version and its matching official documentation before relying on an example.

Choose ak:google-adk-python for ADK work

Use ak:google-adk-python when

• You need a single Agent or a sequential, parallel, or loop workflow.
• The agent needs custom tools, filtered MCP tools, sub-agents, sessions, state, memory, artifacts, callbacks, plugins, or observability.
• You need an evaluation plan or deployment-ready design for Cloud Run, Vertex AI Agent Engine, or GKE.
• You can define the provider, data boundary, tool authority, and measurable behavior the agent must satisfy.

Choose another workflow when

• You have not selected Google ADK or Python as the implementation framework.
• You only need to consume an existing MCP tool from the current assistant.
• You want a conceptual agent brief without code or environment changes.
• You expect the Skill to choose a current model, deployment price, region, or platform configuration without live verification.

Prepare the Python project

Before you start:

• Complete Onboarding and install Marketing Kit for the current runtime and scope.
• Use Python 3.10 or later; the packaged guidance recommends 3.11 or later for development. Follow the project's existing environment and lockfile.
• Confirm whether google-adk is already pinned. Installing or upgrading it changes the environment and may change APIs; approve that separately.
• Record the installed framework version and inspect its command help and documentation before copying a packaged example.
• Define provider credentials, project and region, tool permissions, storage, network exposure, and data-retention constraints without placing secrets in source or prompts.
• For a runnable ADK package, preserve the convention that __init__.py imports the agent module and agent.py exports root_agent or app.

See Runtime adapters for runtime differences.

Start with a bounded agent contract

/ak:google-adk-python Design a Python ADK agent in ./agents/brief-reviewer that reviews a supplied campaign brief, uses no network tools, exports root_agent, adds focused tests and an evaluation fixture, and does not install packages or deploy

/ak:google-adk-python Design a Python ADK agent in ./agents/brief-reviewer that reviews a supplied campaign brief, uses no network tools, exports root_agent, adds focused tests and an evaluation fixture, and does not install packages or deploy

$ak:google-adk-python Design a Python ADK agent in ./agents/brief-reviewer that reviews a supplied campaign brief, uses no network tools, exports root_agent, adds focused tests and an evaluation fixture, and does not install packages or deploy

Follow the ADK stages

1. Confirm the contract. Define input, output, tool authority, provider, storage, privacy, latency or reliability constraints, and acceptance tests.
2. Inspect the environment. Record Python and google-adk versions, project structure, dependency manager, and available credentials without exposing secret values.
3. Choose the architecture. Use an LLM agent for dynamic routing or a sequential, parallel, or loop agent for predictable orchestration. Add sub-agents only when responsibilities are distinct.
4. Implement the package convention. Export root_agent or app, keep tools focused, filter MCP tools, and select session, artifact, or memory services deliberately.
5. Add controls and evidence. Use callbacks or plugins for observable guardrails, then run focused tests and an evaluation set that measures the stated behavior.
6. Prepare, do not assume, deployment. Produce deployment configuration or a runbook only after checking the installed SDK and platform. Execute cloud changes only under a separate approval.

Keep tool, provider, and cloud effects explicit

Never hard-code provider keys or database credentials. Use the target platform's approved secret mechanism and least-privilege identities. A tool confirmation pattern is only useful when sensitive operations are actually gated; test denial and failure paths as well as the happy path.

Verify the outputs

A complete implementation should provide:

• The ADK package and the exported root_agent or app.
• Recorded Python and google-adk versions plus dependency changes.
• Agent, tool, workflow, session, memory, artifact, and network boundaries.
• Focused tests and evaluation results tied to the acceptance criteria.
• Callback, plugin, or observability evidence where required.
• Deployment files or instructions clearly separated from any executed cloud mutation.
• Remaining provider, SDK-version, credential, model, region, or quota dependencies.

Troubleshoot and understand limits

The Skill provides framework guidance, not a guarantee that every packaged API example matches every ADK release. It does not guarantee model availability, deployment success, performance, price, or provider compatibility. Continue with Marketing Agents to understand packaged roles.