Arrow keys choose a result, Enter opens it, Escape closes. Press / on any page to search.
A pure ADK agent beside an Antigravity SDK agent, part by part: what comes built in, what you switch on, what you write. The depth control in the header adds parts and detail.
Tab reaches every link. The address of a part is #/compare/part-id. The row is highlighted and scrolled into view, and a part deeper than the current depth raises it.
Which one should I use? A few questions in turn end in an answer. The answer names what to use and says why in one sentence. It links to the comparison it rests on and the box on the map.
The answers you give stay above the next question, and you can change them. The address keeps them, so a link opens the guide where you left it. The depth control in the header sets which guides show and how much each answer says.
Tab reaches each question. The arrow keys move between its options and choose one, and the next question or the answer appears below it. A guide's address is #/decide/guide-id&a=1.2: the numbers are the options chosen, in order.
The names people give to the work around an agent, from writing one instruction to wiring many runs into a structure. For each name: what it means, who said so and when, and which parts of ADK and the Antigravity SDK it works on. The depth control sets how much of each entry is shown.
Searched on across the sources above and the web, for three things. The first was "workflow engineering", "orchestration engineering" and "tool engineering" as named disciplines (vendor pages only, none with a definition). The second was a coiner for "intent engineering" (two unrelated definitions exist). The third was "loop engineer" as a job title. The sites adk.dev and antigravity.google use none of the five names on the ladder. The one phrase of the kind on antigravity.google is "agentic engineering platform".
Tab reaches every link. The address of an entry is #/disciplines/entry-id. The section is scrolled into view, and an entry deeper than the current depth raises it.
What happens, in order. Step through each figure with the buttons or the arrow keys. The caption under the figure changes with the step, and the step list below is the same text in full.
Four more flows, the internals (one model call, one Live session, a call through Agent Gateway, a turn of an AntigravityAgent), show at L300.
Nothing in ADK runs to completion in one go. The agent is an async generator that yields an event and pauses. The Runner records that event, applies its side effects and only then lets the agent continue. Every flow on this page that runs an agent or a graph happens inside this loop (one invocation, the hook order, state, a graph run, a graph's pause and resume, and at L300 a model call, a Live session and an AntigravityAgent turn). The deployment path and the gateway call show what is around the loop.
In the map: Runner · Event loop · Event · SessionService · LlmAgent
One call to run_async with one new message is an invocation. This is the common shape: the model asks for a tool, the tool runs, the model answers. Dashed arrows are returns, and every yield is a pause. Every committed event is also streamed to the client, but only the last one is drawn.
In the map: Invocation · Runner · LlmAgent · Tool · Model · Event
Two families of hooks wrap a run: plugins, registered once and global, and callbacks, set per agent. They fire in a fixed order at fixed stages; for every stage they share, the plugin's hook runs before the agent's callback. Returning None continues; returning a value replaces the step.
Every write lands in one store, and the store decides how long it lasts. State is written as deltas and committed by the Runner, and a key's prefix decides how far it reaches; memory and artifacts are written by explicit calls and outlive the conversation.
In the map: State · State scopes · SessionService · Memory Bank · Artifacts
A Workflow runs its graph by triggers, not by the order of its edge list: a node runs when an edge triggers it, from START or from a node that has finished, and what travels along that edge is its node_input. The figure draws two of the example's graphs from support_desk/workflow.py, run as the example's tests run them, offline on a scripted model: steps 1 to 7 are one run of refinement_loop, a pipeline that a routed edge closes into a loop, and steps 8 and 9 one run of enrichment_workflow, a fan-out gathered by a JoinNode.
In the map: Workflow (graph) · Workflow nodes · Routes · JoinNode · Custom agent · State · Runner
A node that needs a person yields RequestInput, and the graph stops there: the call to run_async ends with the request in the session, and nothing runs until the person answers. The answer comes in a second call, which resumes the same invocation: the workflow runs again from START, skips what finished, and the waiting node takes the answer. The figure draws adk-python's request_input sample, run offline on a scripted model: steps 1 to 5 are the first call, 6 to 8 the second, and step 9 the setting that makes the waiting node run again.
In the map: Resumability · Workflow (graph) · Workflow nodes · Invocation · Event · Runner
The deployment path on Agent Platform, with the alternative targets beside it. Old names survive in identifiers: the resource is a ReasoningEngine, the CLI target is agent_engine, the environment variable says AGENT_ENGINE.
In the map: agents-cli · Container image · Agent Runtime · /api passthrough · Gemini Enterprise · Agent Gateway · Cloud Run · GKE
What an LlmAgent does between taking the turn and yielding its answer, as the 2.14 source has it. One pass down the middle is one model call; the arrow on the right is the loop. The hooks on the left run for every plugin first, then for the agent's own callbacks.
In the map: LLM flow · LlmRequest and LlmResponse · PluginManager · Callbacks · Model · Tool · LlmAgent
A voice agent does not take turns through run_async. The client opens one long call, run_live, and feeds it through a queue while events stream back. Dashed arrows travel towards the client. The path is experimental in ADK 2.14.
In the map: Live and voice agents · Streaming · RunConfig · API server · LLM flow · Model
An agent on Agent Runtime that is bound to a gateway sends every outbound request through it. One tool call therefore meets the gateway twice: first as a function call in the model's response, where Semantic Governance (preview) can remove it, then as the request to the tool, where the access policy, the registry and Model Armor decide. Dashed arrows are returns.
In the map: Agent Gateway · Agent Identity · IAM access policies · Agent Registry · Model Armor · Semantic Governance
ADK runs an Antigravity SDK agent through AntigravityAgent: the SDK's harness, a local program, runs the loop, and ADK turns its steps into events. One turn opens a fresh SDK agent and so a fresh harness process, resumes the conversation by the id ADK kept in session state, and closes it again. Dashed arrows are returns.
With focus inside a flow: → and ← step, Home and End jump to the overview and the last step. A step's address is #/flows/event-loop&step=3.
Every term with its one-line job, depth and Python symbol. The depth control in the header hides terms and comparisons deeper than the chosen level. The search box below narrows the table by name, alias, symbol or definition.
| Definition | Symbol | Docs |
|---|
Google renamed the platform and several services on 22 April 2026. Code, URLs and many environment variables keep the old identifiers, and this table maps them.
| Was | Is now | Since | Still in code |
|---|
Side by side, the choices the map cannot show at a glance.
Tab reaches the search box, the category filter, the column sort buttons and every link. The address of a term is #/glossary/term-id. The row is highlighted and scrolled into view.
A visual guide to the Agent Development Kit (Python) and to the managed services that an agent meets after it leaves your laptop. The guide also shows the Antigravity SDK beside ADK, and how ADK runs such an agent. The harness of the SDK (the program inside the package that runs the loop of the agent) brings much of what an ADK agent leaves to you. Read the guide at four depths. The control in the header sets how much the map, the flows, the comparison, the glossary and the disciplines show. On a reading path, the control opens the path of that depth.
New to ADK: start with the L50 path, ten stops in about fifteen minutes. Building agents already: the L100 path, then the L200 path. Facing a choice: the decision guides answer it in a few questions.
To find one thing, use the Search button in the header, or / on any page. The search finds a concept by any of its names, old product names included. It also finds a flow, a comparison, a decision guide or an error message pasted whole.
Facts are pinned to the versions above. Where Google marks something preview, the guide says so.
The introductory path: what each piece is and why it exists, in the order a newcomer should meet them. Every stop opens a view with the depth set to L100. While the depth stays there, the Paths link in the header returns you here.
Start the tour The seventeen stops below one at a time, for a talk. Each stop opens its view, with its words large at the foot of the screen. Each question under Check yourself comes after the stop it rests on, for a show of hands. Right arrow or Page Down goes to the next step, and Left arrow or Page Up goes to the step before. The A key shows the answer to a question, and Escape leaves the tour. The bar can switch the questions off, and it has a full screen button where the browser allows one.
Start with LlmAgent, the thing you write: a model, an instruction, a description, and the tools and sub-agents that it may use. The model decides the next step. Everything else on the map exists to run, structure or persist that decision.
A tool is a function with a schema the model can decide to call. Follow the four kinds: your own FunctionTool, Google's built-in tools, whole toolsets from an MCP server, and another agent called like a tool (a sub-agent in single_turn mode, or the older AgentTool).
Every message, tool call, tool result and final answer is an Event. The actions it carries, a state change or a transfer, are what the runtime applies.
The Runner takes an agent (or an App), a session service and optional artifact and memory services, and runs one user message at a time. Note the three services that the Runner uses. Everything persists in these services.
Step through the event loop. The agent yields an event, and the Runner commits the event through the services. The Runner forwards the event to the client and lets the agent resume. Nothing runs to completion in one go.
Step through one invocation: run_async, the session is loaded, the model asks for a tool, the tool runs, the model answers. Count the yields: each yield is a pause.
A Session is one conversation thread with its events and its State. The SessionService decides where the session lives. While you develop with adk web, the session is in a SQLite file in the agent's .adk folder. In tests, the session is in process memory. Other options are a database, or Agent Platform Sessions when deployed. The agent code is the same in each case.
The state of a session ends with the conversation, but user: and app: keys keep a few exact values longer. Memory is what the agent should be able to search for next week. Artifacts are the files that a conversation produces. Both have a development version (memory in the running program or a SQLite file, artifacts in the .adk folder) and a managed version in production.
If the order of steps must not depend on the judgement of the model, draw the order. A graph Workflow has nodes, edges and routes, and its nodes can be agents. Inside an LlmAgent, a second agent joins as a sub-agent: the model transfers to it, or calls it like a tool in single_turn mode.
Look at the four ways one agent calls another, at seven common patterns, and at agents inside a graph. Each picture has one sentence, and from L100 it also says what you write.
The same agent can hold a call. The run_live method keeps a two-way connection open. The user speaks and can interrupt, and the agent answers aloud and sees camera frames. Voice agents for support lines, shops and games work this way. Try it with the microphone in adk web. LiveKit connects the agent to phone calls, and Live is experimental in ADK 2.14.
adk create, adk web, adk run, adk eval, adk deploy. The dev UI is the local window into sessions, state, events and traces. Evaluation replays recorded conversations and scores them.
Agent Runtime hosts your agent as a container, scales it and switches the session service to the managed one. Cloud Run and GKE take the same container with more control and more to manage. Gemini Enterprise is where end users meet the result.
Three choices come first: where the agent runs, where its conversations live, and how one agent involves another. Each decision guide asks a few questions and ends in an answer. The answer links to the comparison table and the box on the map. Start with the deploy target. Its answer continues to the session service.
On this path, you assembled the agent, its tools, the session store and the deploy, but the Antigravity SDK ships an agent already assembled. A harness inside the package runs the loop with file, web, image and subagent tools on. The harness refuses shell commands, and keeps and compacts the conversation in a folder by itself. Read the Compare view at this depth with two questions. What does the harness do that ADK leaves to you, and what does ADK have that the harness lacks, such as a place to deploy? ADK runs such an agent as one of its own, and the L200 path shows how.
Read the five names of the ladder with their definitions and dates. For each name, see who named it, what it covers and leaves out, and what Google says with it. Google's ADK team adopted context engineering in its own words. The adk.dev site itself uses none of the five names. So this page is where the vocabulary of the trade meets the vocabulary of the docs.
Google renamed the platform in April 2026. Finish with the crosswalk so the old identifiers in code, agent_engine, VertexAiSessionService, reasoningEngines, stop being a surprise.
Seventeen stops, about an hour. When they feel familiar, switch the header to L200 and take the L200 path. That path goes under the same boxes: callbacks and plugins, hook order, state scopes, and the road from a container to a published agent.
Questions on what the stops above show: why something happens, what comes next, which part fits. Choose an answer: the page says at once whether it holds and why, and links the place the answer is read from.The answers follow the questions, each with why it holds and where it is read from.
Loading the questions.
The technical path: how the pieces fit, configure and deploy. It goes under the same boxes the L100 path visited; every stop opens a view with the depth set to L200.
Start the tour The twenty-five stops below one at a time, for a talk. Each stop opens its view, with its words large at the foot of the screen. Each question under Check yourself comes after the stop it rests on, for a show of hands. Right arrow or Page Down goes to the next step, and Left arrow or Page Up goes to the step before. The A key shows the answer to a question, and Escape leaves the tour. The bar can switch the questions off, and it has a full screen button where the browser allows one.
Read the L200 description: model, instruction with {state} templating, tools, sub_agents, output_schema and how it works alongside tools, output_key, include_contents, planner, code_executor, the eight callbacks, and 2.0's mode. Then follow the Connected list, where Agent Config is the same agent declared in YAML instead of Python.
Step through the hook order: plugins first, then the agent's callbacks, at every stage they share. Note which hooks exist only on plugins (on_user_message, before_run and after_run, on_event, on_agent_error, on_run_error), and that the model and tool error hooks exist on both.
The comparison table is the cheat sheet: scope, registration, hooks, order, typical use.
Step through state scopes: a write becomes a delta on an event, the Runner commits it, and the prefix decides whether it is temporary, session-wide, per user or app-wide. Memory and artifacts are the stores that outlive the session.
InvocationContext for the agent, Context (formerly CallbackContext and ToolContext) for callbacks and tools: state, actions, artifacts, memory, confirmation, credentials.
Nodes, edges, routes, JoinNode, parallel workers, human-input nodes, retries. Then look at task mode for structured delegation.
The refinement loop, then the fan-out. Each node's output is the next node's node_input, and each event is in the session before the node goes on; the gate's route sends the draft back until the reviewer passes it, and a JoinNode waits for both branches of a fan-out, then hands on their outputs in one dict.
AgentTool keeps control, transfer hands it over, task mode delegates with typed input and output and returns through finish_task.
Customers name a design by its pattern: coordinator, pipeline, fan-out and gather, generate and review, refinement loop, human in the loop. The table says what builds each in ADK 2.14, a graph Workflow or the modes of sub-agents, and links the box and the flow step that show it.
Toolsets (MCP, OpenAPI, Skills), confirmation gates, long-running tools, authentication, and the code executors from model-side to a managed sandbox.
ResumabilityConfig lets an agent's turn pause on a confirmation, request_input or a long-running tool and continue later by invocation id; a graph Workflow at the root pauses and resumes without it. Rewind restores a session to before an invocation.
adk-python's request_input sample, paused and answered. A node's RequestInput ends the call with the request in the session; the answer, a FunctionResponse with the request's id, resumes the same invocation, where the nodes that finished are skipped and the waiting node takes the answer as its output, unless rerun_on_resume runs it again.
One FastAPI app, one Runner: /run_sse, session routes, /a2a/{app}, optional trigger endpoints, the dev UI when enabled. RunConfig sets streaming per request.
Step through the deployment path: deploy packages, Agent Runtime builds and runs the container with the runtime contract, managed sessions, identity and registry; clients call :streamQuery or the /api passthrough; publish registers in Gemini Enterprise.
Agent Runtime, Cloud Run and GKE side by side: who manages what, sessions, scaling, billing, limits, gateway binding, how each publishes.
Build, Scale, Govern, Optimize. Click through Agent Gateway, Agent Identity and Agent Registry on the Govern row, then Cloud Trace, Agent Observability and Agent Platform Evals on the Optimize row.
Evalsets, criteria, the dev UI recording cases, adk eval and AgentEvaluator, user and environment simulation, prompt optimisation with adk optimize, and the managed service that agents-cli eval grades on.
Identity scope, tool checks, Gemini filters, callback and plugin screens, Model Armor in code or at the gateway, sandboxes, VPC-SC.
Ten questions a review asks, from who can call the agent and whom it acts as to whether one user can read another's sessions, where the data lives and what Google keeps. Each row answers for the platform and for ADK 2.14 and agents-cli 1.13, with the status the pages give, and links the boxes that own its facts. Start at the first row: IAM Conditions bind principals, and the users one agent serves are kept apart by the user id it is given.
The error messages readers of ADK's issue tracker meet most, each traced to the piece it comes from: the session's app name, an MCP session's task, a tool's declaration, the history a request is built from, a state key in an instruction, what a deploy installs, the model's quota. Each row says the versions it applies to and what to change; a message pasted into Search lands on its row.
Twenty stops, about a hundred and ten minutes with the docs open beside them.
Five more stops, about an hour: the SDK agent that runs its own loop, read against the ADK parts the twenty stops above have set out, the disciplines that name the levers, and two choices to decide.
AntigravityAgent, from ADK's labs, wraps an Antigravity SDK config. The SDK's harness runs the loop and owns the conversation; ADK sends it the user's text and turns the steps that come back into events. The class takes no instruction, model or tools; those sit in the config. As the Runner's root it keeps one conversation per session through save_dir; with mode single_turn it is a sub-agent that its parent calls as a tool. The lens is on: the marks on the boxes say which parts the harness brings and which stay yours.
At this depth the comparison has its third column, the SDK agent inside ADK. Read it for the seams: ADK's model and tool hooks never fire, max_llm_calls is not enforced, the two state stores stay apart, only the first text part of the user's message is sent, partial events arrive only under SSE. What the harness refuses or sandboxes is decided by the SDK's policies, not by ADK's confirmation.
Antigravity reaches ADK by two roads: AntigravityAgent starts the SDK's harness on your machine, ManagedAgent calls an agent hosted by Google through the Managed Agents API. The table sets the two classes side by side: where the loop runs, what a turn sends, what ADK keeps to continue, tools, credentials, what a failure looks like, status.
At this depth every entry on the Disciplines page lists the parts of ADK and the SDK it works on, each linked and with the lever named: the fields of LlmAgent for prompt engineering, the context stack for context engineering, the Runner, App, hooks and evals for harness engineering, triggers, bounds and resumability for loop engineering, the graph for graph engineering. Read harness engineering first; it is the one whose shape the comparison already drew.
At this depth the decision guides add two to the three of L100: pure ADK, the Antigravity SDK or the SDK agent inside ADK, and a callback or a plugin. Walk the first with the comparison fresh in mind: each answer says why in one sentence read from the compare rows and the package, and links to the rows it rests on.
The L300 path goes under these concepts, into the internals and into operations.
Questions on what the stops above show: why something happens, what comes next, which part fits. Choose an answer: the page says at once whether it holds and why, and links the place the answer is read from.The answers follow the questions, each with why it holds and where it is read from.
Loading the questions.
The advanced path: what happens inside, and what it takes to run an agent in production. It is for the person who writes plugins and custom nodes, debugs one turn, or operates agents behind a gateway. Map stops open at depth L300, where a box shows its L200 entry and then, marked L300, what the internals add.
Start the tour The eighteen stops below one at a time, for a talk. Each stop opens its view, with its words large at the foot of the screen. Each question under Check yourself comes after the stop it rests on, for a show of hands. Right arrow or Page Down goes to the next step, and Left arrow or Page Up goes to the step before. The A key shows the answer to a question, and Escape leaves the tour. The bar can switch the questions off, and it has a full screen button where the browser allows one.
Step through an LlmAgent turn as the 2.14 source has it: the flow, the twelve request processors, the hooks before and after the model, the tool calls, and the loop back. One pass is one model call.
Read LLM flow, then LlmRequest and LlmResponse beside it: which processors run in which order, what contents holds and what it leaves out, when the loop ends, and where max_llm_calls is counted.
Fourteen hooks, plugins asked in registration order, the first answer ends the round. Then open Callbacks at this depth for what counts as an answer at each hook and what an answering hook skips.
A root LlmAgent or Workflow runs in a task of its own and hands its events over through a queue; a node waits until its event has been appended. Follow the Connected list to Event loop, Invocation and SessionService for what that guarantees.
How the calls of one response run together and come back as one event. Then Tool confirmation and Tool authentication: both end the turn with a synthetic function call that the client answers.
Workflow is its own scheduler: one task per triggered node, what a node with several predecessors receives, what fails a run. Workflow nodes, Routes, JoinNode and Parallel workers each add their rules.
ctx.run_node runs a child and, on resume, takes its result from the session, so loops are plain Python. RetryConfig gives the defaults, the delays and what a timeout raises; Resumability says why a graph resumes by replaying the session, not from a snapshot.
Step through a turn of the agent that runs on the Antigravity harness: the conversation id read from session state, a deep copy of the SDK config with one tool per ADK sub-agent, a fresh SDK Agent started for the turn, the first text part sent, each step converted to events, the id yielded as an event of its own, and what a harness error leaves behind. Count which of ADK's hooks the turn passes and which it never reaches.
The Antigravity SDK at this depth, as the 0.1.23 source has it: how the binary is found and started, the handshake over stdin and stdout and the WebSocket after it, why every strategy is local, where a built-in tool runs and where a Python callable does, which policy rules are decided in the binary and which call back, what save_dir holds and what resuming needs. Then AntigravityAgent for the generator path the Runner takes with it, the bridged sub-agent's own Runner, and the two statuses the two packages give it.
Step through a voice session: run_live with a LiveRequestQueue, one connection, two tasks side by side, an interruption, a tool call, and what the session keeps when the turn completes.
What does not apply in a Live session and where its limits come from. Then RunConfig for the Live settings, Streaming for how the event flags read there, and API server for the /run_live WebSocket.
Which updates create a revision, what is fixed at creation, the instance limits. Then Private networking: the PSC interface and DNS peering, VPC Service Controls and CMEK.
The Managed Agents API and the part of it that ADK's ManagedAgent uses. Then Skill Registry, and why ADK reads the skills of Agent Registry instead; Agent Skills has the skill lifetimes that 2.10 added.
Step through an outbound tool call of a bound agent. It meets the gateway twice: as the model's proposal, which Semantic Governance can remove, and as the request, which IAP checks, Agent Registry matches and Model Armor screens.
Agent Gateway, Agent Identity and Agent Registry at this depth, then IAM access policies, Semantic Governance and Model Armor: who may reach what, what a policy can see, and what each refusal looks like.
What adk eval does with a case and when a case passes. Evalsets and Eval criteria have the files and the seventeen metrics; Agent Platform Evals says which agents-cli command runs on your machine and which on the service.
Scenario cases that a model plays, tool results faked by environment simulation, and adk optimize searching for a better root instruction. The optimiser is experimental, and all of it runs on your machine.
At L300 each entry gives the definitions as their sources wrote them, the unit of work each name claims, how the sources relate the rungs and where they disagree: whether harness engineering sits inside context engineering or delivers it, who coined what, and whether loop and graph engineering are disciplines or renamed cron jobs and a meme. Every quote carries its date; open the sources under each entry.
Eighteen stops, about five hours with the source and the docs open beside them, best taken in several sittings. An L300 entry names the class, field or command it describes, so that it can be checked against ADK 2.14.0 and the platform docs; what the package deprecates is left out. The L200 path covers the same boxes one level up.
Questions on what the stops above show: why something happens, what comes next, which part fits. Choose an answer: the page says at once whether it holds and why, and links the place the answer is read from.The answers follow the questions, each with why it holds and where it is read from.
Loading the questions.
At a glance: the fourteen boxes that a first conversation about ADK needs, in reading order. Eight stops are on the map, then come the Compare view and the Disciplines page. Every stop opens with the depth set to L50. While the depth stays there, the Paths link in the header returns you here.
Start the tour The ten stops below one at a time, for a talk. Each stop opens its view, with its words large at the foot of the screen. Each question under Check yourself comes after the stop it rests on, for a show of hands. Right arrow or Page Down goes to the next step, and Left arrow or Page Up goes to the step before. The A key shows the answer to a question, and Escape leaves the tour. The bar can switch the questions off, and it has a full screen button where the browser allows one.
The box you write. The agent names a Gemini model, says in an instruction what the agent is for, and lists what the agent may use. On each turn, the model reads the conversation and decides: answer, call a tool, or transfer the conversation.
A tool is anything the agent can call. A tool can be one of your functions, a Google tool such as search, or another agent. A tool can also be a set of tools that another program offers over MCP, the common way that tool servers describe their tools. The model sees only names and descriptions, and chooses by them.
An agent can transfer the conversation to a specialist that it lists as a sub-agent. Most real systems take this shape: a coordinator that routes to a billing agent and a technical agent.
You never call the model yourself. The Runner loads the conversation, calls the agent, saves every step and streams the results to you. Any host of the agent, your laptop or Google's runtime, drives the agent through a Runner.
A Session is one conversation with a little state attached. The session ends when the conversation ends. Memory is what should still be known next week, per user. During development, a file in your project keeps the conversations, and the running program keeps memory (or a file, if you ask). In production, managed services keep both.
The adk command line creates a project and opens a browser window. In that window, you chat with the agent and inspect every step. The command line also runs evaluations and deploys the agent. The code is the same before and after.
Evaluation replays recorded conversations and scores the answers and the tool calls. The loop is: change the instruction, run the evaluation, read the score. The loop runs before each deploy.
Agent Runtime is Google's managed host. Agent Runtime packages your code, runs the agent at a web address and scales the agent. Agent Runtime also connects managed Sessions and Memory Bank. When you publish the agent, employees find it in Gemini Enterprise. All of these services are the Gemini Enterprise Agent Platform, the band at the bottom of the map.
Google also ships an agent that comes assembled. The Antigravity SDK runs the loop of the agent in a harness, a program inside the package. File tools, helper agents and a rule set are already on. The Compare view puts this agent beside a pure ADK agent, part by part: what each build brings, what you switch on, what you write. ADK can run such an agent as one of its own, and the deeper paths show how.
Prompt engineering, context engineering, harness engineering, loop engineering, graph engineering: five names. Each name covers a bigger piece of the work than the one before, from writing one instruction to wiring many runs together. The Disciplines page says what each name means in plain words, and who said so and when. The page also links each discipline to the boxes that it works on.
Ten stops, about fifteen minutes. The L100 path then adds the names behind each box: events, state, the session service, graph workflows, the kinds of tools.
Questions on what the stops above show: why something happens, what comes next, which part fits. Choose an answer: the page says at once whether it holds and why, and links the place the answer is read from.The answers follow the questions, each with why it holds and where it is read from.
Loading the questions.
The layered picture of an ADK agent and everything it runs on: what you write at the top, the managed services at the bottom. The header sets the depth. Click a box or use the index for its definition, symbol and docs.
Tab reaches the map. Arrow keys move between boxes, Enter selects, Esc clears, [ and ] walk along the connections. To let go of a box with the mouse, click it again, click the empty ground, or use Clear selection in the panel. The address of a box is #/map/id. Add &l=200 for depth.
Simple pictures of how agents work together. The first part shows the four ways one agent calls another. The second part shows seven common patterns, and the third part shows agents inside a graph. A rounded box is your agent or your function, and a plain box is a person or the start of a graph. A dashed arrow is a return.
At L50 each pattern has one sentence. From L100 it also says what you write. The glossary and the map have the detail.
An agent can give work to another agent in four ways. The four ways differ in who talks to the user and in how control comes back.
The parent gives the whole conversation to a specialist. The specialist talks to the user until it transfers back.
List the specialist in the parent's sub_agents and set no mode. The model calls transfer_to_agent when the description of the specialist fits the request. The specialist sees the whole conversation and the session state. Control comes back only with another transfer.
The parent asks a specialist to do one task. The specialist can ask the user questions, then it returns a result.
Set mode='task' on the sub-agent. The model of the parent calls the specialist as a tool with typed input. The specialist works with the user until it calls finish_task. The parent gets that result and keeps the conversation.
The parent asks a specialist for one answer. The specialist does not talk to the user. Several specialists can work at the same time.
Set mode='single_turn' on the sub-agent. The model of the parent calls the specialist as a tool. The specialist gets only the arguments of the call and returns its reply as the result. It shares the session state with the parent. ADK prefers this mode to AgentTool. Set disallow_transfer_to_parent=True and disallow_transfer_to_peers=True on each helper. Otherwise a model can try a transfer instead of an answer, and the parent then calls the helper again.
The parent uses another agent like a tool. The other agent works in a separate session and returns a result.
Put AgentTool(agent=…) in the tools of the parent. The call runs the agent with its own Runner and a new session. The agent gets a copy of the state and returns its last reply. ADK copies its state changes back. One agent can serve many parents this way.
Seven common patterns, built from the four ways above or from a graph. With sub-agents, the model chooses the next step. In a graph Workflow, your edges choose the next step.
One agent reads each request and sends it to the right specialist.
The coordinator lists the specialists in sub_agents. Its model reads the description of each specialist and transfers the request to the best match. In a graph, a ClassifierNode makes the same choice and gives a route.
Agents run one after another. Each step uses the result of the step before.
Write the steps as one chain of edges in a graph Workflow. Each agent saves its result in state with output_key. The next agent reads that result in its instruction.
Several agents work at the same time. One step then collects all their results.
In a graph Workflow, give one node edges to several nodes. These nodes run in parallel. A JoinNode waits for all of them, and the next node uses all the results.
A root agent divides a large job. Managers divide their parts again for their workers.
Each level lists the level below in sub_agents. With mode='task', each manager gets a typed task and returns a typed result. The root agent keeps the conversation with the user.
One agent writes a draft. A second agent checks it.
The writer saves its draft in state with output_key='draft'. The reviewer reads {draft} in its instruction and gives its review. In a graph, the two agents are one chain of edges.
A writer and a reviewer repeat until the draft is good enough.
A routed edge goes back from a gate to the writer. The gate gives the route revise or done from the review. Count the rounds in state, and stop after a maximum.
The run stops and asks a person. The answer of the person continues the run.
A graph node yields RequestInput, and the run pauses. The client sends the answer of the person, and the run resumes at that node. A tool can also ask for a confirmation with require_confirmation=True.
An agent in a graph can have helpers, can ask the user, or can run a graph of its own. The mode of each agent decides what it can do. Each picture here was run on ADK 2.14.
One step of a graph calls helper agents and uses their answers. Then the graph goes on to the next step.
Give the agent of the step sub_agents with mode='single_turn'. The step stays a single-turn node, and it calls each helper as a tool. The helpers answer only the step, and several helpers can run at the same time. Do not give the step a helper in task mode. A single-turn step never starts that helper, and a real model then calls it again and again. Set disallow_transfer_to_parent=True and disallow_transfer_to_peers=True on each helper. Otherwise a model can try a transfer instead of an answer, and the parent then calls the helper again.
One step of a graph talks with the user until it has what it needs. Then the graph goes on.
Make the step an agent with mode='task'. The graph waits at that step between messages. When the agent calls finish_task, its result goes to the next step, and output_key also saves the result in state.
An agent runs a whole graph like one tool. The agent gets the result of the last step.
Put a Workflow in the tools of the agent. The model calls the graph by its name, and the graph runs its steps in order. The output of the last step comes back as the result of the tool.
A step can give the conversation to a specialist, but only for one turn. On the next message, the graph starts again at the beginning.
An agent node with sub_agents can call transfer_to_agent. The specialist answers, and the next step runs in the same turn. On the next message, the graph starts again at START. Use a step in task mode when the step must keep the conversation.