AI Solutions Architect Bootcamp — Day 1, Lesson 7: Agentic AI and LangGraph

You scored 5/5 in Lesson 6 on RAG. That means you've completed six foundational topics: LLMs, tokens, context, inference, embeddings, and RAG. Today we connect them into a system that can reason about a task, select tools, execute actions, maintain state, and pause for human approval.

Lesson 7 of 7 — Final lesson, Day 1 · 60–75 minutes · Python + LangGraph · AWS Bedrock

Because you already have experience with enterprise workflow engines and building AI applications, we'll approach this from an enterprise architecture perspective — not just building a chatbot.

Day 1 progress: 6 of 7 lessons completed · Current: Agentic AI and LangGraph · Next milestone: Day 1 architecture assessment

1. What is agentic AI?

An AI agent is a system that uses a model to help determine actions toward a goal, often by selecting tools, observing results, and deciding what to do next.

System	What determines the next step?	Example
Traditional workflow	Predetermined business logic	An enterprise workflow engine routes a claim according to rules
LLM application	Application invokes a model for a response	Summarize a claim
AI agent	Model influences which action or tool comes next	Investigate a claim using available tools

An agent does not need unlimited autonomy. In enterprise systems, the most reliable approach is often to combine deterministic workflows with carefully bounded agent decisions.

Example: insurance claim assistant

A user asks: "Check my rejected claim, identify whether it qualifies for reopening, and prepare the next steps."

A normal chatbot might explain the general policy. A RAG assistant might retrieve and summarize the relevant policy. An agentic system could additionally:

1. Retrieve the claim record.
2. Search the applicable reopening policy.
3. Determine whether required information is missing.
4. Ask for supporting evidence.
5. Prepare a reopening request.
6. Route it for human approval.
7. Submit the request only when authorized.

The critical distinction is that the agent can interact with systems, not merely generate text.

2. Agent vs workflow: the architectural boundary

Here's the rule to remember: use deterministic code for decisions that must be predictable. Use model-driven decisions where interpretation and flexibility add value.

Consider a claim reopening process:

Claim received	Deterministic workflow entry
AI analysis	Extract facts and retrieve supporting policy
Business rule validation	Eligibility and permissions checked in code
Human approval	Required before consequential action
Authorized case update	Audited, idempotent transaction

Mature business process and case management engines already excel at structured case lifecycles, SLAs, approvals, and auditability. LangGraph complements that with model-driven reasoning and tool orchestration. It doesn't automatically replace a mature business process engine.

3. What is LangGraph?

LangGraph is a framework for building stateful agent and workflow applications using graphs. Its central concepts are:

Concept	Meaning	Workflow engine analogy
State	Shared data carried through execution	Case data
Node	Function that performs work	Processing step
Edge	Connection between nodes	Transition
Conditional edge	Chooses a next node based on state	Decision routing
Checkpointer	Persists execution state	Persisted case state
Interrupt	Pauses execution for external input	Approval or assignment wait
Store	Holds cross-thread information	Shared application data

The analogy is useful, but LangGraph and a typical case management engine have different execution and persistence models.

A basic LangGraph workflow

START → Read claim → Validate → Route by status → Continue, or Request details

This is a graph, but it isn't necessarily an autonomous agent. A graph can be entirely deterministic. LangGraph is an orchestration framework; agentic behavior comes from how you use model decisions inside the graph.

4. Your first LangGraph application

Let's write a small, executable graph. Install:

python -m pip install -U langgraph

from typing import TypedDict, Literal
from langgraph.graph import StateGraph, START, END


class ClaimState(TypedDict):
    claim_id: str
    status: str
    message: str


def inspect_claim(state: ClaimState):
    # Simulated result from an authoritative claim system.
    status = "rejected"
    return {"status": status}


def route_claim(state: ClaimState) -> Literal["review", "complete"]:
    if state["status"] == "rejected":
        return "review"
    return "complete"


def review_claim(state: ClaimState):
    return {"message": "Rejected claim requires reopening review."}


def complete_claim(state: ClaimState):
    return {"message": "Claim does not require reopening review."}


builder = StateGraph(ClaimState)
builder.add_node("inspect", inspect_claim)
builder.add_node("review", review_claim)
builder.add_node("complete", complete_claim)
builder.add_edge(START, "inspect")
builder.add_conditional_edges(
    "inspect", route_claim, {"review": "review", "complete": "complete"}
)
builder.add_edge("review", END)
builder.add_edge("complete", END)

graph = builder.compile()
result = graph.invoke({"claim_id": "CLM-1042", "status": "", "message": ""})
print(result["message"])

Understand every component

ClaimState defines the state schema. inspect_claim is a node that returns a partial state update. route_claim selects a branch. add_conditional_edges connects the routing result to the appropriate node. compile() produces the executable graph. invoke() runs it.

Notice that this example contains no LLM at all. That's intentional. Before building agents, you need to understand graph execution independently.

5. Cycles: what makes agent graphs powerful?

Traditional workflows often move forward through predefined stages. Agent graphs can contain cycles. A typical cycle is:

Reason → Select tool → Execute tool → Observe result → Reason again

But an uncontrolled cycle can run indefinitely or make excessive calls. Production controls should include recursion or step limits, tool timeouts, retry budgets, maximum spend, and explicit termination conditions. For example, LangGraph supports graph execution limits through recursion_limit.

Interactive agent-tool loop simulator

Agent-Tool Loop Simulator

Click "Step" to advance through Reason → Select tool → Execute tool → Observe. The agent needs 3 full cycles to gather enough evidence to finish. Watch what happens when steps exceed the recursion limit.

Recursion limit (max graph steps)
10

Current phase

Not started

Steps taken

0

Press Step to begin.

6. Tools: giving an agent capabilities

A tool is a callable operation exposed to the model-driven workflow. Examples:

• get_claim_status(claim_id)
• search_policy(question)
• calculate_days_since_rejection(claim_id)
• prepare_reopening_request(claim_id)
• submit_reopening_request(request_id)

Notice the difference between reading and writing. Read-only tools retrieve information. Write tools modify external state and may require approval.

Python tool definitions

from langchain_core.tools import tool


@tool
def get_claim_status(claim_id: str) -> str:
    """Retrieve the status of an authorized insurance claim."""
    # Demo only. A real implementation checks identity,
    # authorization, and the authoritative claim system.
    return f"Claim {claim_id}: rejected"


@tool
def search_claim_policy(question: str) -> str:
    """Search approved claim reopening policy documents."""
    return (
        "Policy 4.2: Reopening after 30 days "
        "requires supervisor approval."
    )


tools = [get_claim_status, search_claim_policy]

A tool's name, description, and input schema help the model decide when and how to call it. But a tool call proposed by an LLM is not automatically authorized. Your application must validate tool arguments, enforce permissions, and prevent unsafe or duplicate actions.

Tool calling vs tool execution

This distinction matters for AWS Bedrock too. The model can return a structured request indicating which tool it wants to use. Your application typically executes that tool and returns the result to the model. The model is not directly granted unrestricted access to your database simply because a tool is defined.

7. Build a real tool-using agent

Now we'll add a model to the graph, using LangChain's Bedrock integration and LangGraph's prebuilt tool node. Install:

python -m pip install -U langgraph langchain-aws langchain-core

from langchain_aws import ChatBedrockConverse
from langgraph.graph import StateGraph, START, END
from langgraph.graph import MessagesState
from langgraph.prebuilt import ToolNode, tools_condition
from langchain_core.messages import SystemMessage

# Uses the tools defined in the previous example.
llm = ChatBedrockConverse(
    model_id="amazon.nova-lite-v1:0",
    region_name="us-east-1",
    temperature=0.1,
    max_tokens=500
)
llm_with_tools = llm.bind_tools(tools)

SYSTEM_PROMPT = """You are an insurance claim analysis assistant.
Use tools to retrieve claim facts and policy evidence.
Never approve or modify a claim.
If information is insufficient, explain what is missing."""


def call_model(state: MessagesState):
    response = llm_with_tools.invoke([
        SystemMessage(content=SYSTEM_PROMPT),
        *state["messages"]
    ])
    return {"messages": [response]}


builder = StateGraph(MessagesState)
builder.add_node("agent", call_model)
builder.add_node("tools", ToolNode(tools))
builder.add_edge(START, "agent")
builder.add_conditional_edges("agent", tools_condition)
builder.add_edge("tools", "agent")

graph = builder.compile()

This example demonstrates the agent-tool loop. It uses simulated tools, so it doesn't retrieve real claims or policies. Tool-calling support must be available for the chosen Bedrock model and Region.

What happens during execution?

1. The model receives the user's question and tool definitions.
2. It may request get_claim_status.
3. LangGraph routes that request to ToolNode.
4. The tool returns the claim status.
5. The graph loops back to the model.
6. The model may request the policy search tool.
7. After receiving enough information, it generates a response.

This is a basic agentic architecture. Notice that the model chooses whether and when to use tools, while the graph controls the permitted execution paths.

8. State and memory in LangGraph

From Lesson 3, you know that context windows are not persistent memory. LangGraph addresses state persistence through checkpointers and long-term storage.

Short-term memory: checkpoints

A checkpointer can persist the state of a conversation thread.

from langgraph.checkpoint.memory import InMemorySaver

checkpointer = InMemorySaver()

# Recompile the previously constructed builder
# with checkpoint persistence.
graph = builder.compile(checkpointer=checkpointer)

config = {
    "configurable": {"thread_id": "claim-session-1042"},
    "recursion_limit": 10
}

graph.invoke(
    {"messages": [{"role": "user", "content": "Check claim CLM-1042."}]},
    config=config
)

# A subsequent call with the same thread_id
# can continue using checkpointed state.

InMemorySaver is appropriate for demonstrations and tests. It does not survive process restarts. For production, use a durable checkpointer backed by an appropriate database and configure retention, concurrency, encryption, and access controls.

Long-term memory: store

A long-term store can retain application-defined information across threads. For example, one conversation might save a user's preferred notification method. A later conversation could retrieve that preference from the authorized store.

Checkpoint = conversation or workflow state. Store = information intended for reuse across conversations or workflows. Neither mechanism automatically determines which information is safe or appropriate to remember — that is an application policy decision.

9. Human-in-the-loop: pausing an agent for approval

This is one of LangGraph's most important enterprise features. Imagine an agent prepares a request to reopen a rejected claim. The agent may draft the request, but the actual submission requires a human supervisor's approval. LangGraph supports interrupts, allowing execution to pause and later resume.

Minimal interrupt example

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.types import interrupt, Command
from langgraph.checkpoint.memory import InMemorySaver


class ApprovalState(TypedDict):
    claim_id: str
    approved: bool


def approval_step(state: ApprovalState):
    decision = interrupt({
        "action": "reopen_claim",
        "claim_id": state["claim_id"],
        "message": "Supervisor approval required"
    })
    return {"approved": decision["approved"]}


builder = StateGraph(ApprovalState)
builder.add_node("approval", approval_step)
builder.add_edge(START, "approval")
builder.add_edge("approval", END)

graph = builder.compile(checkpointer=InMemorySaver())

config = {"configurable": {"thread_id": "approval-1042"}}

The important mechanism is interrupt() combined with Command(resume=...). A production system must verify the identity and authorization of the person resuming the workflow. A client-supplied approved=True is not proof of approval.

A subtle but critical issue: replay and idempotency

When an interrupted graph resumes, code before the interrupt may execute again, depending on how the graph is structured. Therefore, do not place an irreversible action before an interrupt unless that action is safely idempotent or protected by durable transaction controls. For example, avoid:

charge_customer()
decision = interrupt("Approve charge?")

The charge could occur before approval and potentially repeat during replay. Instead, pause before the action, validate approval, then execute through a separately controlled, idempotent operation. This is especially important for payments, account deletion, claim updates, and external API mutations.

Interactive approval workflow simulator

Human-in-the-Loop Approval Simulator

Prepare a reopening request, then approve it. Toggle the safeguards off to see why they exist.

Verify approver identity Apply idempotency key

Workflow state

Idle

No request prepared yet.

10. Multi-agent architecture

A multi-agent system uses multiple specialized agents or model-driven components that collaborate on a larger task. For example:

Supervisor / Orchestrator → Policy Agent (RAG retrieval) + Claims Agent (case analysis) + Drafting Agent (prepare response) → Validation + Human Approval

When should you use multiple agents?

Use multiple agents when tasks genuinely benefit from distinct responsibilities, tools, or contexts. For example, one component may specialize in policy retrieval while another investigates claim records. But don't introduce multiple agents just because it sounds sophisticated. Multi-agent systems can create additional latency, cost, coordination overhead, inconsistent state, and difficult debugging. A single agent with well-designed tools is often the better starting point.

11. AWS Bedrock + LangGraph enterprise architecture

LangGraph provides orchestration and state management. Amazon Bedrock provides managed model inference. They are complementary technologies.

Enterprise client application

↓ API Gateway + identity + authorization

↓ LangGraph orchestration on ECS / Fargate — state graph · tool routing · approval interrupts

↓ Bedrock (LLM inference) + Knowledge Bases (policy RAG) + case management APIs (authoritative case actions)

↓ Durable state + audit + monitoring — PostgreSQL / DynamoDB · CloudWatch · KMS

Reference architecture, not a mandatory deployment topology. Lambda may also suit shorter stateless operations; long-running or highly stateful orchestration needs deliberate lifecycle design.

Why ECS/Fargate?

It can be a practical deployment choice for a persistent Python orchestration service, especially when you need control over dependencies, streaming connections, and worker behavior. Lambda can work for bounded steps and event-driven functions, but long-running approval workflows should persist state rather than keep a function invocation open while waiting.

Why not use Bedrock Agents for everything?

Amazon Bedrock also provides managed agent capabilities. The architectural choice depends on requirements:

Bedrock-managed agents	LangGraph
AWS-managed agent orchestration features	Explicit application-defined state graph
Integrated Bedrock ecosystem	Flexible framework-level orchestration
Less custom infrastructure for supported use cases	More control over routing and execution
Useful for AWS-centric agent workloads	Useful for custom workflows and portability

Both can be valid. Evaluate orchestration control, persistence, approvals, observability, cost, and operational ownership rather than assuming one is always superior.

12. Security: what makes an agent enterprise-ready?

Agents introduce risks beyond ordinary question-answering because they may invoke tools that read or modify external systems. Here are the major controls an AI Solutions Architect must design.

Risk	Required control
Unauthorized tool access	Identity and permission checks at every tool boundary
Prompt injection	Treat retrieved content and tool output as untrusted data
Excessive tool execution	Step limits, timeouts, rate limits, and spend budgets
Duplicate transactions	Idempotency keys and transactional safeguards
Sensitive data leakage	Least privilege, tenant isolation, output controls
Incorrect model decisions	Deterministic validation and human approvals
Workflow failures	Durable checkpoints, retries, audit logs
Uncontrolled memory	Retention, access policies, and deletion handling

An agent should not be the ultimate authority

Suppose the model says: "This claim is eligible. Reopen it immediately." The application must still verify: does the authenticated user have permission? Is the claim in an eligible state? Are the policy conditions satisfied? Is supervisor approval required? Has the request already been submitted? Only after those checks should an authorized system execute the action. The model's recommendation is evidence for the workflow, not a substitute for the workflow's controls.

13. Agent evaluation: how do we know it works?

Agent evaluation is more complex than evaluating a chatbot. A chatbot may be judged by answer quality. An agent must also be evaluated by the actions it takes. Useful metrics include:

Metric	What it measures
Task success rate	Did the agent complete the authorized goal?
Tool selection accuracy	Did it choose appropriate tools?
Tool argument accuracy	Did it supply correct inputs?
Unauthorized action rate	Did it attempt forbidden operations?
Human escalation quality	Did it pause when approval was needed?
Average tool calls	How efficiently did it complete the task?
End-to-end latency	How long did the complete workflow take?
Cost per successful task	How much did successful execution cost?

Example evaluation scenario

A rejected claim requires supervisor approval. A correct agent should retrieve the claim, find the applicable policy, prepare a request, and pause for approval. An incorrect agent might submit the reopening immediately. Even if the final user-facing explanation sounds excellent, the second agent has failed a critical safety requirement. Evaluate trajectories and state transitions, not just final text.

14. Architecture challenge: design your own agent

Imagine you're asked to build an AI claims assistant with these requirements:

• Read claim records.
• Search internal policies.
• Request missing information.
• Prepare a reopening request.
• Require supervisor approval before submission.
• Resume the workflow the following day.
• Keep a complete audit trail.

A sound design would use: LangGraph for orchestration, routing, and interrupts; Bedrock for language reasoning; RAG for policy evidence; a business rules engine or authoritative claims API for business rules and case updates; and a durable checkpoint database to resume execution.

The supervisor approval should be validated through the enterprise identity and authorization system. The final submission should be idempotent and audited. This is the architecture-level thinking expected of an AI Solutions Architect.

Lesson 7 — Final Knowledge Check

Lesson 7 Assessment

You need at least 4/5 to pass Lesson 7 and complete the Day 1 learning sequence.

Day 1's final principle: an enterprise AI agent is not simply an LLM with access to tools. It's a controlled, stateful software system that combines probabilistic reasoning with deterministic execution, durable persistence, authorization, observability, and human oversight.

Passing this lesson completes the seven foundational lessons of Day 1. The next step is a comprehensive architecture assessment before advancing to hands-on AWS and LangGraph engineering.