ODW #7: Reduce Token Consumption by 40% in Three Ways! Context Engineering with ADK

The post explains how LY Corporation’s Orchestration Development Workshop uses context engineering to reduce AI-agent costs and improve accuracy. As internal adoption of tools such as Claude Code, Cline, and ADK grows, excessive token usage, missed instructions, and declining performance in long conversations have become common. The recommended solution is to deliberately select and manage the context sent to an LLM, demonstrated through an ADK-based Jira weekly-report agent.

Problems Caused by Expanding AI Use

• Increased AI adoption has led to unexpectedly high token consumption.
• Users often receive incomplete or incorrect results despite providing detailed prompts.
• Long-running conversations can cause the model to produce irrelevant answers.
• Major causes include:
  • Trial-and-error prompting
  • More complex and long-running agents
  • Expansion from single-agent to multi-agent systems
  • Tool integrations such as MCP, whose definitions also consume context
  • Limited awareness of context optimization techniques

Context Rot and Context Engineering

• Context rot occurs when long-running agents accumulate conversation history, intermediate results, and irrelevant information.
• As the context grows:
  • The context window becomes pressured.
  • Relevant information becomes harder to identify.
  • Noise overwhelms important signals, reducing accuracy.
• Context engineering is the deliberate design and management of all information provided during inference, including:
  • Static context: System prompts and tool definitions
  • Dynamic context: User messages, conversation history, and retrieved external data
  • Long-term context: Persistent session state and accumulated information
• The core principles are:
  • Treat tokens as a limited resource and retain the smallest set of high-signal information.
  • Provide neither too little information, which forces guesswork, nor too much, which wastes tokens and reduces clarity.

Why Use ADK

Google’s open-source Agent Development Kit (ADK) is presented as a practical platform for applying context engineering.

• Agents can be designed and shared using team knowledge rather than relying on individual CLI expertise.
• ADK includes UI, API-server, evaluation, and multi-agent capabilities.
• Its multi-agent architecture naturally supports separating and controlling context.

ADK Context-Engineering Components

The workshop introduces nine key components, including:

• Structured input and output: JSON or schema-based formats reduce unnecessary text and make agent processing more reliable.
• AgentTool: Embeds one agent inside another as a tool. The calling agent receives only the final result, preventing internal tools and intermediate context from accumulating.
• MCP Toolset filtering: The tool_filter parameter exposes only required MCP tools, reducing tool-definition tokens and improving model decisions.
• The remaining components can be combined with these techniques to control context throughout an agent workflow.

Jira Weekly Report Example

The workshop builds jira_weekly_report, an agent that analyzes team Jira tickets and generates a weekly Markdown report.

Version 1: Single Agent Without Context Engineering

• A single agent retrieves the ticket list, fetches each ticket, analyzes it, and builds the report.
• All Jira tools are exposed through one MCP toolset.
• As the number of tickets increases, detailed ticket contents accumulate in the agent’s context.
• This leads to context rot, higher token usage, and declining reliability.

Version 2: Context-Aware Multi-Agent Design

• The workflow is split into:
  • A root agent that searches Jira tickets and aggregates the final report.
  • A sub-agent dedicated to analyzing one ticket at a time.
• input_schema requires a structured issue_key.
• output_schema requires a structured report containing ticket content and progress, including comments.
• The sub-agent receives only the jira_get_issue MCP tool.
• The root agent receives only the jira_search tool.
• AgentTool hides the sub-agent’s internal context and returns only its final report.
• The sub-agent is instructed to include facts only and avoid speculation.

This design limits each agent’s responsibilities, removes unnecessary tool definitions, and prevents individual ticket details from polluting the root agent’s context.

Practical Recommendation

For production AI agents, treat context as a constrained resource. Use structured schemas, narrowly filtered tools, and specialized sub-agents to pass only the information needed for each step.