go-adk

google.golang.org/adk

When to trigger

• The user mentions Go ADK,

  google.golang.org/adk

  ,

  adk-go

  , or asks how to build agents in Go.
• The task involves ADK concepts like

  llmagent

  , tools, callbacks, sessions/state/memory, workflow agents, streaming, MCP, A2A, ADK web/API runtime, launchers, deployment, evaluation, or safety controls.

Core rules

• Treat references/llms-index.md as the required ADK coverage map.
• Prefer official ADK Go APIs and examples over ad-hoc wrappers.
• Follow existing repository patterns first (imports, launcher style, layout, env handling).
• For version-sensitive behavior, check release notes and API reference before giving definitive guidance.
• Prioritize Go-specific ADK docs first; if a feature is documented only in another SDK doc, call that out explicitly.
• Keep agent names unique and never use

  user

  as an agent name.
• Use concise

  Description

  fields so delegation and tool selection remain reliable.
• Treat ADK Web as development-only unless the user explicitly asks for production runtime choices.

Workflow

1. Map task to ADK domain:
   • Build, run, deploy, evaluate, safety, components, protocols, or reference.
   • Load only the relevant sections from references/llms-index.md.
2. Confirm execution style:
   • Launcher-first app (

     cmd/launcher

     ,

     cmd/launcher/full

     ) or embedded runtime (

     runner.Run

     loop).
   • Local dev UI, CLI-only, or REST/API server flow.
3. Build the first working agent:

   • llmagent.New(llmagent.Config{...})

     with a concrete model (commonly

     gemini.NewModel(...)

     ).
   • Add minimum viable

     Instruction

     ,

     Description

     , and

     Tools

     .
4. Add tools safely:
   • Use

     functiontool.New(...)

     for typed custom tools.
   • Use

     geminitool.GoogleSearch{}

     or other ADK/native integrations only when needed.
   • For sensitive tools, apply confirmations, auth, and policy callbacks.
5. Wire stateful execution:
   • Sessions via

     session.Service

     (often

     session.NewInMemoryService()

     for local dev).
   • Add

     memory.Service

     only when cross-session retrieval is required.
   • Add state/context/artifacts management only when required by the workflow.
6. Apply control points:
   • Use callbacks (

     Before/After Model

     ,

     Before/After Tool

     , agent callbacks) for logging, caching, guardrails, and overrides.
   • Prefer plugins for reusable security policy enforcement.
7. Scale composition:
   • Use workflow agents for deterministic orchestration (

     sequentialagent

     ,

     parallelagent

     ,

     loopagent

     ).
   • Use multi-agent delegation (descriptions + transfer behavior) only when specialization is clear.
8. Select runtime/deployment posture:
   • Local dev: CLI/Web/API.
   • Production: deployment target + observability + safety posture.
9. Verify behavior end-to-end:
   • Validate happy-path conversation, tool errors, callbacks, session resume/rewind behavior, and evaluation criteria.

Output expectations

• Provide exact Go imports, runnable snippets, and command lines that match the chosen runtime mode.
• Call out version-sensitive behavior if the user targets older ADK tags.
• Mention the relevant ADK doc section when guidance comes from

  llms-index

  categories beyond core Go quickstart pages.
• Prefer small, testable incremental changes over large rewrites.

References

• Quickstart and launcher baseline: references/quickstart.md
• Core APIs and agent config: references/core-primitives.md
• Tools, callbacks, and guardrails: references/tools-and-guardrails.md
• Runtime modes, examples, and A2A: references/runtime-and-examples.md
• Required ADK source map (

  llms.txt

  mirror): references/llms-index.md