03 – AWS Agentic AI Frameworks Lab: Building with Strands and LangChain

Step 1 — Set up the shared “document corpus”

Both implementations search the same tiny corpus, so define it once and import it into both scripts (or just paste it twice if you want two fully standalone files — that’s what we do below so you can run either one independently).

DOCS = {
    "bedrock-pricing": (
        "Amazon Bedrock charges are based on the number of input and output "
        "tokens processed, plus optional charges for provisioned throughput. "
        "On-demand pricing has no minimum commitment and bills per token."
    ),
    "bedrock-agents": (
        "Amazon Bedrock Agents let you orchestrate multi-step tasks by "
        "combining a foundation model with your own Lambda-backed action "
        "groups and, optionally, a knowledge base for retrieval-augmented "
        "generation."
    ),
    "strands-overview": (
        "Strands Agents is an open-source, model-driven agent SDK from AWS. "
        "Instead of hand-coding a control flow graph, you give the agent a "
        "model, a list of tools, and a prompt, and the model decides which "
        "tools to call and when, in a loop, until it produces a final answer."
    ),
}

Keeping the corpus trivial keeps the diff between the two implementations honest — none of the framework mechanics being tested here change if the “documents” are three sentences or three thousand PDF pages.

Step 2 — Build the research assistant with Strands Agents SDK

Strands’ whole pitch is “model-driven”: you don’t write an explicit graph of steps. You define tools as plain Python functions, hand them to an Agent, and the underlying model (by default a Bedrock-hosted Claude model) decides which tool to call, when, and how many times, looping until it has enough information to answer. Install it first:

pip install strands-agents

Now define the two tools our research assistant needs — a keyword search over the corpus, and a fetch-by-id — using Strands’ @tool decorator. This is the detail that trips people up most often: Strands (like every framework in this space) builds the tool’s JSON schema by introspecting your function’s type hints and docstring.

If either is missing or vague, the model receives a poor or broken schema and either can’t call the tool correctly or calls it with the wrong argument shape.

from strands import Agent, tool
from strands.models import BedrockModel

DOCS = {
    "bedrock-pricing": (
        "Amazon Bedrock charges are based on the number of input and output "
        "tokens processed, plus optional charges for provisioned throughput."
    ),
    "bedrock-agents": (
        "Amazon Bedrock Agents let you orchestrate multi-step tasks by "
        "combining a foundation model with your own Lambda-backed action "
        "groups and, optionally, a knowledge base for retrieval-augmented "
        "generation."
    ),
    "strands-overview": (
        "Strands Agents is an open-source, model-driven agent SDK from AWS. "
        "You give the agent a model, a list of tools, and a prompt, and the "
        "model decides which tools to call and when."
    ),
}


@tool
def search_documents(keyword: str) -> list[str]:
    """
    Search the document corpus for entries whose id or body contains the
    given keyword (case-insensitive) and return the matching document ids.

    Args:
        keyword: The term to search for, e.g. "pricing" or "agents".

    Returns:
        A list of document ids that matched the keyword. Empty if none matched.
    """
    keyword = keyword.lower()
    return [
        doc_id
        for doc_id, body in DOCS.items()
        if keyword in doc_id.lower() or keyword in body.lower()
    ]


@tool
def get_document(doc_id: str) -> str:
    """
    Retrieve the full text of a document by its id.

    Args:
        doc_id: The exact document id, as returned by search_documents.

    Returns:
        The full document text, or an error string if the id is unknown.
    """
    return DOCS.get(doc_id, f"No document found with id '{doc_id}'.")


# Explicitly pin the Bedrock model instead of relying on the SDK default,
# so this lab is reproducible regardless of which region/account you run it in.
bedrock_model = BedrockModel(
    model_id="anthropic.claude-3-5-sonnet-20240620-v1:0",
    region_name="us-east-1",
)

research_agent = Agent(
    model=bedrock_model,
    tools=[search_documents, get_document],
    system_prompt=(
        "You are a research assistant. Use search_documents to find "
        "relevant material, then get_document to read it, then answer the "
        "user's question in 2-4 sentences citing which document(s) you used."
    ),
)

if __name__ == "__main__":
    result = research_agent(
        "How does Amazon Bedrock pricing work, and is it related to agents?"
    )
    print(result)

Run it with python strands_research_assistant.py. Three things stand out:

• The tool loop is implicit. Calling research_agent("...") triggers Strands’ internal loop: send the prompt and tool schemas to the model, receive a tool-use request, execute the matching Python function, feed the result back to the model, repeat until the model returns a final text answer. You never write that loop yourself.
• The model is a first-class, swappable object. Because BedrockModel is just one implementation of Strands’ model-provider interface, swapping to a different Bedrock model, or even a non-Bedrock provider (Anthropic’s direct API, Ollama for local development, OpenAI via LiteLLM), is a one-line change — you’re not rewriting your tool or agent code.
• Docstrings are the API. The Args:/Returns: sections aren’t just style — Strands’ @tool decorator parses them (along with the type hints) to build the JSON schema the model actually sees. Skimpy docstrings produce skimpy schemas produce wrong tool calls.

For the official reference on tool construction and the decorator’s parsing rules, see the Strands Agents tools documentation.

Step 3 — Build the same assistant with LangChain + Bedrock

LangChain takes a different default posture: rather than one model-driven loop object, you typically compose a chat model, a set of tools, and an explicit agent runtime. The current recommended integration for Bedrock chat models in the langchain-aws package is ChatBedrockConverse, which wraps Bedrock’s unified Converse API (tool calling, streaming, and multi-turn chat all go through one endpoint).

It supersedes the older ChatBedrock wrapper for most new work, and both are distinct from the legacy BedrockLLM class, which is a plain text-completion wrapper without native chat or tool-calling support — don’t reach for BedrockLLM for anything agentic.

Install the packages:

pip install langchain-aws langgraph

Why langgraph too? Because LangChain’s older AgentExecutor + create_tool_calling_agent pattern (the one you’ll still find in a lot of tutorials and Stack Overflow answers) has been superseded by LangGraph’s prebuilt create_react_agent, which is the currently recommended way to get a tool-calling agent loop in the LangChain ecosystem without hand-rolling a graph. It gives you the same “model decides which tool to call, in a loop” behavior Strands gives you by default.

from langchain_core.tools import tool
from langchain_aws import ChatBedrockConverse
from langgraph.prebuilt import create_react_agent

DOCS = {
    "bedrock-pricing": (
        "Amazon Bedrock charges are based on the number of input and output "
        "tokens processed, plus optional charges for provisioned throughput."
    ),
    "bedrock-agents": (
        "Amazon Bedrock Agents let you orchestrate multi-step tasks by "
        "combining a foundation model with your own Lambda-backed action "
        "groups and, optionally, a knowledge base for retrieval-augmented "
        "generation."
    ),
    "strands-overview": (
        "Strands Agents is an open-source, model-driven agent SDK from AWS. "
        "You give the agent a model, a list of tools, and a prompt, and the "
        "model decides which tools to call and when."
    ),
}


@tool
def search_documents(keyword: str) -> list[str]:
    """Search the document corpus for entries whose id or body contains the
    given keyword (case-insensitive) and return the matching document ids."""
    keyword = keyword.lower()
    return [
        doc_id
        for doc_id, body in DOCS.items()
        if keyword in doc_id.lower() or keyword in body.lower()
    ]


@tool
def get_document(doc_id: str) -> str:
    """Retrieve the full text of a document by its exact id, as returned by
    search_documents. Returns an error string if the id is unknown."""
    return DOCS.get(doc_id, f"No document found with id '{doc_id}'.")


llm = ChatBedrockConverse(
    model="anthropic.claude-3-5-sonnet-20240620-v1:0",
    region_name="us-east-1",
    temperature=0,
)

research_agent = create_react_agent(
    model=llm,
    tools=[search_documents, get_document],
    prompt=(
        "You are a research assistant. Use search_documents to find "
        "relevant material, then get_document to read it, then answer the "
        "user's question in 2-4 sentences citing which document(s) you used."
    ),
)

if __name__ == "__main__":
    result = research_agent.invoke(
        {
            "messages": [
                (
                    "user",
                    "How does Amazon Bedrock pricing work, and is it related to agents?",
                )
            ]
        }
    )
    print(result["messages"][-1].content)

Run it with python langchain_research_assistant.py. Notice the shape difference immediately: LangChain’s @tool decorator (from langchain_core.tools, not Strands’ @tool) similarly relies on the function’s docstring and type hints to build a schema, but the invocation contract is different — you pass a {"messages": [...]} dict into .invoke() and read the last message back out, rather than calling the agent directly with a string like Strands allows.

That’s a small but real ergonomics gap between the two frameworks for this exact use case.

For the authoritative, currently-maintained reference on this integration, see the LangChain Bedrock chat model documentation, which explicitly recommends the Converse API path (ChatBedrockConverse) “for users who do not need to use custom models.”

Step 4 — Compare what actually happened

Run both scripts against the same question and you should get semantically similar answers — both agents will call search_documents("pricing") or similar, then get_document("bedrock-pricing"), then synthesize an answer that also mentions the agents document since the question asks about a relationship. The interesting part isn’t the output text, it’s what each framework made you write versus made you not write:

Both frameworks solved the identical problem with roughly the same amount of code — the meaningful difference is that Strands treats “agent” as a single first-class object with a batteries-included loop, while LangChain treats “agent” as something you assemble from a chat model, a tool list, and a graph runtime (LangGraph). Neither is objectively less code; they’re different defaults about where the seams are.

Step 5 — Why this comparison matters more than it looks

The real choice you’re evaluating here is where each framework puts its opinions. Strands’ opinion is that the agent loop itself — send prompt and tools, receive a tool-use request, execute, feed back, repeat — is a solved problem that shouldn’t need to be re-implemented per project, so it hides that loop behind one object.

That’s a productive default for a single, coherent unit of behavior: a support bot, a code-review assistant, a research helper like the one in this lab.

LangChain (via LangGraph) has the opposite opinion: the loop is exactly the part you might need to customize, so it exposes it as an explicit, inspectable graph — useful when your “agent” is really a small pipeline with branching logic, human-approval steps, or multi-day checkpointed state.

Neither opinion is wrong; they optimize for different points on the “simple agent” to “complex workflow” spectrum, and it’s worth knowing which end your problem sits on before picking a framework.

One more practical note before Common Mistakes: both frameworks’ tool-calling reliability is ultimately bounded by the underlying model’s tool-use quality, not by the framework. If you see meaningfully different tool-selection behavior between your Strands run and your LangChain run with everything else held constant, look first at system prompt wording and temperature — both configurations here use temperature=0 or Strands’ equally-low default, precisely to keep that variable out of the comparison.