Skip to content

[BUG] Bedrock model truncates older tool results to 2000 chars, agents lose loaded skill instructions聽#2946

Description

@project0

馃幆 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

  1. Create an agent with a Bedrock ModelConfig and a skill whose SKILL.md is longer than 2000 chars.
  2. Ask a question that makes the agent load the skill and then call at least one more tool.
  3. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions