bedrock-agentcore-starter-toolkit 0.1.5__tar.gz → 0.1.6__tar.gz

{bedrock_agentcore_starter_toolkit-0.1.5 → bedrock_agentcore_starter_toolkit-0.1.6}/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [0.1.6] - 2025-08-11
+
+Updated SDK dependency to >=0.1.2 for improved thread pool handling and concurrency fixes
+
+### Dependencies
+- Updated to bedrock-agentcore SDK v0.1.2
+
 ## [0.1.5] - 2025-08-08
 
 ### Changes

{bedrock_agentcore_starter_toolkit-0.1.5 → bedrock_agentcore_starter_toolkit-0.1.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: bedrock-agentcore-starter-toolkit
-Version: 0.1.5
+Version: 0.1.6
 Summary: A starter toolkit for using Bedrock AgentCore
 Project-URL: Homepage, https://github.com/aws/bedrock-agentcore-starter-toolkit
 Project-URL: Bug Tracker, https://github.com/aws/bedrock-agentcore-starter-toolkit/issues
@@ -22,7 +22,7 @@ Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
 Classifier: Topic :: Software Development :: Libraries :: Python Modules
 Requires-Python: >=3.10
 Requires-Dist: autopep8>=2.3.2
-Requires-Dist: bedrock-agentcore>=0.1.1
+Requires-Dist: bedrock-agentcore>=0.1.2
 Requires-Dist: boto3>=1.39.7
 Requires-Dist: botocore>=1.39.7
 Requires-Dist: docstring-parser<1.0,>=0.15

bedrock_agentcore_starter_toolkit-0.1.6/documentation/docs/user-guide/import-agent/design.md

@@ -0,0 +1,128 @@
+# Import Agent Design
+
+Design overview for the import-agent utility, explaining the choices behind the generated agent.
+
+
+## Utility Feature Support
+
+Below is each feature of Bedrock Agents and which of the features this utility successfully maps to each target framework. We also describe which AgentCore Primitive is used to enhance each feature mapping.
+
+|Bedrock Agent Feature	|AgentCore + Langchain	|AgentCore + Strands	|Notes	|
+|---	|---	|---	|---	|
+|Action Groups	|SUPPORTED	|SUPPORTED	|Uses AgentCore Gateway	|
+|Orchestration	|SUPPORTED	|SUPPORTED	|	|
+|*Guardrails*	|SUPPORTED	|SUPPORTED	|	|
+|*Knowledge Bases*	|SUPPORTED	|SUPPORTED	|	|
+|*Code Interpreter*	|SUPPORTED	|SUPPORTED	|Uses AgentCore Code Interpreter	|
+|Short Term Memory	|SUPPORTED	|SUPPORTED	|	|
+|Long Term Memory	|SUPPORTED	|SUPPORTED	|Uses AgentCore Memory	|
+|Pre/Post Processing Step	|SUPPORTED	|SUPPORTED	|	|
+|User Input	|SUPPORTED	|SUPPORTED	|	|
+|*Traces*	|SUPPORTED	|SUPPORTED	|Uses AgentCore Observability	|
+|Multi-Agent Collaboration 	|SUPPORTED	|SUPPORTED	|	|
+
+## Action Groups → AgentCore Gateway Target
+
+In Bedrock Agents, users can define Action Groups for their agents. An Action Group is a collection of tools that are either executed via AWS Lambda or through a local callback (Return of Control). These tools are defined using either an OpenAPI specification or a structured function schema. At runtime, Bedrock Agents call your Lambda function with an event formatted according to the schema you selected. The structure of this event is documented here: [AWS Bedrock Lambda integration](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-lambda.html).
+
+In AgentCore Gateway, we create one gateway per generated agent. Each Action Group in Bedrock Agents maps to a target in the gateway. Within each target, every function or path/method becomes a tool. To ensure compatibility with existing Action Group Lambda functions, we use a proxy Lambda function as the executor for all tools in the gateway. This proxy:
+
+1. Receives tool calls in the Gateway's format.
+2. Identifies the correct Action Group Lambda to invoke.
+3. Reformats the request object to match the expected format.
+4. Calls the appropriate Lambda and returns the result in a Gateway-compatible format.
+
+If AgentCore Gateway is disabled, the system generates local tools instead:
+
+* Each function or path/method becomes a separate tool.
+* The tool’s argument schema is exposed to the agent via Pydantic model generation.
+* Each tool formats its request correctly and calls the corresponding Action Group Lambda directly.
+
+This approach also applies to Return of Control (ROC) action groups, where the tool prompts the user for input locally before proceeding with execution.
+
+
+## Orchestration
+
+For orchestration, the Bedrock Agents prompt are constructed at runtime, by substituting in template fixtures (ie. variables in the prompt). For example, the orchestration prompt may have the fixture called knowledge_base_guidelines. This variable is filled in depending on the model provider and model version in use.
+
+To approximate the same behavior and deliver translated agents that are functionally equivalent, the utility uses ONE collection of template fixtures (`template_fixtures_merged.json`) and substitutes them in to build the correct prompts. As for orchestration strategy, for both Langchain and Strands, the utility uses the standard ReAcT orchestration pattern.
+
+
+## Guardrails
+
+In Bedrock Agents, users can add Bedrock Guardrails to their agent. This applies the guardrail on the model level and Bedrock Agents will have defined behavior for when a guardrail is invoked to redact or block an input. Equivalently, the utility applies the same guardrail on Bedrock models, as there is support for this in both Langchain and Strands.
+
+
+## Knowledge Bases
+
+In Bedrock Agents, users can add existing Knowledge Bases (defined via Bedrock Knowledge Bases) to their agent via the Console or SDK. The AgentCore + Langchain/Strands equivalent of this feature is to use each of those KBs to define a KB retrieval tool for an agent to use. This tool uses the AWS SDK to retrieve from connected knowledge bases using a query decided by the agent and then returns the document results for the agent to use.
+
+
+## Code Interpreter → AgentCore Code Interpreter
+
+In Bedrock Agents, users can enable Code Interpreter. This gives a Bedrock Agent access to a sandbox for it to write, troubleshoot, and return the output of code.
+
+We use AgentCore Code Interpreter for an equivalent experience. The utility defines a `code_tool` which creates a code sandbox session and defines a sub-agent with access to code interpreter operations (as tools). These operations include executing code, writing/removing files, and more. This sub-agent is fed the code tool's input query and runs in a loop using the sandbox operations to accomplish the coding task and return the output.
+
+When AgentCore Code Interpreter is opted-out, we use open-interpreter, an open source and local code interpreter that can write, execute, and troubleshoot code.
+
+
+## Short Term Memory
+
+In Bedrock Agents, by default, agents have short term memory of an entire session’s messages. This means that the user can ask any number of questions within a session, with the agent keeping earlier messages from that session in its context.
+
+The utility will use an in-memory saver as a solution for this. In Langchain, we use an in-memory store to save the session’s messages in a thread for that session. In Strands, we use a Sliding Conversation Manager, which can maintain in-memory context of any number of earlier messages in a session.
+
+
+## Long Term Memory → AgentCore Memory
+
+In Bedrock Agents, users can enable Long Term Memory for their agent. This is based on session summarization, where BR Agents uses an LLM to summarize the conversation’s discussion topics based on a session’s messages. This occurs on the end of each session, and customers can configure a max number of sessions and max days threshold to keep the summaries. In the orchestration prompt in BR agents, a synopsis of the long-term memory, consisting of multiple of these session summaries, is injected.
+
+In Bedrock Agents, users can enable Long-Term Memory for their agents. This system is based on session summarization, where Bedrock Agents use an LLM to summarize discussion topics from each session’s messages.
+
+* Summarization happens at the end of each session.
+* Customers can configure:
+    * The maximum number of sessions to retain.
+    * A maximum age (in days) for how long to keep the summaries.
+* During orchestration, Bedrock Agents inject a synopsis of long-term memory—which consists of multiple session summaries—into the system prompt.
+
+In AgentCore Memory, the utility implements a similar memory model using a summarization strategy with a dedicated memory store:
+
+```
+{
+    "summaryMemoryStrategy": {
+        "name": "SessionSummarizer",
+        "namespaces": ["/summaries/{actorId}/{sessionId}"],
+    }
+}
+```
+
+On each entrypoint invocation, formatted messages are saved to this memory store by generating an event that includes the correct `userId` and `sessionId` (both provided to the entrypoint). During agent initialization (inside the `get_agent` loop in the output code), the top session summaries are retrieved from the memory store and formatted to match the Bedrock Agents' memory style. These formatted summaries are then injected into the agent's system prompt as a memory synopsis.
+
+If AgentCore Memory is opted out, then we replicate the behavior with a local long term memory manager, which uses a memory summarization LLM and the memory summarization BR agents prompt to create and manage session summaries. The generated summaries are saved and maintained in a local session summaries JSON file.
+
+
+## Pre/Post-Processing Step
+
+In Bedrock Agents, customers can enable and override pre-processing and post-processing steps in their agents. These steps are meant to be taken at the start and end, respectively, of agent invocation.
+
+If the pre-processing step is enabled, then within the `invoke_agent` function, the utility will use the pre-processing prompt on the user query and append the output to the query before passing this on to the orchestration loop. If the post-processing step is enabled, then the post-processing prompt is used on the orchestration loop output, and this result is returned as the output of `invoke_agent`.
+
+
+## User Input
+
+In Bedrock Agents, an agent can ask for human input. This may be for clarification or to ask for missing parameters for a tool call. If enabled, the utility will create a human input tool, which can be invoked with a question by the agent and asks the user for CLI input on that question. This answer is then returned to the agent as the tool’s output.
+
+
+## Traces → AgentCore Observability
+
+In Bedrock Agents, users can view traces that describe pre/post processing steps, routing classifier steps, guardrail invocation, agent orchestration, and other information. These traces are in a format specific to Bedrock Agents, and can be viewed either in the console or as output of an invoke_agent call to a BR agent.
+
+The equivalent for this with AgentCore is to use AgentCore Observability (if not opted-out). For both Langchain and Strands, the agent will output OTEL logs on a session, trace, and span level. These logs are captured by AgentCore Observability when the agent is deployed to AgentCore Runtime, and the logs will be visible in CloudWatch under the GenAI Observability section.
+
+
+## Multi-Agent Collaboration
+
+In Bedrock Agents, users can promote an agent and add collaborators to it. This hierarchy can be up to 5 levels deep. A collaborator can receive shared conversation history from the parent, and can be invoked with routing mode (parent uses a routing classifier prompt to find a relevant collaborator for a user query) or supervisor mode (an agents-as-tools approach).
+
+The utility's approach to this is to recursively translate a parent agent and its children, and then orchestrate them together via an Agents-as-Tools approach by default. If conversation sharing is enabled, then the parent will inject its state into the child's via these collaboration tools. If routing mode is enabled for the parent, then the parent agent uses a routing classifier prompt, before orchestration, to invoke a relevant child agent. In AgentCore Runtime, the code for a parent agent and its children are packaged together, in the same container image, to enable this setup.

{bedrock_agentcore_starter_toolkit-0.1.5 → bedrock_agentcore_starter_toolkit-0.1.6}/documentation/docs/user-guide/import-agent/overview.md

@@ -7,6 +7,11 @@ The `import-agent` utility enables you to migrate existing Amazon Bedrock Agents
 > Review the generated code, evaluate agent behavior, and make necessary changes before deploying.
 > Extend the agent with additional tools, memory, and other features as required.
 
+> **Note**
+> Use the output agent definition as a starting point for your custom agent implementation.
+> Review the generated code, evaluate agent behavior, and make necessary changes before deploying.
+> Extend the agent with additional tools, memory, and other features as required.
+
 ## What is Import Agent?
 
 The import-agent utility automates the process of:
@@ -14,6 +19,7 @@ The import-agent utility automates the process of:
 1. **Fetching** your existing Bedrock Agent configuration
 2. **Converting** it to LangChain/LangGraph or Strands framework code
 3. **Integrating** AgentCore primitives (Memory, Code Interpreter, Observability, Gateway)
+3. **Integrating** AgentCore primitives (Memory, Code Interpreter, Observability, Gateway)
 4. **Deploying** to AgentCore Runtime (optional)
 
 ## Key Benefits
@@ -34,7 +40,7 @@ Ideal for teams wanting AWS-native agent development with streamlined patterns.
 
 ## Generated Output
 
-The utility generates a SUPPORTED agent implementation including:
+The utility generates an agent implementation including:
 
 - **Agent Code**: Framework-specific implementation of your Bedrock Agent
 - **Dependencies**: All required packages and versions
@@ -92,3 +98,4 @@ flowchart TD
 - [Quick Start Guide](quickstart.md) - Get started in 5 minutes
 - [Configuration Reference](configuration.md) - Detailed parameter guide
 - [Design Choices](design.md) - Details on the design of the generated agent
+- [Design Choices](design.md) - Details on the design of the generated agent

{bedrock_agentcore_starter_toolkit-0.1.5 → bedrock_agentcore_starter_toolkit-0.1.6}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "bedrock-agentcore-starter-toolkit"
-version = "0.1.5"
+version = "0.1.6"
 description = "A starter toolkit for using Bedrock AgentCore"
 readme = "README.md"
 requires-python = ">=3.10"
@@ -28,7 +28,7 @@ classifiers = [
 dependencies = [
     "boto3>=1.39.7",
     "botocore>=1.39.7",
-    "bedrock-agentcore>=0.1.1",
+    "bedrock-agentcore>=0.1.2",
     "docstring_parser>=0.15,<1.0",
     "httpx>=0.28.1",
     "jinja2>=3.1.6",

{bedrock_agentcore_starter_toolkit-0.1.5 → bedrock_agentcore_starter_toolkit-0.1.6}/src/bedrock_agentcore_starter_toolkit/operations/gateway/client.py

@@ -84,6 +84,7 @@ class GatewayClient:
             "protocolType": "MCP",
             "authorizerType": "CUSTOM_JWT",
             "authorizerConfiguration": authorizer_config,
+            "exceptionLevel": "DEBUG"
         }
         if enable_semantic_search:
             create_request["protocolConfiguration"] = {"mcp": {"searchType": "SEMANTIC"}}

{bedrock_agentcore_starter_toolkit-0.1.5 → bedrock_agentcore_starter_toolkit-0.1.6}/tests/operations/gateway/test_gateway_client_init.py

@@ -164,6 +164,7 @@ class TestCreateMCPGateway:
                 "authorizerType": "CUSTOM_JWT",
                 "authorizerConfiguration": authorizer_config,
                 "protocolConfiguration": {"mcp": {"searchType": "SEMANTIC"}},
+                "exceptionLevel": "DEBUG",
             }
             self.client.client.create_gateway.assert_called_once_with(**expected_request)
 

{bedrock_agentcore_starter_toolkit-0.1.5 → bedrock_agentcore_starter_toolkit-0.1.6}/uv.lock

@@ -73,7 +73,7 @@ wheels = [
 
 [[package]]
 name = "bedrock-agentcore"
-version = "0.1.1"
+version = "0.1.2"
 source = { registry = "https://pypi.org/simple" }
 dependencies = [
     { name = "boto3" },
@@ -84,14 +84,14 @@ dependencies = [
     { name = "urllib3" },
     { name = "uvicorn" },
 ]
-sdist = { url = "https://files.pythonhosted.org/packages/b6/68/78ff9be5b18260f657291772e1aaa3856ef78da5a5465b9f0356c818f415/bedrock_agentcore-0.1.1.tar.gz", hash = "sha256:cade2a39ae1bbad5f37842f0bb60758d4ff25fc56e9271404972f0ed71c8b074", size = 170185, upload-time = "2025-07-23T22:48:33.949Z" }
+sdist = { url = "https://files.pythonhosted.org/packages/fe/7c/2de54122abd86ad73cf42b5ba3f26410bb043cca685edc3f90d166b8bc38/bedrock_agentcore-0.1.2.tar.gz", hash = "sha256:9063dddef43c0f6c492d8fec852a6a8c1c630f7bcee07aa3f0d218290370988b", size = 204302, upload-time = "2025-08-11T21:27:50.053Z" }
 wheels = [
-    { url = "https://files.pythonhosted.org/packages/8c/3c/81ed595a5077fe190361c1409955ee0837c402a3f0355e41ab006588d749/bedrock_agentcore-0.1.1-py3-none-any.whl", hash = "sha256:cec53a9c15bcf922f943540d9b14b75e6c69bae5483b9c32c8cd0babbc541804", size = 48910, upload-time = "2025-07-23T22:48:32.901Z" },
+    { url = "https://files.pythonhosted.org/packages/63/e0/d66fbc2f7620214964039ffe9a675dd1e8e23245c61cd7b280f78d606d02/bedrock_agentcore-0.1.2-py3-none-any.whl", hash = "sha256:2e45b5e3d14ac1828881f089456fb35c48233ab7aad8c4d83c525cf4b2ab92c2", size = 48747, upload-time = "2025-08-11T21:27:48.804Z" },
 ]
 
 [[package]]
 name = "bedrock-agentcore-starter-toolkit"
-version = "0.1.5"
+version = "0.1.6"
 source = { editable = "." }
 dependencies = [
     { name = "autopep8" },
@@ -139,7 +139,7 @@ dev = [
 [package.metadata]
 requires-dist = [
     { name = "autopep8", specifier = ">=2.3.2" },
-    { name = "bedrock-agentcore", specifier = ">=0.1.1" },
+    { name = "bedrock-agentcore", specifier = ">=0.1.2" },
     { name = "boto3", specifier = ">=1.39.7" },
     { name = "botocore", specifier = ">=1.39.7" },
     { name = "docstring-parser", specifier = ">=0.15,<1.0" },

bedrock_agentcore_starter_toolkit-0.1.5/documentation/docs/user-guide/import-agent/design.md

@@ -1,114 +0,0 @@
-# Import Agent Design
-
-Design overview for the import-agent utility, explaining the choices behind the generated agent.
-
-## Feature Support
-
-| Bedrock Agent Feature                               | Langchain | Strands | AgentCore               |
-|-----------------------------------------------------|-------------------------------------|----------------------------------|--------------------------------------------------|
-| *Guardrails*                                        | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Orchestration (via reAct)*                         | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Knowledge Bases*                                   | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Code Interpreter*                                  | SUPPORTED                            | SUPPORTED                         | SUPPORTED: 1P Code Interpreter                    |
-| *Lambda Function Definitions*                       | SUPPORTED                            | SUPPORTED                         | SUPPORTED: AgentCore Gateway                  |
-| *Lambda OpenAPI Definitions*                        | SUPPORTED                            | SUPPORTED                         | SUPPORTED: AgentCore Gateway                  |
-| *Return of Control*                                 | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Short Term (Conversational) Memory*                | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Long Term (Cross-Session) Memory*                  | SUPPORTED                            | SUPPORTED                         | SUPPORTED: AgentCore Memory                      |
-| *Session Summarization*                             | SUPPORTED                            | SUPPORTED                         | SUPPORTED: AgentCore Memory                      |
-| *Pre Processing Step*                               | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Post Processing Step*                              | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *KB Generation Routing/Optimizations*               | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Idle Timeouts*                                     | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *User Input (as a tool)*                            | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Traces*                                            | SUPPORTED                            | SUPPORTED                         | SUPPORTED: AgentCore Observability               |
-| *Multi-Agent Collaboration - Supervisor Mode*       | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Multi-Agent Collaboration - Routing Mode*          | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Multi-Agent Collaboration - Conversation Relay*    | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Custom Bedrock Model Usage*                        | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Chat Interface (via CLI)*                          | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Custom Inference Configurations*                   | SUPPORTED                            | SUPPORTED                         |                                                  |
-| *Agent Deployment*                                  | N/A                                  | N/A                              | SUPPORTED: AgentCore Runtime                     |
-| *Lambda Parsing and Orchestration*                  | N/A                                  | N/A                              |                                                  |
-
-
-## Action Groups -> AgentCore Gateway Target
-
-In Bedrock Agents, users can define Action Groups for their agent. An Action Group is a collection of tools either executed via Lambda or with a local callback (Return of Control) and defined with an OpenAPI spec or structured function schema. BR Agents, at runtime, will call your Lambda function with an event of the following format, depending on which schema option you chose: [https://docs.aws.amazon.com/bedrock/latest/userguide/agents-lambda.html](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-lambda.html).
-
-In AgentCore Gateway, we create one gateway for the output agent. Each action group is equivalent to one target in this gateway, and each function or path/method is one tool in this target. In order to maintain backwards compatibility with the action group lambda functions, we create a proxy Lambda function that serves as the Lambda for all the gateway's targets. This proxy handles an incoming tool call in Gateway's format, finds the correct end action group Lambda function to call for that tool, and then reformats data to call that Lambda function and return its output.
-
-If AgentCore Gateway is opted out, then the utility generates local tools for each function and path/method, exposes their relevant argument schema to the agent via Pydantic model generation, then has each tool format its input correctly to call the relevant action group lambda. This also applies for ROC action groups, where such a tool invocation will ask the user for local input to continue execution.
-
-## Session Memory -> AgentCore Memory
-
-In Bedrock Agents, users can enable Long Term Memory for their agent. This is based on session summarization, where BR Agents uses an LLM to summarize the conversation’s discussion topics based on a session’s messages. A max number of sessions and max days threshold can be set. In the orchestration prompt in BR agents, a synopsis of the long-term memory, consisting of multiple of these session summaries, is injected.
-
-In AgentCore Memory, we create a memory store adopting the summarization strategy:
-
-```python
-{
-    "summaryMemoryStrategy": {
-        "name": "SessionSummarizer",
-        "namespaces": ["/summaries/{actorId}/{sessionId}"],
-    }
-}
-```
-
-On each entrypoint invocation, we save formatted messages to this memory store by creating an event with the correct user id and session id. During agent initialization within the agent update loop (`get_agent`), we retrieve the top session summary memories from the memory store, format the memories correctly, and inject them as a memory synopsis into the agent's system prompt.
-
-If AgentCore Memory is opted out, then we replicate the behavior with a local long term memory manager, which uses a memory summarization LLM and the memory summarization BR agents prompt to create and manage session summaries. The generated summaries are saved and maintained in a local session summaries JSON file.
-
-## Code Interpreter -> AgentCore Code Interpreter
-
-In Bedrock Agents, users can enable Code Interpreter. This gives a Bedrock Agent access to a sandbox for it to write, troubleshoot, and return the output of code.
-
-We use AgentCore Code Interpreter for an equivalent experience. The utility defines a `code_tool` which creates a code sandbox session and defines a sub-agent with access to code interpreter operations (as tools). This sub-agent is fed the code tool's input query and runs in a loop using the sandbox operations to accomplish the coding task and return the output.
-
-When AgentCore Code Interpreter is opted-out, we use open-interpreter, an open source and local code interpreter that can write, execute, and troubleshoot code.
-
-## Traces -> AgentCore Observability
-
-In Bedrock Agents, users can view traces that describe pre/post processing steps, routing classifier steps, guardrail invocation, agent orchestration, and other information. These traces are in a format specific to Bedrock Agents, and can be viewed either in the console or as output of an invoke_agent call to a BR agent.
-
-The equivalent for this with AgentCore is to use AgentCore Observability (if not opted-out). For both Langchain and Strands, the agent will output OTEL logs on a session, trace, and span level. These logs are captured by AgentCore Observability when the agent is deployed to AgentCore Runtime, and the logs will be visible in CloudWatch under the GenAI Observability section.
-
-## Guardrails
-
-In Bedrock Agents, users can add Bedrock Guardrails to their agent. This applies the guardrail on the model level and Bedrock Agents will have defined behavior for when a guardrail is invoked to redact or block an input. Equivalently, the utility applies the same guardrail on Bedrock models, as there is support for this in both Langchain and Strands.
-
-## Knowledge Bases
-
-In Bedrock Agents, users can add existing Knowledge Bases (defined via Bedrock Knowledge Bases) to their agent via the Console or SDK. The AgentCore + Langchain/Strands equivalent of this feature is to use each of those KBs to define a KB retrieval tool for an agent to use. This tool uses the AWS SDK to retrieve from connected knowledge bases using a query decided by the agent and then returns the document results for the agent to use.
-
-## Multi-Agent Collaboration
-
-In Bedrock Agents, users can promote an agent and add collaborators to it. This hierarchy can be up to 5 levels deep. A collaborator can receive shared conversation history from the parent, and can be invoked with routing mode (parent uses a routing classifier prompt to find a relevant collaborator for a user query) or supervisor mode (an agents-as-tools approach).
-
-The utility's approach to this is to recursively translate a parent agent and its children, and then orchestrate them together via an Agents-as-Tools approach by default. If conversation sharing is enabled, then the parent will inject its state into the child's via these collaboration tools. If routing mode is enabled for the parent, then the parent agent uses a routing classifier prompt, before orchestration, to invoke a relevant child agent. In AgentCore Runtime, the code for a parent agent and its children are packaged together, in the same container image, to enable this setup.
-
-## Code Structure
-
-In general, the generated agents follow the structure below:
-
-1. Imports
-2. Model configurations
-3. Prompt definitions
-4. Action Group / MCP Tools
-5. Knowledge Base Tools
-6. Agent Initialization and Update Loop
-7. Agent Invocation Logic
-8. AgentCore Runtime Entrypoint
-9. CLI for Local Agent Testing
-
-## Prompt Generation, Testing, and Agent Similarity
-
-Bedrock Agents prompts are constructed at runtime, by substituting in template fixtures (ie. variables in the prompt). For example, an orchestration prompt may have the fixture called knowledge_base_guidelines. This variable is filled in depending on the model provider and model version in use.
-
-To approximate the same behavior and deliver translated agents that are functionally equivalent, the utility uses ONE collection of template fixtures (`template_fixtures_merged.json`) and substitutes them in to build the correct prompts.
-
-This, along with all the design choices above, yield translated agents that are very similar semantically and functionally to the original Bedrock Agents. Below are functional testing results on a sample of 400 randomly generated and translated BR agents on a shared prompt suite:
-
-- ~95% match in average semantic similarity of responses via text embedding
-- 97.50% match in Langchain agent usage of KBs, collaborators, guardrails, action groups
-- 100% match in Strands agent usage of KBs, collaborators, guardrails, action groups