Building AI Applications and Agents with LangChain on AWS

AWS lifecycle notice (June 30, 2026) — Amazon Bedrock Agents Classic is in maintenance for new customers after July 30, 2026. Net-new agent builds should use Bedrock AgentCore. Full matrix: lifecycle roundup.

Enterprise AI applications are not chatbots with a nicer theme. They have to reach APIs, documents, tickets, and metrics without turning the foundation model into a superuser.

LangChain is a development framework for that composition. As of August 27, 2026, the current LangChain OSS overview describes create_agent: a configurable harness around a model loop — prompt, tools, and middleware — not a cloud platform. On June 17, 2026, AWS shipped AgentCore Harness GA for a different harness: a managed, config-driven agent loop on AgentCore Runtime (What’s New). Same English word. Different products. This post keeps them apart.

First-party signals we reuse (not new client outcomes) — Gateway server-side tools cut median tool round-trip ~180 ms → ~95 ms on a B2B CRM assistant (12 tools, ~8k turns/day) — Gateway post. Support-style AgentCore at 50K sessions/mo ~$791/mo platform + model (decision guide). Calculator: AgentCore pricing.

Reproduce this — Artifacts under examples/architecture-blog-2026/langchain-bedrock/. python3 -m py_compile langchain_bedrock_stub.py. Gates: monday-checklist.md. Diagram: architecture.drawio.

Opinionated take: use LangChain to compose Bedrock models with narrow tools and retrieval in your repo. Host production agents on AgentCore Runtime (or stay on a thin API process if the loop is truly simple). Graduate to LangGraph on AgentCore Runtime when you need an explicit stateful graph. Do not pick LangChain instead of AgentCore — they do not compete.

Trade-off you accept: you own package upgrades and prompt/tool schemas, in exchange for portable application code and Bedrock-side residency, Guardrails, and IAM.

Building more than a chatbot

A chatbot is messages in → model out. An enterprise application also has to:

• Call internal APIs with the caller’s identity, not a shared god key.
• Read documents the user is allowed to see (Knowledge Bases + ACLs, not a public crawl).
• Ground answers in business systems (CRM, ITSM, billing) through controlled interfaces.
• Expose tools that cannot mutate payroll because a prompt said “please.”

LangChain’s job is to connect the language model to that application logic. Amazon Bedrock’s job is the model API and adjacent AI services. AgentCore’s job is session isolation, Memory, Gateway, Identity, and traces when you run an agent in production.

If the product is only “summarize this PDF,” you may need none of the agent stack — ChatBedrockConverse and a document pipeline are enough.

What is LangChain?

LangChain is an open-source framework (and ecosystem of integrations) for LLM applications. The 2026 docs lead with:

Agent = Model + Harness. The harness is everything around the loop: system prompt, tools, middleware that retries, redacts, or routes.

That is application composition. It is not:

• Amazon Bedrock (models, Guardrails, Knowledge Bases).
• AgentCore Runtime (microVM host).
• AgentCore Harness (AWS-managed loop from configuration).
• LangGraph (explicit graph of State / Nodes / Edges).

Official LangChain guidance: use LangGraph when you need advanced orchestration that mixes deterministic and agentic steps (overview). This post stays on the composition layer and links out once when the graph becomes the point.

The building blocks of a LangChain application

Stick to what current LangChain architecture actually ships:

You do not need an agent for extraction or classification. Bind tools only when the model must choose an action at runtime.

Context: Python 3.12+, langchain-aws, explicit max tokens; placeholders only.

# langchain-aws ChatBedrockConverse → Bedrock Converse API.
# Pin inference profile IDs to what list-inference-profiles returns in your account.

from langchain_aws import ChatBedrockConverse
from langchain.agents import create_agent

model = ChatBedrockConverse(
    model="us.anthropic.claude-sonnet-4-6",
    region_name="us-west-2",
    max_tokens=1024,
    temperature=0,
)

def lookup_order_status(order_id: str) -> str:
    """Narrow read API — not a database session."""
    ...

agent = create_agent(
    model=model,
    tools=[lookup_order_status],
    system_prompt="Use lookup_order_status for order questions. Never invent shipment facts.",
)

The syntax-checkable stub is langchain_bedrock_stub.py.

LangChain and enterprise system integration

The integration pattern that survives security review:

1. Application authenticates the user (Cognito, Entra ID, IAM Identity Center).
2. LangChain decides whether a tool is needed.
3. Tool implementation calls an internal API with a scoped token — or AgentCore Gateway converts OpenAPI / Lambda / MCP into tools the agent can invoke.
4. Policy (Cedar on Gateway) intercepts writes.

Databases. Expose pre-defined queries or a metrics API. Do not hand the model a connection string. A BI assistant that can SELECT * is an exfiltration product.

Search and documents. Prefer Bedrock Knowledge Bases with metadata filters, or a search API that already enforces ACLs. LangChain loaders are fine for building a corpus in a pipeline; they are not a substitute for authorization at query time.

Internal services. Idempotent, timeout-bounded, audited. Treat model-supplied parameters as untrusted input.

From a real engagement — Same B2B CRM assistant silhouette (12 tools, ~8k turns/day): the number that moved was Gateway ~180 ms → ~95 ms median tool round-trip after server-side execution — Gateway post. LangChain (or LangGraph) did not create that delta. The tool bus did. If you are composing CRM tools in LangChain, put them on Gateway before you tune prompts.

Building AI agents with LangChain

LangChain agents are a model calling tools in a loop until the harness stops. You supply:

• A language model (Bedrock Converse).
• Tools with schemas.
• System prompt (and middleware for retries / PII filters).

Complexity shows up when:

• The loop must pause for a human and resume the same workflow state next Tuesday.
• Routing among specialists must be an auditable DAG, not whatever the model feels like.
• You need cycles with caps (retrieve until citations suffice).
• Several agents share working memory with hop limits.

That is where stateful orchestration matters. LangChain’s create_agent is the bounded loop. When the loop is no longer the architecture, use LangGraph with AWS Bedrock AgentCore — State, Nodes, Edges, HITL — on the same Runtime/Memory/Gateway platform.

If you do not have a LangGraph investment and you need AWS-endorsed multi-agent primitives, Harness + Strands is the paved road on this site.

LangChain + Amazon Bedrock

Accessing foundation models. ChatBedrockConverse is the Converse-shaped integration AWS has published in application blogs. Prefer Converse over provider-specific InvokeModel bodies. Cross-region inference profiles (us., eu., global.) are a data-residency decision, not a performance tweak you apply blindly.

Model portability. LangChain’s model interface lets you swap Bedrock model IDs in one place. Portability of governance still depends on staying on Bedrock (IAM, CloudTrail, Guardrails, PrivateLink). Calling OpenAI directly is a different trust boundary — Bedrock vs OpenAI.

AWS-native AI architecture. Knowledge Bases, Guardrails, prompt caching, and inference profiles live in the AWS account. LangChain invokes them; it does not replace them.

Enterprise deployment. Run the app in a VPC, use IAM roles (not long-lived keys in .env), set max_tokens, and enable CloudTrail on bedrock / bedrock-runtime. For PHI, Bedrock eligibility plus your BAA still require log hygiene — HIPAA on Bedrock.

Older snippets that import BedrockChat from langchain_community are legacy. New code should use langchain-aws.

LangChain + AWS Bedrock AgentCore

Suggested production shape:

Business application
    → LangChain application (create_agent / RAG chain)
        → Agent / tool logic (narrow schemas)
            → AgentCore Runtime (optional host; ARM64)
                 ├─ AgentCore Memory
                 ├─ AgentCore Identity
                 └─ AgentCore Gateway + Policy
                      → Enterprise systems
            → Amazon Bedrock (Converse, Guardrails, Knowledge Bases)
            → Observability (OTEL → CloudWatch)

Open the draw.io.

Separation of responsibility. LangChain owns application composition. AgentCore owns production agent infrastructure (what AgentCore is). Bedrock owns models.

AWS documents wrapping framework code in BedrockAgentCoreApp @entrypoint. The public “Use any agent framework” page’s LangChain-ecosystem named sample is LangGraph; AgentCore is still framework-agnostic, and AWS documents Memory integration for LangChain or LangGraph. AgentCore CLI scaffolding that lists LangChain is a convenience, not a requirement to rewrite your app as Harness config.

Do not put a custom LangChain loop “on Harness.” Harness is the managed loop. Custom create_agent code belongs on Runtime (or on compute you already operate).

What broke — Browser left enabled on every turn of a support-style agent. Platform compute dominated; we have published ~3× Runtime-shaped spend on that failure mode (Harness/Strands). Detection: AgentCore cost lines, not model tokens, jumped first. Fix: default Browser/Code Interpreter off; enable per skill. Registering a LangChain web tool without a spend cap has the same shape.

Enterprise use cases

Knowledge assistant

Enterprise documents → ingestion → Knowledge Bases or scoped search → LangChain retrieval tool or 2-step RAG → Bedrock generate → cited response.

Do not rebuild a knowledge base in a sidecar vector store if Bedrock Knowledge Bases already match your connectors. Do not skip ACLs.

Customer support automation

Customer request → application context (ticket id, product, entitlement) → LangChain agent → read tools (order status, policy retrieve) → draft → CRM/ITSM write only through Gateway Policy.

Reuse the CRM assistant lesson: tool I/O latency is a Gateway problem; the model is not.

Business intelligence assistant

Business question → controlled metric interface (semantic layer, approved views) → LangChain → reasoning over returned aggregates → answer with the query id.

Unrestricted warehouse access is not an enterprise best practice. If the question needs a new metric, that is an analytics engineering ticket, not a tool the model invents.

Production architecture considerations

Security. IAM least privilege on InvokeModel for specific profile ARNs. No bedrock:* on the app role. Secrets in Secrets Manager via Identity/Gateway, not in tool docstrings.

Prompt and input validation. Max length, allowed languages, injection tests. Guardrails on the Bedrock path for PII/topics. Remember: Guardrails masking in the API response does not un-log PII in CloudWatch unless you design for that.

Tool permissions. One tool, one capability. Writes gated. Parameters validated before the HTTP call.

Data boundaries. Tenant id from the JWT, not from the prompt. Retrieval filters must use the authenticated tenant.

Observability. OTEL into CloudWatch if on AgentCore; otherwise your APM. Log tool name, latency, and error class — not raw payloads in regulated environments.

Evaluation. Golden questions with expected tool traces. Do not A/B prompts on live traffic without a suite.

Reliability. Timeouts per tool, circuit breakers, idempotency keys on writes. Converse retries: throttling yes; validation no.

Scaling and cost. max_tokens always set. Prompt cache where the model supports it. Session TTL on Memory. Model the AgentCore platform line separately from tokens — 12 components. Classic-era patterns: agentic workflows (AgentCore for net-new).

When LangChain is a good choice

• You are building an application that must mix prompts, tools, and retrieval in code.
• The agent loop is bounded (few tools, clear stop conditions).
• You want model portability across Bedrock IDs behind one interface.
• The team already ships Python/TypeScript LangChain and needs AWS hosting, not a rewrite.
• RAG or tool-calling is the product, not a 12-node compliance DAG.

When LangGraph or another architecture may be better

Use LangGraph when you need explicit stateful graph workflows, cycles with caps, HITL interrupt/resume, or multi-agent coordination a reviewer can audit as edges. That write-up is LangGraph + AWS Bedrock AgentCore.

Use Harness when configuration covers the first agent.

Use Strands on Runtime when you want AWS-endorsed multi-agent primitives without a LangGraph codebase.

Use Step Functions / Bedrock Flows when the workflow is mostly deterministic and the model is a task.

Use Quick Suite for employee permission-aware knowledge work (AgentCore vs Quick).

What to Do This Week

1. One Bedrock Converse path via ChatBedrockConverse with explicit max tokens.
2. One read-only tool with a narrow schema; no SQL.
3. Decide: stay a chain, use create_agent, or move to LangGraph/Strands/Harness — one sentence.
4. If hosting an agent: Runtime ARM64 + Memory actor_id/thread_id, or Harness if config is enough.
5. Gateway for the second tool; Policy LOG_ONLY on any write.
6. Price sessions on the calculator. Walk monday-checklist.md.

What This Post Doesn’t Cover

• LangGraph HITL and checkpoint semantics — LangGraph post.
• AgentCore SKU math — pricing post.
• Deep Agents / LangSmith product setup — LangChain’s own docs; not an AWS control.
• Every langchain-aws class (embeddings, S3 loaders). Verify the package README for the version you pin.
• Region matrices — AgentCore regions and Bedrock model cards.

We have not published a first-party token-per-task benchmark of create_agent vs a raw Converse loop for this date. Measure on your prompts; reuse the Gateway ~180→95 ms figure only for tool I/O.

Need a Bedrock + LangChain application design that stays inside IAM and Gateway Policy? Generative AI on AWS or contact us — AWS Select Tier Partner.