Google uses prompts for translation to solve the challenge of agent extension

Google Unveils a New Approach to Taming Agent Complexity

In mid‑July, the Google Developers Blog published an unassuming technical article titled “Building scalable AI agents with modular prompt transpilation.” Don’t be fooled by the “tutorial” façade—it’s actually distilled from the pitfalls Google encountered when operating large‑scale Agent systems, summarized into a reusable architectural pattern.

The core idea in one line: treat prompts as code, and introduce a “transpilation layer” that completely decouples high‑level Agent logic from low‑level model invocation.

It sounds like an old compiler trick, but applied to Agents, this turns out to be more important than you’d expect.

Why Agent Systems Collapse at Scale

In the past two years, any team that has built an Agent system could list a pile of pain points. The most common ones include:

• A single business workflow packs in dozens of Agents, each with its own system prompt—touch one, break them all
• Trying to migrate from Gemini to Claude or GPT reveals that prompts must be almost completely rewritten
• Under multi‑model setups, identical “tool‑call” concepts are expressed entirely differently
• Prompts hard‑code business rules, and version control devolves into manual git diff comparison
• A/B testing is extremely expensive because a prompt is one big string—impossible to compare structurally

This is exactly what Google’s new method aims to fix. Its key insight: once the number of Agents grows from a handful to tens or hundreds, the problem changes in nature—it’s no longer about writing better prompts but about how to organize, reuse, and maintain them.

This is essentially the leap from “writing scripts” to “engineering systems.”

What the Transpilation Layer Actually Does

According to Google’s article, the approach can be divided into three layers:

Layer 1: High‑level Agent Description.
Developers describe Agents in a structured, model‑agnostic way—what they do, which tools they can call, what policies they follow, how they collaborate with other Agents. This layer has nothing to do with literal prompt text and is more like writing an interface definition language (IDL).

Layer 2: Modular Prompt Components.
Prompts are broken into reusable modules—role definitions, task constraints, tool descriptions, few‑shot examples, output format specs, etc.—each versioned independently. That’s the “modular” part of the article’s title.

Layer 3: The Transpiler.
This is the crucial piece. The transpiler compiles the high‑level abstract description into optimized prompt strings for specific models (Gemini, Claude, GPT‑4, etc.). Since models differ in preferences—XML vs. JSON schemas, few‑shot placement, system role handling—the transpiler normalizes those differences.

A simple analogy: writing raw prompts is like writing assembly (directly manipulating strings); Google’s architecture lets you write in C, and the compiler emits machine code for different CPU architectures. GPT is x86, Claude is ARM, Gemini is RISC‑V—and your source code stays the same.

The Real Value of This Architecture

After reading carefully, a few developer takeaways stand out:

Prompts become first‑class citizens.
Where prompts used to hide in code strings, Notion pages, or chats, they now gain explicit schemas, linting, unit tests, and CI regression runs. That’s the baseline for true engineering.

Model‑switching costs plummet.
Crucial in today’s multi‑model landscape: the business might use Gemini 2.5 Pro today for cost, Claude tomorrow for code reasoning, and GPT‑5 the day after for multimodality—no prompt rewrites required.

Unified grammar for multi‑Agent coordination.
The article dives deep into Agent‑to‑Agent calls and context sharing. The transpilation layer standardizes these communication protocols so that, whether the backend uses A2A or MCP, the higher layer sees a single abstraction.

Feasible A/B testing and evaluation.
Because prompts are modular, you can swap just one component (say, a few‑shot set) and run evaluations—a near impossibility before.

Pseudocode to Illustrate the Structure

Although Google hasn’t open‑sourced the implementation, the described structure implies typical usage like this:

# agent_definition.yaml — High‑level description
agent: customer_support_l1
role: "Handle basic customer inquiries and detect escalation signals"
capabilities:
  - knowledge_base_search
  - ticket_creation
  - escalation_to_human
policies:
  - name: no_pricing_commitment
    modules: [policy/pricing_disclaimer]
  - name: pii_handling
    modules: [policy/pii_v2]
output_schema: schemas/support_response.json

Then compose several prompt modules:

# prompt_modules/role/support_agent.yaml
version: 1.3.0
content: |
  You are a patient and professional customer support representative.
  When encountering a question you cannot answer, actively use the escalation_to_human tool.

# prompt_modules/policy/pii_v2.yaml
version: 2.0.1
content: |
  Do not repeat full credit card or ID numbers provided by users.
  If reference is necessary, display only the last four digits.

During transpilation, the builder generates the final prompt for the target model:

from prompt_transpiler import compile_agent

# Compile for Gemini
gemini_prompt = compile_agent(
    "customer_support_l1",
    target="gemini-2.5-pro",
)

# Compile for Claude — same agent definition, different output
claude_prompt = compile_agent(
    "customer_support_l1",
    target="claude-sonnet-4.5",
)

According to the target model’s preferences, the transpiler automatically decides: Claude versions wrap policy segments in XML tags, Gemini uses compact Markdown layouts, GPT might migrate tool definitions into a function‑calling schema.

Relationship to Existing Frameworks

You might ask: isn’t this what LangChain, LlamaIndex, or CrewAI already do?

Not quite. Most existing frameworks treat prompts as configurable strings or template variables—the abstraction stops at “fill in the blank.” Google’s ambition is bigger: give prompts their own type, module, and version systems, and only generate concrete code at the final model step.

A closer analogy is Google’s internal Protobuf for gRPC: define once, compile for multiple languages. Here: define once, transpile for multiple models.

Naturally, there’s an upfront cost. Building the module library and transpilation rules demands serious engineering effort—overkill for a small team with a single Agent. But once you have a dozen or more Agents or need multi‑model backends, the marginal gains become dramatic.

What It Means for Developers

This isn’t a “just‑for‑fun” blog post—it signals a real shift: Agent development is moving from a prompt‑craft workshop phase to proper software engineering.

Practical steps you can take now:

1. Extract prompts from code into a dedicated folder with version numbers
2. Add unit tests for prompts—assert expected output formats on typical inputs
3. Split prompts into four module types: role, task, constraint, and example; combine them manually first
4. Establish an internal “prompt library” for team reuse to avoid reinventing the wheel per Agent
5. Abstract a model‑adapter layer—even if it starts as plain if‑else, it beats hard‑coded strings

Do these, and you’ll already capture 80 % of the benefits. For a full transpiler, wait for a community implementation—given Google’s typical open‑source cadence, the ADK (Agent Development Kit) will likely integrate this.

Multi‑model switching is an unavoidable reality. OpenAI Hub, for instance, uses one key for GPT, Claude, Gemini, and DeepSeek under the OpenAI‑compatible format—handy when experimenting with transpilation layers without juggling multiple SDKs.

A Final Take

Such architectural ideas usually show their real impact six to twelve months later—when more teams feel the pain of Agent scale and look back to find that Google had already pointed in the right direction.

Notably, Anthropic’s recent Claude Agent SDK and Microsoft’s Semantic Kernel “Prompt as Function” concept are moving the same way. The industry is collectively realizing: prompts can’t stay mystical; they must become engineering artefacts.

Whoever solidifies this infrastructure first will own the foundation of the next wave of Agent competition.

References

• Understanding AI Agents: A General Framework for LLM‑Based Intelligent Agents – Zhihu — background on Agent architecture concepts and large models as the central “brain.”