load_skill re-returns full SKILL.md instructions on every call. Is context growth from repeated loads expected?

[mohannaguru-design]

Looking at SkillToolset / LoadSkillTool in google/adk/tools/skill_toolset.py, I want to check whether the current behavior is intentional.

LoadSkillTool.run_async always returns the full skill.instructions body in the function response:

return {
    "skill_name": skill_name,
    "instructions": skill.instructions,
    "frontmatter": skill.frontmatter.model_dump(),
}

There's a per-agent activated_skills list tracked in tool_context.state (_adk_activated_skill_{agent_name}), but it's only consulted in _resolve_additional_tools_from_state to decide which adk_additional_tools to expose — it's never used to short-circuit load_skill itself. So if the model calls load_skill on the same skill twice in a session (e.g. after a context summarization/truncation step upstream, or just because it isn't careful about tracking what it already has), the full SKILL.md content gets duplicated in the conversation history each time.

The system instruction (_DEFAULT_SKILL_SYSTEM_INSTRUCTION) tells the model it "MUST use load_skill" whenever a skill seems relevant, but doesn't say anything like "only if you haven't already loaded it this session" — so the framework seems to rely entirely on the model's own judgment/memory of its history to avoid redundant loads, rather than the toolset enforcing it.

Questions:

1. Is this the intended design — i.e., is de-duplication meant to be the model's responsibility, not the toolset's?
2. If so, is there a recommended pattern for avoiding instruction-bloat in longer sessions or multi-agent pipelines (where activated_skills is namespaced per-agent, so the same skill can get loaded — and its instructions duplicated — once per sub-agent)?
3. Would a patch that has load_skill check activated_skills first and return a short "already loaded, see earlier turn" response instead of the full instructions on repeat calls be a welcome contribution, or is there a reason this wasn't done already (e.g. context truncation elsewhere making that check unreliable)?

---

[Junaid-PK]

Your reading of the current implementation is correct. The important distinction is that activated_skills means “expose this skill's additional tools”, not “the current model context still contains this skill's instructions.”

LoadSkillTool.run_async records activation and then unconditionally returns the instructions. The activation state is consumed later only while resolving adk_additional_tools. The per-invocation fetched-skill cache avoids repeated registry I/O, but it does not deduplicate function responses.

A state-only short circuit would therefore be unsafe. ADK compaction replaces covered raw events with a summary, and the default summarizer caps each rendered tool response at 2,000 characters. After that, session state may still say the skill is activated while most of its instructions are no longer visible to the model. Returning “already loaded, see earlier turn” would leave the model unable to recover them.

The per-agent namespace also makes sense for the same reason: activation by agent A does not prove that agent B's model context has ever received the instructions.

So I would answer the three questions as follows:

1. Yes, repeated calls currently re-return the full body; there is no toolset-level deduplication. The prompt also only says the model must load a relevant skill, not that it should suppress repeat loads.
2. For now, avoid unnecessary reloads through agent guidance while the earlier result is still in the active context, but allow reload after compaction, handoff, or uncertainty. In multi-agent pipelines, each agent needs its own load because each has its own model context.
3. I would not submit the proposed activated_skills-only short circuit as-is. A robust dedup design needs a model-visibility signal synchronized with compaction/history, or compaction must preserve/reset enough information to make reloading deterministic.

There is also relevant prior maintainer feedback on an activated-skill eviction proposal: removing skill tools was rejected because it could invalidate context caching and leave the model referring to tools introduced in earlier turns (#5745). That is not the identical change, but it reinforces that session state and visible conversation history must stay coherent.

A small prompt clarification such as “do not reload a skill whose full instructions are still present in the active context; reload if they may have been compacted away” looks safer than a server-side state-only guard. Whether that wording or a context-aware API change is preferred still needs a maintainer decision.