LangGraph &
Google ADK

the big idea

Both frameworks solve the same problem (orchestrating stateful LLM workflows) from opposite directions.

Keep that split in your back pocket. Everything fits around it.

LangGraph 🕸️

LangGraph models an agent as a directed graph with shared state, inspired by Google's Pregel system. Every node reads state → does something → returns a state update. Edges decide who runs next. That's really the whole thing.

three primitives, that's it

defining state, with a twist

from typing import TypedDict, Annotated
from langgraph.graph.message import add_messages
from langchain_core.messages import AnyMessage

class AgentState(TypedDict):
    messages: Annotated[list[AnyMessage], add_messages]  # ← reducer!
    user_name: str
    turn_count: int

That Annotated[list, add_messages] thing is a reducer. It's how LangGraph decides to merge updates to a key. Without it, new values overwrite old ones. With it, new messages append. We'll see that live in a minute.

a node is just a function

def classify(state: AgentState) -> dict:
    # read state
    last_msg = state["messages"][-1].content
    # do work (could be an LLM call, a tool, whatever)
    label = "urgent" if "help" in last_msg else "normal"
    # return ONLY the fields you want to update
    return {"classification": label}

edges: three flavors

from langgraph.graph import StateGraph, START, END

graph = StateGraph(AgentState)
graph.add_node("classify", classify)
graph.add_node("respond", respond)
graph.add_node("escalate", escalate)

# 1. fixed edge: always go from START to classify
graph.add_edge(START, "classify")

# 2. conditional edge: pick next based on state
def route(state):
    return "escalate" if state["classification"] == "urgent" else "respond"

graph.add_conditional_edges("classify", route, ["respond", "escalate"])

# 3. terminal edges
graph.add_edge("respond", END)
graph.add_edge("escalate", END)

app = graph.compile()  # ← don't forget this!

how it actually runs: the super-step model

LangGraph doesn't traverse the graph step-by-step like a flowchart. It runs in super-steps: in each step, all active nodes run in parallel, their outputs merge via reducers, and the next set of active nodes is computed. Inspired by Pregel. Step through the demo below to see it live.

Notice how it's not stepping edge by edge — it's in waves. All the active nodes in super-step N run together, their updates merge, and the waves keep propagating until every node goes quiet.

reducers: the trap nobody explains

When two parallel nodes update the same state key, or when you call the same node multiple times, LangGraph needs to know how to merge the new value with the old. That's what a reducer is.

Default behavior: overwrite. But for lists of messages, you usually want append. Watch the difference:

two advanced primitives worth knowing

Send is for dynamic fan-out: spawn N parallel invocations of a node when you don't know N at graph-definition time (map-reduce-ish).

from langgraph.types import Send

def dispatch(state):
    return [Send("make_joke", {"subject": s}) for s in state["subjects"]]

graph.add_conditional_edges("pick_subjects", dispatch)

Command lets a node update state AND route in one return — skipping the usual edge resolution. Great for multi-agent handoffs.

from langgraph.types import Command

def review(state) -> Command:
    return Command(
        update={"status": "approved"},
        goto="deploy"   # jump, don't use edges
    )

persistence = superpower

Attach a checkpointer and LangGraph saves state after every super-step. This is wild. It unlocks: fault tolerance, human-in-the-loop, time travel, and long-running agents.

from langgraph.checkpoint.memory import InMemorySaver
# or: from langgraph.checkpoint.postgres import PostgresSaver

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

# every run needs a thread_id; same thread = same conversation history
cfg = {"configurable": {"thread_id": "conv-42"}}
app.invoke({"messages": [...]}, config=cfg)

wait, where do LLMs plug in?

We've been hand-waving the "do work" part of every node. Time to unwave that. Here's the thing most tutorials don't make obvious:

So the mental picture for any LLM-calling node is: a function that invokes a LangChain model and returns the result into graph state. That's the whole integration.

the four primitives you'll touch every day

the message list IS the conversation

An LLM call is literally llm.invoke([list_of_messages]) → new AIMessage. Four message types flow through state:

from langchain_core.messages import (
    HumanMessage,    # user said
    AIMessage,       # model said (may contain .tool_calls!)
    SystemMessage,   # system prompt
    ToolMessage,     # result of a tool execution
)

An AIMessage has two fields that matter: .content (the text) and .tool_calls (list of functions the model wants to invoke). This is how tool-calling LLMs say "I want to run this function" — they emit a structured tool_call instead of plain text.

tools: write function, add decorator, done

from langchain_core.tools import tool

@tool
def get_weather(location: str) -> dict:
    """Get the current weather for a location."""
    return {"temp": 72, "condition": "sunny"}

# attach to model — now the LLM knows this tool exists
llm_with_tools = llm.bind_tools([get_weather])

response = llm_with_tools.invoke(messages)
# response.tool_calls → [{"name": "get_weather", "args": {"location": "Tokyo"}, ...}]

The @tool decorator inspects the function's name, docstring, and type hints to build a JSON schema the model sees. Write good docstrings. The docstring IS the prompt.

two prebuilt nodes save you boilerplate

from langgraph.prebuilt import ToolNode, tools_condition
from langgraph.graph import MessagesState   # pre-made state schema!

# ToolNode: looks at last AIMessage, executes every tool_call,
# appends results as ToolMessages to state
tool_node = ToolNode([get_weather])

# tools_condition: conditional edge function
# if last message has tool_calls → "tools" ; else → END
graph.add_conditional_edges("agent", tools_condition)

Also note MessagesState — a prebuilt state schema with messages: Annotated[list[AnyMessage], add_messages] already set up. Saves 3 lines and signals you know the idiom.

the agent loop, step by step

Put it all together and you get the ReAct loop — the shape 95% of LLM agents take. Watch one execute below. The key thing to notice: the message list grows on every iteration, and that's the mechanism by which the agent "remembers" what it did.

Notice: the add_messages reducer is doing silent work here. Every node returns {"messages": [new_msg]}, and the reducer appends. If you forgot the reducer, each step would overwrite history and the agent would forget everything between iterations. Ouch.

the full pattern in 15 lines

from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.prebuilt import ToolNode, tools_condition
from langchain.chat_models import init_chat_model

llm = init_chat_model("anthropic:claude-sonnet-4-6").bind_tools([get_weather])

def call_model(state: MessagesState):
    return {"messages": [llm.invoke(state["messages"])]}

g = StateGraph(MessagesState)
g.add_node("agent", call_model)
g.add_node("tools", ToolNode([get_weather]))
g.add_edge(START, "agent")
g.add_conditional_edges("agent", tools_condition)   # auto-route on tool_calls
g.add_edge("tools", "agent")                  # loop back
app = g.compile()

even shorter: create_agent (the one-liner)

If that's exactly the shape you want — and it often is — LangGraph has it prebuilt:

from langchain.agents import create_agent   # new v1 API

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[get_weather],
    prompt="You are a helpful assistant.",
)
agent.invoke({"messages": [{"role": "user", "content": "weather in Tokyo?"}]})

two more primitives to know exist

with_structured_output() — forces the model to return a Pydantic object instead of free text:

class Decision(BaseModel):
    should_escalate: bool
    reason: str

result = llm.with_structured_output(Decision).invoke(messages)
# result is a Decision instance, not a string — typed, validated

Streaming — app.stream() emits per-super-step updates; app.astream_events() emits token-level events. Both matter for real app UX.

build the agent loop yourself

Here's the truth: Google interviews often happen in a Google Doc. No autocomplete. No running code. No syntax highlighting to bail you out. What they're really testing isn't "can you type langgraph.prebuilt from memory" — it's can you reason about the data?

Given a blank page, can you design the right primitives for an agent loop and explain why each piece exists? That's the skill. Let's build one together, layer by layer. Click through the tabs below to see how each layer builds on the last.

# 1. A message in the conversation
Message:
  role    : "user" | "assistant" | "tool"
  content : text (possibly empty)
  tool_calls  : list of ToolCall (if assistant wants tools)
  tool_call_id: string (only when role = "tool")

# 2. What the model requests
ToolCall:
  id   : unique id for this request
  name : name of tool to invoke
  args : dict of arguments

# 3. A tool definition (what's available)
Tool:
  name        : identifier
  description : what it does (for the LLM!)
  fn          : callable that does the work

# 4. The whole thing
AgentState:
  messages  : list[Message]
  iteration : int   # budget tracker

from dataclasses import dataclass, field
from typing import Callable, Any, Literal

@dataclass
class ToolCall:
    id: str
    name: str
    args: dict[str, Any]

@dataclass
class Message:
    role: Literal["user", "assistant", "tool"]
    content: str = ""
    tool_calls: list[ToolCall] = field(default_factory=list)
    tool_call_id: str | None = None

@dataclass
class Tool:
    name: str
    description: str
    fn: Callable[..., Any]

@dataclass
class AgentState:
    messages: list[Message] = field(default_factory=list)
    iteration: int = 0

function run_agent(user_query, tools, max_iters):
    state = AgentState()
    state.messages.append(Message(role="user", content=user_query))

    while state.iteration < max_iters:
        state.iteration += 1

        # 1. Call the LLM with full history + available tools
        response = llm.call(messages=state.messages, tools=tools)
        state.messages.append(response)

        # 2. If no tool calls → we're done, return the answer
        if not response.tool_calls:
            return response.content

        # 3. Otherwise, execute each tool call in order
        for call in response.tool_calls:
            tool = find_tool(tools, call.name)
            result = tool.fn(**call.args)      # run it!
            state.messages.append(
                Message(
                    role="tool",
                    content=str(result),
                    tool_call_id=call.id,       # link back
                )
            )

        # loop continues — next iteration, LLM sees tool results

    return "Reached max iterations without final answer"

def run_agent(
    user_query: str,
    tools: list[Tool],
    llm,                    # some LLM client we have
    max_iters: int = 10,
) -> str:
    state = AgentState()
    state.messages.append(Message(role="user", content=user_query))

    # build a lookup once — O(1) dispatch beats O(n) search in the loop
    tool_registry = {t.name: t for t in tools}

    while state.iteration < max_iters:
        state.iteration += 1

        # 1. Ask the model. llm.call returns a Message (role="assistant").
        response: Message = llm.call(
            messages=state.messages,
            tools=tools,       # schemas, not the functions themselves
        )
        state.messages.append(response)

        # 2. Natural stopping condition
        if not response.tool_calls:
            return response.content

        # 3. Execute each tool call; append results
        for call in response.tool_calls:
            tool = tool_registry.get(call.name)
            if tool is None:
                result = f"Error: no tool named {call.name}"
            else:
                try:
                    result = tool.fn(**call.args)
                except Exception as e:
                    result = f"Error: {e}"   # feed error back to LLM!

            state.messages.append(Message(
                role="tool",
                content=str(result),
                tool_call_id=call.id,
            ))

    return "[Hit max iterations]"  # budget exceeded

# Define some tools
def get_weather(location: str) -> dict:
    return {"temp": 72, "condition": "sunny"}

def search_web(query: str) -> list[str]:
    return ["result 1...", "result 2..."]

tools = [
    Tool(name="get_weather",
         description="Get current weather for a location",
         fn=get_weather),
    Tool(name="search_web",
         description="Search the web for a query",
         fn=search_web),
]

answer = run_agent(
    user_query="What's the weather in Tokyo and what are they known for?",
    tools=tools,
    llm=my_llm_client,
    max_iters=5,
)

seeing the data model in action

The Message dataclass has four fields, but each individual message only uses some of them. The class is a union — "a message is one of these four things" — which is confusing until you see a full conversation play out. Let's trace one together.

Use the controls below to step through a real tool-calling conversation. Watch how tool_calls and tool_call_id appear on different messages, never on the same one.

the one-pager you should be able to recreate

If someone slides a blank Google Doc in front of you and says "implement an agent loop," this is the shape that should materialize. No imports, no frameworks — just primitives + logic.

from dataclasses import dataclass, field

@dataclass
class ToolCall: id: str; name: str; args: dict

@dataclass
class Message:
    role: str
    content: str = ""
    tool_calls: list = field(default_factory=list)
    tool_call_id: str = None

def run_agent(query, tools, llm, max_iters=10):
    registry = {t.name: t for t in tools}
    messages = [Message(role="user", content=query)]

    for _ in range(max_iters):
        resp = llm.call(messages=messages, tools=tools)
        messages.append(resp)

        if not resp.tool_calls:
            return resp.content

        for call in resp.tool_calls:
            try:
                result = registry[call.name].fn(**call.args)
            except Exception as e:
                result = f"Error: {e}"
            messages.append(Message(
                role="tool", content=str(result), tool_call_id=call.id
            ))

    return "[max iters]"

Google ADK 🤖

Where LangGraph gives you graph primitives, ADK gives you agent primitives. It's higher-level and more opinionated. Released at Google Cloud NEXT 2025, it's the same framework powering Google's own products (Agentspace, Customer Engagement Suite).

agent types, in order of importance

LlmAgent: the workhorse

from google.adk.agents import LlmAgent

capital_agent = LlmAgent(
    name="capital_agent",               # required, unique
    model="gemini-2.5-flash",
    description="Answers capital questions",  # for OTHER agents to route to this one
    instruction="Respond with the capital of the country asked.",  # system prompt
    tools=[get_capital_city],          # plain functions work!
    output_key="last_answer",          # auto-save response to state
)

workflow agents (the "no-LLM" orchestrators)

These are deterministic. They don't use an LLM to decide control flow — they just run their children in a fixed pattern. This is how ADK replaces the edge-routing you'd write by hand in LangGraph.

from google.adk.agents import SequentialAgent, ParallelAgent, LoopAgent

# assembly line: run in order, pass via state
pipeline = SequentialAgent(
    name="pipeline",
    sub_agents=[fetcher, analyst, summarizer],
)

# fan-out: all run concurrently
swarm = ParallelAgent(
    name="code_review_swarm",
    sub_agents=[security_checker, style_checker, performance_analyst],
)

# iterate until exit_loop tool called or max iterations hit
refiner = LoopAgent(
    name="refiner",
    sub_agents=[generator, critic],
    max_iterations=3,
)

the data model: session ▸ state ▸ events

Memorize this cold for the interview. Every ADK interaction lives inside a session, which holds:

• state — a dict-like scratchpad, scoped by prefix (user:, app:, temp:, or none)
• events — the append-only history. User inputs, LLM outputs, tool calls, state deltas. Everything.

state prefix conventions

events are the fundamental unit of flow

Every interaction produces events. State never changes directly — it changes because an event with a state_delta was emitted. Watch a full turn play out below.

sub-agents: delegation vs orchestration

There are two different ways an agent can have children. This distinction gets people confused:

# 1. LLM-DRIVEN delegation (non-deterministic)
coordinator = LlmAgent(
    name="coordinator",
    model="gemini-2.5-flash",
    instruction="Delegate to the right specialist.",
    sub_agents=[greeter_agent, weather_agent],   # LLM picks one
)

# 2. DETERMINISTIC orchestration (fixed order)
pipeline = SequentialAgent(
    name="pipeline",
    sub_agents=[fetcher, analyst],   # runs in this exact order
)

When a LlmAgent has sub_agents, its LLM dynamically routes to one using a built-in transfer_to_agent tool (it reads each sub-agent's description to decide). When a SequentialAgent has sub_agents, they just run in order. Know which you want.

the Runner and contexts

You don't run agents directly — you run them through a Runner, which creates an InvocationContext that travels with execution. For most code you only touch the specialized context types:

build a multi-agent system in ADK

Google's interviewer is likely to pose something like this. Word it almost exactly as they will:

The prompt is dense on purpose. It's testing whether you can (a) decompose the work, (b) pick the right agent type for each piece, (c) design the data flow, and (d) think about correctness. Let's walk through the full solution — with a visual of the architecture as it grows.

what ADK primitives do we need, and why?

One problem statement, five different agent types. That's why this question is so common — it's a Rorschach test for whether you know the full primitive vocabulary.

the architecture, one piece at a time

Step through the tabs below to see how the system is built layer by layer. Each stage highlights a new agent, tells you which ADK primitive to use, and shows the exact code.

putting it all together

Now that each piece is built, here's the full wiring. This is roughly what you'd write on the whiteboard:

from google.adk.agents import LlmAgent, SequentialAgent, ParallelAgent, LoopAgent

MODEL = "gemini-2.5-flash"

# ---------- 1. Three parallel fetchers ----------
profile_agent = LlmAgent(
    name="profile_agent",
    model=MODEL,
    description="Fetches company profile: CEO, HQ, industry.",
    instruction="Given a company name, use search to find profile. Return compact JSON.",
    tools=[google_search],
    output_key="profile",
)
news_agent = LlmAgent(
    name="news_agent",
    model=MODEL,
    instruction="Find 3 most recent news items for the company. Return dated bullets.",
    tools=[google_search],
    output_key="news",
)
financials_agent = LlmAgent(
    name="financials_agent",
    model=MODEL,
    instruction="Fetch latest market cap, revenue, and recent stock movement.",
    tools=[get_stock_data, google_search],
    output_key="financials",
)

fetch_fanout = ParallelAgent(
    name="fetch_fanout",
    sub_agents=[profile_agent, news_agent, financials_agent],
)

# ---------- 2. Synthesizer + conflict check ----------
synthesizer = LlmAgent(
    name="synthesizer",
    model=MODEL,
    instruction="""Merge {profile}, {news}, {financials} into a one-page brief.
    Also detect conflicts (e.g., news mentions acquisition, financials show old market cap).
    Output JSON: {"brief": str, "conflicts": list[str], "has_conflict": bool}.""",
    output_key="draft",
)

# ---------- 3. Refine loop (runs only when no conflict) ----------
critic = LlmAgent(
    name="critic",
    model=MODEL,
    instruction="Check {draft} for clarity, completeness. If good, call exit_loop. Else give feedback.",
    tools=[exit_loop],
    output_key="feedback",
)
reviser = LlmAgent(
    name="reviser",
    instruction="Revise {draft} per {feedback}. Overwrite draft.",
    output_key="draft",
)
refine_loop = LoopAgent(
    name="refine_loop",
    sub_agents=[critic, reviser],
    max_iterations=3,
)

# ---------- 4. Conflict clarifier (only when has_conflict) ----------
conflict_clarifier = LlmAgent(
    name="conflict_clarifier",
    description="Handles cases where sources disagree. Asks user for guidance.",
    model=MODEL,
    instruction="Present {conflicts} to the user. Ask which source to trust. Await response.",
)

# ---------- 5. Router: LlmAgent with sub_agents for delegation ----------
quality_router = LlmAgent(
    name="quality_router",
    model=MODEL,
    instruction="""Examine {draft}. If has_conflict is true, transfer to conflict_clarifier.
    Otherwise transfer to refine_loop to polish the output.""",
    sub_agents=[conflict_clarifier, refine_loop],   # ← LLM picks one!
)

# ---------- 6. Root: the full pipeline ----------
research_pipeline = SequentialAgent(
    name="research_pipeline",
    sub_agents=[fetch_fanout, synthesizer, quality_router],
)

"now, how would you evaluate this?"

This follow-up is where most candidates stumble. The common wrong answer: "I'd write some test cases and check if the output looks right." That's unit testing, which doesn't work for agents because they're non-deterministic. The right answer has a structure.

the agent evaluation pyramid

# EXACT: every tool call matches, same order, no extras
# IN_ORDER: expected tools appear in order, extras allowed between
# ANY_ORDER: all expected tools appear, any order

expected_tools = [
    {"tool": "google_search", "args": {"query": "Acme Corp CEO"}},
    {"tool": "get_stock_data", "args": {"ticker": "ACME"}},
]
# For our research assistant, use ANY_ORDER at the top level
# (profile/news/fin run in parallel, real order is non-deterministic).
# But within each fetcher, IN_ORDER or EXACT makes sense.

# Golden dataset entry for a "has conflict" case
{
    "query": "Research Stripe",
    "initial_state": {"mock_news": "Stripe acquired by Visa",
                      "mock_financials": "Market cap $95B standalone"},
    "expected_trajectory": [
        "profile_agent", "news_agent", "financials_agent",   # parallel
        "synthesizer",
        "quality_router",
        "conflict_clarifier",                                 # ← critical
    ],
    "must_NOT_run": ["refine_loop"],                          # shouldn't polish bad data
}

# test_config.json
{
    "criteria": {
        "tool_trajectory_avg_score": 0.8,       # loose for parallel
        "response_match_score": 0.6,             # ROUGE is lenient
        "final_response_match_v2": 0.85,         # LLM judge, strict
        "hallucinations_v1": 0.9,                # grounding check
    }
}

def no_hallucinated_tickers(eval_case, result):
    # every stock ticker in output MUST appear in the financials tool result
    output_tickers = extract_tickers(result.final_response)
    source_tickers = extract_tickers(result.state["financials"])
    return output_tickers.issubset(source_tickers)

def conflict_flag_must_be_honest(eval_case, result):
    # if sources disagree in the fixture, has_conflict MUST be True
    if eval_case.fixture.get("sources_disagree"):
        return result.state["draft"]["has_conflict"] is True
    return True

def financials_freshness_enforced(eval_case, result):
    # the before_tool_callback should have blocked stale data
    return "stale_data_rejected" in result.callback_logs

the five ADK evaluation metrics you should name

Being able to name metrics by ADK's actual API names signals you've actually used the tool. Memorize these:

how you'd actually run it — the loop

Not just "define metrics" — describe the full eval lifecycle. This is what earns the senior-IC signal:

failure modes specific to multi-agent systems

These come up in follow-up questions. Know them by name:

same problem, both frameworks

The fastest way to internalize the difference is to see the same solution written in both. Flip the tab.

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

class State(TypedDict):
    topic: str
    summary: str
    draft: str
    final: str

def fetch_summary(state):
    return {"summary": llm_summarize(state["topic"])}

def write_draft(state):
    return {"draft": llm_draft(state["summary"])}

def revise(state):
    return {"final": llm_revise(state["draft"])}

g = StateGraph(State)
g.add_node("fetch", fetch_summary)
g.add_node("draft", write_draft)
g.add_node("revise", revise)
g.add_edge(START, "fetch")
g.add_edge("fetch", "draft")
g.add_edge("draft", "revise")
g.add_edge("revise", END)

app = g.compile()
result = app.invoke({"topic": "octopi"})

from google.adk.agents import LlmAgent, SequentialAgent

fetcher = LlmAgent(
    name="fetcher",
    model="gemini-2.5-flash",
    instruction="Summarize the topic from the query.",
    output_key="summary",
)

drafter = LlmAgent(
    name="drafter",
    model="gemini-2.5-flash",
    instruction="Write a draft from this summary: {summary}",
    output_key="draft",
)

reviser = LlmAgent(
    name="reviser",
    model="gemini-2.5-flash",
    instruction="Revise for clarity: {draft}",
    output_key="final",
)

pipeline = SequentialAgent(
    name="content_pipeline",
    sub_agents=[fetcher, drafter, reviser],
)
# run via Runner + SessionService

the cheatsheet

gotchas

Click any card to expand. These are the things that don't show up in the tutorials but will trip you up in the interview.

quiz yourself

Ten questions. Instant feedback. The ones you miss are the ones to study.