Workflows vs Agents: Who Should Choose the Next Research Step?

A research agent lands on the sentence "LangGraph supports durable execution," ticks a box in a comparison table and recommends the framework. You ship a local app. The process dies. Nothing resumes. What failed?

A condition was skipped. "Supports persistence" is not the same as "persistence is wired up in this application." A market-intelligence agent worth using should notice that gap, read past feature labels and sometimes change its next question because of what it finds.

Earlier in this series the runtime itself was the focus. Here the question is how much freedom the model gets inside that runtime.

Two ways to investigate the same brief

Suppose the brief asks for the relationship between LangGraph and Deep Agents, plus what a Python research service needs for restart recovery, using only official docs.

One approach is a fixed process. You supply the right pages, pull out the key claims, compare their caveats and emit a cited brief. That is a workflow.

The other approach lets the model pick the next move. It searches, opens a page, notices a missing condition and chooses what to dig into next. That is an agent.

Both can use models, tools, branches and retries. The real split is who decides the path. LangGraph's note on workflows and agents draws that line clearly.

A practical rule of thumb:

• Documents and steps are already known: prefer a workflow.
• The useful sources only appear while you research: try a bounded agent.
• Delivery must be predictable, investigation need not be: combine the two.

This project sits in the third bucket.

When a finding rewrites the question

At first glance the brief looks like a bake-off between frameworks. The Deep Agents overview then shows that Deep Agents runs on the LangGraph runtime. The investigation pivots.

Old question: which framework wins?

New finding: they sit at different layers.

Better question: which duties belong in the application itself, and which belong in a higher-level harness?

Persistence needs the same care. The docs describe checkpointer setup and thread identity for local graphs. They also separate in-memory from database-backed stores, and note that Agent Server owns the persistence infrastructure on its own. See Persistence and Checkpointers.

A useful answer keeps those conditions. A feature-table tick mark does not. Everything below comes from reading the docs directly, not from a recorded agent transcript.

Shape of the system: workflow wrapping a researcher

The application owns the brief, the allowed sources, the request caps and how output is handled. Inside that fence the model picks searches and documents. Investigation stays flexible; delivery stays explicit.

Pieces involved:

• LangGraph runs the outer stages of the app.
• The Anthropic SDK gives the model native web-search and web-fetch tools.
• A saved audit keeps sources, citation records, usage and tool errors.

One provider call may pack several search and read actions. LangGraph steers the outer process; it does not invent every query. A single researcher keeps the boundary easy to inspect. Deep Agents can wait until more context management and delegation are needed. Changing providers would also mean rewriting the tool and citation contracts.

Search finds pages; fetch reads them

The request exposes both tools:

tools = [
    {
        "type": "web_search_20250305",
        "name": "web_search",
        "max_uses": 3,
    },
    {
        "type": "web_fetch_20250910",
        "name": "web_fetch",
        "max_uses": 4,
        "max_content_tokens": 6000,
        "citations": {"enabled": True},
    },
]

These definitions come from the companion code and are not a full program. The model you pick must support the documented tool versions. Anthropic documents both tools under Agents and Tools on its developer site; look there for the current search and fetch specs.

Three constraints shape the design.

1. Caps are per request. At most two SDK calls are allowed, including a paused-turn continuation, and SDK retries stay off.
2. Citations on fetch are turned on deliberately so native citation records survive, not only the prose of the answer.
3. An HTTP 200 is not proof of evidence. The API may succeed while a fetch inside it fails, so the tool-result blocks need a look as well.

Those caps limit how many requests and tools fire. They are neither a spend ceiling nor a hard wall-clock deadline.

Citations can still prop up a stretch

Imagine a report claiming the app will recover automatically after a crash, citing a page about configurable persistence. The link is real. The claim is broader than the evidence.

A basic audit asks four yes/no questions: Did the model finish normally? Did it fetch at least one document? Did it return answer text? Does the final response carry native citations? Pass becomes needs_review. Fail on a required check becomes incomplete.

Neither label means the claims are true. Citations may point at indexes and passage locations rather than URLs, and the prototype stores those records without inventing how they map.

A useful review habit: take one substantive claim and open its source. Which condition, exception or qualification would flip the recommendation?

Grow complexity only when you can measure the gain

Long investigations may want selective context loading, compact notes or separate researchers for independent branches. Those ideas show up in Anthropic's posts on packing context for agents and on multi-agent research systems. For this app they are options to evaluate, not upgrades to ship by default.

Four checks make a fair first gate:

1. Does it explain the relationship between LangGraph and Deep Agents?
2. Does it keep the conditions for restart recovery intact?
3. Does it notice when a document fetch failed?
4. Does it admit that docs alone cannot settle the cheapest deployment option?

Put a supplied-document workflow next to model-directed search. Hold the model and the answer requirements fixed, say clearly which sources each side can see and log real usage. Score supported findings, missing conditions and honest uncertainty, not citation count alone.

Where things stand today: ten integration tests pass against the real SDK and LangGraph runtime with mocked HTTP. No live API run has been done yet, because credentials were not set, so there are no measured quality, latency or cost numbers.

Looking ahead

There is now a design worth testing: a researcher that can follow evidence, wrapped in software that leaves an inspectable trail. The next snag appears when the process dies halfway through. Saved response files help you see what happened; they do not restart the graph. The following part adds persistent execution state and tests recovery in a fresh process, still using this web-research application.