---
title: "Discussion on \"Building agents with Strands harness and Kimi K3 in Amazon Bedrock\" | Hashnode"
description: "Discussion on \"Building agents with Strands harness and Kimi K3 in Amazon Bedrock\". Pair AWS's new open-source agent runtime with Moonshot AI's 1M-token model in a few lines of Python"
url: "https://hashnode.com/posts/building-agents-with-strands-harness-and-kimi-k3-in-amazon-bedrock/6ab5c133ec3d4d16c362616c"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Building agents with Strands harness and Kimi K3 in Amazon Bedrock](https://blog.gainesai.com/building-agents-with-strands-harness-and-kimi-k3-in-amazon-bedrock?utm_source=hashnode&utm_medium=feed)

Pair AWS's new open-source agent runtime with Moonshot AI's 1M-token model in a few lines of Python

Sep 25 · 15 min read · blog.gainesai.com  
Read the article

-   [#aws](https://hashnode.com/tag/aws)
-   [#ai](https://hashnode.com/tag/ai)
-   [#python](https://hashnode.com/tag/python)
-   [#generative-ai](https://hashnode.com/tag/generative-ai)
-   [#llm](https://hashnode.com/tag/llm)
-   [#kimi-k3](https://hashnode.com/tag/kimi-k3)
-   [#bedrock](https://hashnode.com/tag/bedrock)

## Written by

[James Gaines](https://hashnode.com/@gainesai)

@gainesai · Morgantown, USA

  
[View profile](https://hashnode.com/@gainesai)

Building and breaking things in the cloud

AWS cloud architect and AI enthusiast based in Morgantown, WV. I write about building on AWS, exploring AI agents and automation, and the occasional deep dive into cloud security. Follow along as I share what I'm learning, building, and breaking in the cloud

## Responses 1

Markdown supported · ⌘↵ to post

[Mateo Ruiz](https://hashnode.com/@mateoruiz)

[Sep 25](https://hashnode.com/posts/building-agents-with-strands-harness-and-kimi-k3-in-amazon-bedrock/6ab5c133ec3d4d16c362616c/comment/6ab62af0e56e1439671ed438)

The interesting part here is that the harness makes agent infrastructure portable, but the live-testing section shows why portability alone isn't enough. Once context handling, reasoning replay, caching, and model-specific behavior become runtime assumptions, those assumptions need to be characterized rather than buried in configuration.

I especially like keeping the hook even after the documented failure couldn't be reproduced. That’s a good production pattern: distinguish “currently reproducible” from “still worth guarding against,” and encode the expected behavior in a characterization test. Otherwise a future Bedrock/model revision can silently invalidate an assumption that nobody remembers was there.

For long-running agents, I’d treat those characterization tests almost like compatibility contracts between the harness and model provider. The model string may be swappable, but the behavioral contract around context, tool calls, reasoning state, and session replay is what actually determines whether the agent remains reliable.
