amazon-bedrock-agent-samples: A Notebook Collection for Bedrock Agents, Not a Framework
Example Jupyter notebooks 📓 and code scripts 💻 for using Amazon Bedrock Agents 🤖 and its functionalities
At a glance
- What is it?
- This repository is a set of Jupyter notebooks and Python scripts that show how to build Amazon Bedrock Agents and multi-agent supervisor flows. It is a teaching resource for engineers already inside AWS, and the README says outright that the examples are not meant for production use.
- Who is it for?
- Adopt this repository if you are evaluating Amazon Bedrock Agents and want runnable notebooks that exercise code interpretation, guardrails, knowledge bases, inline agents and supervisor mode before you commit to an architecture. Skip it if you need a maintained library, a deployment pipeline, or anything you can ship without rewriting.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 163 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What amazon-bedrock-agent-samples is actually for
The problem this repository addresses is not a missing library. It is the gap between the Bedrock Agents API surface and a working mental model of it. The API exposes concepts such as action groups, orchestration, traces and supervisor mode, and the documentation for each is separate. This repository collects runnable examples so you can see those concepts assembled. The README frames the intent directly: the examples "demonstrate concepts and techniques but are not intended for direct use in production environments." That sentence sets the ceiling on what you should expect.
The audience is narrow and specific. You need an AWS account with Bedrock model access, Python, and enough familiarity with boto3 to read the helper classes in src/utils/. The README notes the solutions use the boto3 SDK in Python, then lists equivalent SDK entry points for C++, Go, Java, JavaScript, Kotlin, .NET, PHP, Ruby, Rust, SAP ABAP and Swift. That list is useful mainly as a signal: the concepts transfer across SDKs, but every sample here is Python. If your team writes Go or TypeScript, you are reading these notebooks for the sequence of API calls, not for code you will paste.
The folder split: examples, shared tools, and helper classes
The repository structure separates three concerns. Under examples/agents/ sit single-agent samples: code interpretation, guardrails integration, knowledge base integration, long term memory, models not yet optimized for Bedrock Agents, a CDK agent, computer use, custom orchestration, inline agents, LangChain tools with inline agents, conversation history management, OpenAPI schema agents, user confirmation before action execution, and a connected house agent built with CloudFormation. Under examples/multi_agent_collaboration/ sit the supervisor-mode samples, starting with 00_hello_world_agent and continuing through domain-flavored ones such as devops_agent and energy_efficiency_management_agent.
The third piece is src/. The README describes src/shared/ as "shared tools that can be reused by Amazon Bedrock Agents via Action Groups," naming Web Search, Working Memory and Stock Data Lookup. Those are the pieces an agent calls at runtime, not the pieces that define the agent. src/utils/ is described as utilities that provide "a higher level of abstraction than the underlying APIs," with files including bedrock_agent_helper.py, bedrock_agent.py and knowledge_base_helper.py. That helper layer is where most of the reading effort goes. The notebooks are thin; the helpers are where resource creation, polling and cleanup are actually implemented.
Multi-agent collaboration and what supervisor mode changes
The multi-agent examples are the part of this repository that is hardest to reproduce from API documentation alone. The README describes two modes. Supervisor mode plans and executes complex tasks across agents. Routing mode does intent classification across agents and falls back to supervisor mode when a single intention cannot be detected. That fallback rule is the detail worth noting: routing is a classifier in front of the same supervisor machinery, so a misclassified request does not dead-end, it escalates.
The README also states that traces let you observe agent behavior across multi-agent flows, and that guardrails, security and privacy apply as they do across Amazon Bedrock features. Traces are the practical debugging surface here. When a supervisor hands a subtask to the wrong collaborator, the trace is where you see the handoff. If you are evaluating whether multi-agent is worth the added latency and cost for your use case, the hello world sample under examples/multi_agent_collaboration/00_hello_world_agent/ is the smallest thing in the repository that exercises the pattern, and it is the right starting point before the domain-specific agents.
Getting a sample running: the path the README describes
There is no install command for the repository as a whole. The Getting Started section gives three steps. First, navigate to src/ for details. Second, navigate to the example you want to deploy under examples/. Third, follow the deployment steps in that example's README.md. The README does not inline those steps, so the real instructions live at paths like examples/agents/agent_with_code_interpretation/README.md and examples/multi_agent_collaboration/startup_advisor_agent/README.md.
That is a deliberate structure and also a friction point. You cannot judge setup cost from the top-level README, because each example may create different resources. A guardrails sample and a knowledge base sample will not share prerequisites. Expect to read the per-example README before you know what you are provisioning. The one shared entry point is the helper layer in src/utils/, particularly bedrock_agent_helper.py, which is where the boto3 calls that create and wire an agent are concentrated. If you want to understand the mechanism rather than run a notebook, read that file first and treat the notebooks as call sequences against it.
The experimental label is the main limitation
The README opens with a caution block: the examples are for experimental and educational purposes only and are not intended for direct use in production. It also directs you to put Amazon Bedrock Guardrails in place to protect against prompt injection, linking the Bedrock prompt injection documentation. That is not boilerplate hedging. It tells you the samples do not carry the input validation, retry behavior or error handling you would need if an agent were taking real actions on real systems.
The repository also has no releases listed, so there is no versioned artifact to pin. You are tracking the main branch. For a samples repository that is normal, but it means a helper signature in src/utils/ can change between the time you read a notebook and the time you run it. The wrong-tool case is straightforward: if you need a supported library with a stability contract, or a deployment path you can hand to an operations team, this is not it. The CDK agent sample under examples/agents/cdk_agent/ is the closest thing to infrastructure-as-code here, and it is still one example among many rather than a supported module.
Where this sits next to agent frameworks like LangChain
The honest comparison is not a competitor product but a different layer. Frameworks such as LangChain give you an orchestration library you import and run yourself, with model and tool abstractions you control. Bedrock Agents puts orchestration inside the managed service: you define an agent, attach action groups, and the service handles planning and invocation, with traces emitted for inspection. The difference shows up in what you own. With a framework, you own the loop, the retries and the deployment. With Bedrock Agents, you own the agent definition, the action group schemas and the IAM permissions, and AWS runs the rest.
This repository reflects that split. There is no agent runtime in it. The code creates agents through boto3, points them at Lambda-backed or schema-backed action groups, and reads the results back. One sample, examples/agents/langchain_tools_with_inline_agent/, sits at the boundary, using LangChain tools with inline agents. That is the sample to read if you are deciding between the two approaches, because it shows what the managed path looks like when your tools already live in a framework. If your tools are plain HTTP endpoints with an OpenAPI schema, examples/agents/open_api_schema_agent/ is the more direct fit.
Maintenance cost and the Apache-2.0 licence
The repository is licensed Apache-2.0 and is not archived. The last push recorded is 2026-04-05, so it is active. Apache-2.0 permits commercial use, modification and redistribution, and includes a patent grant. It also means the samples come with no warranty, which aligns with the README's own statement that they are not for production. None of this is legal advice; if you copy helper code into a product, run the licence question past whoever handles that for your organization.
The maintenance cost that matters is not the licence, it is the rewrite. Because there is no release to pin and the helpers are the substance, upgrading means diffing src/utils/ against your fork rather than bumping a version. Budget for that. The upside is the same property: the helpers are small enough to read in an afternoon, which is more than can be said for most SDKs you would otherwise reverse-engineer from API references.
Editorial conclusion
Adopt this repository if you are evaluating Amazon Bedrock Agents and want runnable notebooks that exercise code interpretation, guardrails, knowledge bases, inline agents and supervisor mode before you commit to an architecture. Skip it if you need a maintained library, a deployment pipeline, or anything you can ship without rewriting. Before you spend time on a specific folder, open its own README.md and confirm the deployment steps and prerequisites, because the top-level README only points you there and does not repeat them.
Community notes