Supress agent "thinking" from output in chatbot

[hshabbirh]

Hi folks,

I'm building an agent that is embedded in a chatbot. The agents uses several tools. The challenge i'm facing is that the agent outputs the LLM thinking (within tags) which includes its tool-plan. How can i exclude the "thinking" and output only the final content?

[williamgurzoni]

Actually, I was about to open a discussion for the opposite haha. When using the Ollama client, it stopped outputting the thinking process after this update. Would be good to have this as an option. Seeing the thinking processes while developing helps a lot with the prompt engineering.

But I agree, it should be optional.

[yyhao0422]

Im facing the same issue as some of the model like claude model , it does not output thinking tag , directly show the thinking step as the output, which make my final output include tool use thinking step. If the thinking can be consistent across all model, it would be better for developer to render the thinking process to frontend

[yonib05]

Hi @hshabbirh, apologies for taking this long to circle back, this one deserved an answer months ago.

There are two different "thinkings" here. Native reasoning (e.g. Bedrock with thinking enabled, Gemini thinking models) is kept separate by the SDK: in agent.stream_async() those deltas arrive as events with a reasoningText key, while normal answer text arrives under data. So in a chatbot you just render event["data"] and drop the rest. Note the default Agent also prints everything to stdout, so pass callback_handler=None if you're consuming the stream yourself. Docs: https://strandsagents.com/docs/user-guide/concepts/streaming/

The <thinking> tags you're seeing are the second kind: the model writing its tool plan as ordinary text before calling a tool. That streams as data like any other text, so there's no key to filter on. The reliable fix is to not stream intermediate turns to the user at all: call the agent and render result.message (or str(result)), which only contains the final message. If you need streaming plus final-answer-only, that requires buffering text per turn today, and there's an open feature request for a built-in option, #2055, give it a 👍 so we know more people want it. A system prompt instruction not to narrate tool plans also helps a lot in practice.

@williamgurzoni for your opposite case: since that Ollama change, capable models think by default but the reasoning moves out of content into a separate message.thinking field, and the Strands Ollama provider doesn't read that field (or expose a think option), so it stopped surfacing through Strands. I didn't find an existing issue for this, so please file one here so we can track it: https://github.com/strands-agents/harness-sdk/issues/new?template=feature_request.yml

@yyhao0422 the consistency you're after exists for models that emit structured reasoning: the SDK normalizes all of those into the same reasoningText events regardless of provider, so you can route them to a separate pane in your frontend. When a model thinks in plain prose instead, that's model behavior the SDK can't reliably separate, and the same final-message approach above is the workaround.

Hope this helps all three of you!