Context Engineering Demo with Google ADK

A practical demonstration of the Four Pillars of Context Engineering using Google's Agent Development Kit (ADK) and the free Gemini API.

What This Demo Shows

This demo implements a Customer Support Agent that demonstrates:

Pillar	What It Does	How We Demo It
WRITE	Store facts in external memory	save_customer_note saves customer info outside context window
SELECT	Retrieve only relevant info	search_knowledge_base loads only matching KB sections
COMPRESS	Summarize to save tokens	log_interaction stores summary, not full transcript
ISOLATE	Use specialized sub-agents	billing_agent and technical_agent handle specific tasks

---

Prerequisites

• Python 3.10+
• Free Gemini API key from aistudio.google.com

---

Setup

1. Create project folder and virtual environment

mkdir context_engineering_demo
cd context_engineering_demo

python -m venv .venv

# Activate:
# macOS/Linux:
source .venv/bin/activate
# Windows:
.venv\Scripts\activate

2. Install dependencies

pip install google-adk python-dotenv

3. Create .env file with your API key

GOOGLE_API_KEY=your_api_key_here
GOOGLE_GENAI_USE_VERTEXAI=FALSE

Get your free API key at: https://aistudio.google.com/apikey

4. Create the project structure

context_engineering_demo/
├── .env
├── run_demo.py
└── support_agent/
    ├── __init__.py        # Required!
    ├── agent.py
    ├── knowledge_base.py
    └── tools.py

---

Running the Demo

Option 1: ADK Web UI (Recommended)

adk web

Open http://localhost:8000 in your browser.

Important: In ADK Web UI, check the Events tab (right panel) to see:

• Which tools were called
• Which sub-agent handled the request
• Full tool responses

Some responses (especially from sub-agents) appear in the Events tab rather than the main chat.

Option 2: Command Line

python run_demo.py

Option 3: See Pillars Without LLM

python run_demo.py --demo

This shows the mechanics of each pillar without using API credits.

---

Testing Guide: Verify All Four Pillars

Run these tests in order to verify the demo is working correctly.

Test 1: SELECT Pillar — Basic Knowledge Retrieval

Prompt:

How much does the Pro plan cost?

Expected Behavior:

• Tool call: search_knowledge_base (selects "pricing" category)
• Text response: Mentions "$29/month" and Pro features

✅ Success: You see pricing information in the response.

---

Test 2: SELECT Pillar — Technical Query

Prompt:

How do I reset my password?

Expected Behavior:

• Tool call: search_knowledge_base (selects "account" category)
• Text response: Steps including "Click 'Forgot Password' on login page"

✅ Success: You see password reset instructions.

---

Test 3: WRITE Pillar — Save Customer Facts

Prompt:

I'm customer_456 and I'm on the Pro plan. I primarily use the Slack integration.

Expected Behavior:

• Tool call: get_customer_context (checks for existing facts)
• Tool call: save_customer_note (saves plan = "Pro")
• Tool call: save_customer_note (saves integration = "Slack")
• Text response: Acknowledges the customer

✅ Success: You see save_customer_note called in the Events tab.

---

Test 4: WRITE Pillar — Verify Memory Works

Prompt:

What do you know about customer_456?

Expected Behavior:

• Tool call: get_customer_context
• Text response: Mentions "Pro plan" and "Slack integration" (from Test 3)

✅ Success: Agent remembers facts saved in Test 3.

---

Test 5: COMPRESS Pillar — Log Compressed Interaction

Prompt:

Log this interaction for customer_456: they asked about API rate limits, I explained Pro plan has 1000 requests/hour, they were satisfied.

Expected Behavior:

• Tool call: log_interaction with:
  • customer_id: "customer_456"
  • issue_type: "technical"
  • resolution: Brief summary (~20-30 tokens, not full conversation)

✅ Success: Check Events tab — log_interaction is called with a compressed summary.

Why this matters: Instead of storing the entire conversation transcript (potentially 500+ tokens), we store a ~30 token summary. This is the COMPRESS pillar in action.

---

Test 6: ISOLATE Pillar — Sub-Agent Delegation

Prompt:

I need a refund for my last payment

Expected Behavior:

• Possible transfer to billing_agent (check Events tab for "transfer")
• Tool call: search_knowledge_base with billing category
• Response about refund policy: "Full refund within 14 days, prorated after"

✅ Success: Check Events tab — you should see either:

• Transfer to billing_agent, OR
• search_knowledge_base called with billing category

Note: The text response may only appear in the Events tab when sub-agents handle the request.

---

Test 7: ISOLATE Pillar — Technical Sub-Agent

Prompt:

My API integration with GitHub is not syncing properly

Expected Behavior:

• Possible transfer to technical_agent
• Tool call: search_knowledge_base with technical category
• Response with troubleshooting steps

✅ Success: Check Events tab for technical agent handling or technical KB retrieval.

---

Test 8: Debug — Check All Saved Memory

Prompt:

Check memory status

Expected Behavior:

• Tool call: check_memory_status
• Response showing all saved customer facts

✅ Success: In Events tab, you should see all facts saved during your session.

---

Understanding the Four Pillars in This Demo

📝 WRITE (External Memory)

Problem: LLMs forget everything between conversations.

Solution: Store important facts externally.

In this demo:

• save_customer_note stores facts like "customer is on Pro plan"
• log_interaction stores interaction summaries
• Facts persist and can be retrieved in future queries

Token savings: Instead of keeping full conversation history in context (1000s of tokens), we store extracted facts (~50 tokens).

---

🔍 SELECT (Just-in-Time Retrieval)

Problem: Loading all knowledge into context wastes tokens and confuses the model.

Solution: Retrieve only what's relevant to the current query.

In this demo:

• search_knowledge_base analyzes the query
• Returns only matching sections (pricing OR technical OR billing)
• Never loads the entire knowledge base

Token savings: ~100-200 tokens loaded vs ~500+ for full KB.

---

📦 COMPRESS (Token Efficiency)

Problem: Conversation history grows unbounded, eventually hitting context limits.

Solution: Summarize and compress information before storing.

In this demo:

• log_interaction stores: {"issue": "billing", "resolution": "explained refund policy"} (~30 tokens)
• Instead of: Full 47-message transcript (~4,500 tokens)

Token savings: 95%+ reduction in stored history.

---

🔀 ISOLATE (Task Decomposition)

Problem: One agent with all tools and all knowledge becomes slow and confused.

Solution: Specialized sub-agents with focused contexts.

In this demo:

• billing_agent: Only handles pricing/refunds, only has billing KB access
• technical_agent: Only handles API/integration issues, only has technical KB access
• Main agent delegates based on query type

Why it helps: Each agent has ~200 tokens of context instead of ~1000. Focused context = better accuracy.

---

Troubleshooting

"No text response in main chat"

For Tests 5-8, check the Events tab in ADK Web UI. Sub-agent responses often appear there instead of the main chat.

"ModuleNotFoundError: No module named 'support_agent'"

Make sure you have __init__.py in the support_agent/ folder.

"GOOGLE_API_KEY not found"

Create a .env file in your project root with:

GOOGLE_API_KEY=your_key_here
GOOGLE_GENAI_USE_VERTEXAI=FALSE

"Rate limit exceeded"

The free Gemini API has rate limits. Wait a minute and try again, or reduce query frequency.

---

Project Structure

context_engineering_demo/
├── .env                    # API key configuration
├── README.md               # This file
├── run_demo.py             # Standalone demo script
└── support_agent/          # ADK agent package
    ├── __init__.py         # Package init (required!)
    ├── agent.py            # Main agent + sub-agents (ISOLATE)
    ├── knowledge_base.py   # Product database (WRITE/SELECT)
    └── tools.py            # Agent tools (all pillars)

---

Learn More

This demo accompanies the LinkedIn article series on Context Engineering:

• Part 1: Why Context Engineering Matters
• Part 2: The Four Pillars Framework
• Part 3: Implementation (this demo)

---

Quick Reference: Test Prompts

Pillar	Test Prompt	What to Check
SELECT	"How much does Pro cost?"	KB search returns pricing only
SELECT	"How do I reset my password?"	KB search returns account only
WRITE	"I'm customer_456 on Pro plan"	save_customer_note called
WRITE	"What do you know about customer_456?"	Returns saved facts
COMPRESS	"Log this interaction for customer_456: billing question, resolved"	log_interaction stores summary
ISOLATE	"I need a refund"	Transfer to billing_agent (Events tab)
ISOLATE	"My API is broken"	Transfer to technical_agent (Events tab)
DEBUG	"Check memory status"	Shows all saved facts