馃幆 Affected Service(s)
App Service (golang-adk)
馃殾 Impact/Severity
Minor inconvenience
馃悰 Bug Description
When an agent uses the Bedrock provider, the golang ADK cuts every tool result in the conversation history to 2000 characters, except the most recent one. It does this each time it rebuilds the Converse request.
The UI shows the full tool output from the session store, but the model only sees <first 2000 chars>\n... [truncated, N chars omitted] once another tool call has happened after it.
This hurts most with the skills tool. A SKILL.md is usually longer than 2000 chars, and the agent loads it once and then follows it over several tool calls. After the first follow-up call, the skill instructions are gone from the model's context. We saw the agent notice this and re-read the SKILL.md with read_file, which gets truncated the same way as soon as the next tool call happens.
Code (main @ 15e0fc1, also in v0.10.1 and v1.0.0-alpha3), go/adk/pkg/models/bedrock.go:
const historyToolResultMaxLen = 2000
func truncateToolResult(s string, maxLen int) string {
if len(s) <= maxLen {
return s
}
return s[:maxLen] + fmt.Sprintf("\n... [truncated, %d chars omitted]", len(s)-maxLen)
}
truncateTools := i != lastToolResultIdx
...
if part.FunctionResponse != nil {
result := extractFunctionResponseContent(part.FunctionResponse.Response)
if truncateTools {
result = truncateToolResult(result, historyToolResultMaxLen)
}
The limit is hardcoded and can't be configured. None of the other Go model adapters (OpenAI, Anthropic, etc.) do this, so the same agent behaves differently depending on the provider.
It also works against Bedrock prompt caching. A tool result is sent in full while it is the latest one and truncated after that, so the request prefix changes at that message on every step and the cache is invalidated from there on.
馃攧 Steps To Reproduce
- Create an agent with a Bedrock ModelConfig and a skill whose SKILL.md is longer than 2000 chars.
- Ask a question that makes the agent load the skill and then call at least one more tool.
- On the next model turn, the agent can't see anything in the skill past the first 2000 chars. Ask the agent about it, or look at the Bedrock request: the
toolResult block for the skill call ends with ... [truncated, N chars omitted].
馃 Expected Behavior
The model keeps seeing the full tool results that are still in the history, the same as with the other providers. If truncation is needed to save context, it should be opt-in or configurable, and not applied to skill content.
馃摫 Actual Behavior
The agent reported:
skills tool output got truncated (7791 chars omitted, cut off mid-section). Needed rest of recipe (span attribute names, sql steps) before querying. read_file grabbed full file to see truncated part.
The SKILL.md was ~9.5k chars; 2000 + 7791 matches the skill tool output size.
馃捇 Environment
- kagent: v0.10.1, image
golang-adk:0.10.1-full (code unchanged in v1.0.0-alpha3 and main)
- Model provider: AWS Bedrock (Anthropic Claude)
- Kubernetes provider: AWS EKS
馃攳 Additional Context
Possible fixes, in order of preference:
- Remove the truncation, or make it opt-in (e.g. a ModelConfig field for the max tool result length in history, where 0 means no limit).
- Never truncate results from the
skills tool (and possibly read_file).
- Raise the default limit well above 2000.
Related but different: #2508 (extractFunctionResponseContent drops MCP resource content, so the model sees less than the UI shows).
Workaround: keep SKILL.md under ~1800 chars and move the details into reference files that the agent reads right before the step that needs them.
馃幆 Affected Service(s)
App Service (golang-adk)
馃殾 Impact/Severity
Minor inconvenience
馃悰 Bug Description
When an agent uses the Bedrock provider, the golang ADK cuts every tool result in the conversation history to 2000 characters, except the most recent one. It does this each time it rebuilds the Converse request.
The UI shows the full tool output from the session store, but the model only sees
<first 2000 chars>\n... [truncated, N chars omitted]once another tool call has happened after it.This hurts most with the
skillstool. A SKILL.md is usually longer than 2000 chars, and the agent loads it once and then follows it over several tool calls. After the first follow-up call, the skill instructions are gone from the model's context. We saw the agent notice this and re-read the SKILL.md withread_file, which gets truncated the same way as soon as the next tool call happens.Code (
main@ 15e0fc1, also in v0.10.1 and v1.0.0-alpha3),go/adk/pkg/models/bedrock.go:The limit is hardcoded and can't be configured. None of the other Go model adapters (OpenAI, Anthropic, etc.) do this, so the same agent behaves differently depending on the provider.
It also works against Bedrock prompt caching. A tool result is sent in full while it is the latest one and truncated after that, so the request prefix changes at that message on every step and the cache is invalidated from there on.
馃攧 Steps To Reproduce
toolResultblock for the skill call ends with... [truncated, N chars omitted].馃 Expected Behavior
The model keeps seeing the full tool results that are still in the history, the same as with the other providers. If truncation is needed to save context, it should be opt-in or configurable, and not applied to skill content.
馃摫 Actual Behavior
The agent reported:
The SKILL.md was ~9.5k chars; 2000 + 7791 matches the skill tool output size.
馃捇 Environment
golang-adk:0.10.1-full(code unchanged in v1.0.0-alpha3 and main)馃攳 Additional Context
Possible fixes, in order of preference:
skillstool (and possiblyread_file).Related but different: #2508 (
extractFunctionResponseContentdrops MCP resource content, so the model sees less than the UI shows).Workaround: keep SKILL.md under ~1800 chars and move the details into reference files that the agent reads right before the step that needs them.