Google Agent Patterns

When you read documentation, blog posts, or job descriptions about building agents, you’ll quickly notice different vendors use different words for the same concepts. Anthropic talks about agents, workflows, tool use, and augmented LLMs. Google uses “extensions,” “grounding,” and an explicit “orchestration layer.” These are largely the same building blocks described with different emphasis — understanding Google’s framing strengthens your agent design across platforms.

​

Core capabilities Google expects from an agent

Google defines an agent as a system with three core capabilities:

• Use tools to interact with external systems.
• Maintain memory across interactions.
• Reason and plan to accomplish goals.

These align with general agent design patterns (tooling, memory, reasoning), but Google highlights two specific ideas Anthropic emphasizes less: grounding and an explicit orchestration layer.

​

Two ways to use tools: extensions vs function calling

Google separates agent tool use into two patterns:

• Extensions
  • The model calls an external API or service directly.
  • The model decides when to call the tool, constructs the request, and consumes the response.
• Function calling
  • The model emits a structured specification of the intended call (for example, a function name and arguments).
  • Your application receives that specification, validates and executes the operation, and returns the result to the model.

Function calling is the dominant pattern for production systems because it gives your application more control: validate inputs, apply authorization, sanitize or constrain actions, log requests, and enforce safety policies. For these reasons, many production agents prefer function calling to reduce risk and improve observability.

​

Grounding: tie responses to verifiable data

One of Google’s important contributions is the explicit concept of grounding: connect agent outputs to verifiable data sources rather than relying only on the model’s internal knowledge. Grounding reduces hallucinations and improves trust. Two common grounding approaches:

• Grounding with search
  • Issue web, enterprise-search, or knowledge-base queries prior to answering.
  • Condition responses on retrieved documents and cite sources.
• Grounding with data stores
  • Query a specific dataset (company documents, product catalogs, internal knowledge base).
  • Generate answers from authoritative sources stored in your systems.

A grounded agent is less likely to invent facts because its answers are tied to retrievable evidence and can provide citations.

​

The orchestration layer: the agent loop made explicit

Google also emphasizes an orchestration layer that coordinates the agent loop. The orchestration layer typically:

• Accepts user input.
• Decides whether to call tools and which ones.
• Executes or delegates tool calls (often via function calling).
• Reads and writes memory.
• Produces the final response to the user.

Think of orchestration as the glue connecting model reasoning, tools, and memory — an explicit component that enforces separation of responsibilities, observability, and system-level controls.

​

Quick terminology mapping

Use this mapping when you read different vendor materials so you can translate ideas and design patterns between platforms.

​

Further reading and references

• Google AI documentation on agents and grounding — see Google’s official docs for patterns and best practices.
• Anthropic developer materials for agent and workflow design.
• Research and production best practices for retrieval-augmented generation (RAG), function calling, and agent orchestration.

If you want, I can produce a reference architecture or a small example orchestrator (pseudocode) that demonstrates function calling, grounding queries, and memory reads/writes. Which would you prefer next: architecture diagram, pseudocode, or a sample implementation?