Workflow, Agent, Multi-Agent: Two Independent Architectural Choices

TL;DR

Separate how actions advance from how work is divided. Workflow can include model routing and dynamic tasks, and can organize multiple agents; "split-process-aggregate" is arranged by code, not preventing task lists from being generated at runtime.

One reason to introduce an Agent: investigation paths must change with evidence. After checking inventory and finding materials not released, you switch to checking quality inspection and chasing approvals. If these paths have mature rules, workflow branches can also handle them.

Multi-Agent value must land on division of labor. Supplier investigation and capacity investigation each have their own materials, tools, and follow-up queries, so they can advance independently; but you must consider whether constraints are consistent and whether results lose key conditions.

Checking again does not necessarily recover missing facts. Writing an estimated date as a committed date can be corrected from original records; but attributing delay to quality inspection without inspection records requires supplementary investigation or retaining unknowns.

Start with fixed workflow plus single Agent investigation. Later, compare using the same batch of orders: whether causes were found, whether solutions are executable, how much manual re-checking is needed, plus time and cost.

When Steps Are Clear, Use Workflow to Organize Work

Suppose the business needs to find out why several orders are delayed, which deliveries are affected, and give handling recommendations.

If the order system already records delay reasons, production progress, and estimated warehouse-out dates, you can read records, organize facts, and generate explanations. Code links production and logistics records by order number, calculates date differences, verifies inventory quantities; the model reads remarks and organizes explanations.

When materials are few, one model call after gathering everything may suffice. If the model confuses original records with speculation during explanation, split into two steps: first list dates, statuses, remarks, and record sources per order; then generate explanations based on that. Debugging then distinguishes misreading records from adding unsupported conclusions. The two prompts can be tuned separately. This is a form of prompt chaining .

These steps execute in a known sequence and can be organized with a Workflow . If one call works, don't split; when you need step-by-step verification and separate prompt tuning, prompt chaining makes issues easier to locate.

You can also add a router at the entry. Some requests only ask for estimated delivery date, some want cause analysis, some want solution comparison. The model classifies the natural-language request into categories, and code launches the corresponding flow.

Requests only asking for delivery date can skip cause investigation and solution comparison, saving downstream work. If several request types read the same data and run the same logic, adding classification adds an extra call and another judgment point to debug.

The model in the router chooses among known categories; subsequent processing paths are arranged by developers. Anthropic's Building effective agents classifies routing as a workflow, where categorization can be done by the model.

"Fixed process" means the organization method is fixed, not the content of each execution. Workflows can contain branches, loops, and model judgments; each run can take different branches.

After order numbers are known, independent order-record and logistics-record queries can run in parallel; generating handling recommendations must wait for investigation results. Here you adjust dependencies and wait times, no need to add multiple agents just for parallel queries.

Business judgment difficulty is separate from whether processing steps can be pre-arranged. The previously mentioned Uber contract review assistant v1 organized intent recognition, risk assessment, and rule querying into a LangGraph workflow. Legal judgment involves clause meaning and business risk, yet some work can still unfold in a known structure.

Task List Unknown? Workflow Still Works

Order remarks may not fully explain causes: one order suspected material shortage involving material substitution, another involves customer spec change, another may relate to carrier.

Let the model read materials and list verification items per order: check material arrival and substitution approval, check spec change time, or check logistics trajectory. Different orders generate different lists, quantity not fixed. Code then processes each item and aggregates.

This matches Anthropic's Orchestrator-workers : orchestrator splits tasks based on current input, hands to workers. Although the task list is generated ad-hoc, the "split-process-aggregate" organization can still be pre-arranged.

Task list can be dynamically generated, split, dispatch, and aggregate still organized by workflow

LangGraph official tutorial demonstrates this with report generation: model lists sections, then launches a worker per section. Scheduling code snippet:

sections = orchestrator(topic).result()
section_futures = [llm_call(section) for section in sections]
final_report = synthesizer(
    [section_fut.result() for section_fut in section_futures]
).result()

The number of sections is known only at runtime; code dispatches tasks accordingly and waits for results. Here llm_call invokes the model once to write one section, synthesizer simply concatenates section texts. Workers bear subtasks but have no autonomous search or repeated tool-call investigation loops.

The same tutorial's graph implementation uses Send to dynamically dispatch per section list. Framework pre-defines how nodes work; runtime decides how many tasks execute—both can be true simultaneously.

Back to order analysis: a worker checking spec-change records can receive order number, call specified API, extract change content and time. If every verification item can be completed in such steps, no need to give each worker an autonomous investigation loop.

However, the model-generated list may miss items. Another trouble: queries return no error, list executes fully, yet delay cause remains unclear. Valuable leads hide in first-round returned records; original list didn't arrange a next step.

What You Find Decides What to Query Next

Continue with that suspected-material-shortage order.

Assume system verifies required materials are fully warehoused, but one batch not yet released. Next, query quality records by batch number; if records show "awaiting substitute material approval", follow approval number to engineering change, confirm which step is stuck.

The next valuable query depends on what the previous query returned. The initial "material shortage" remark is just a lead to verify; subsequent actions change with investigation results.

If these situations are limited and handling rules mature, write them as workflow branches. When lead combinations are too many to enumerate paths, consider letting an Agent use tool-returned information to decide what to query next.

This investigation loop can be broken down: model reads "warehoused, not released", proposes querying quality records with batch number; runtime checks parameters and permissions, executes query, returns results to model. Model reads "awaiting substitute material approval", then chooses next query.

Here the loop is "judge → call tool → read result". Model chooses what to query; runtime executes the query. Tool results feed next judgment, giving the original plan a chance to be corrected.

Single Agent adjusts next query based on tool results, program retains stop conditions

Tool returns affect this investigation. "No record found" may need condition verification or source switch; "API request failed" needs retry decision per error; "record shows no anomaly" provides basis to investigate other causes. If all three return empty text, model cannot even judge whether the query succeeded.

For this order assistant, tool results can retain query status, order/batch number, record source and time, key fields. Only then can you distinguish: change query condition, or handle API fault first.

Initial plan must also adjust with results. Materials already fully warehoused but still querying suppliers along "not arrived" path piles up call records while the immediate question—why this batch can't be used—remains unanswered. For production schedulers, such wait is frustrating.

Agent may also pick wrong direction or repeatedly query same record, so investigation needs stop conditions. Enough evidence → form explanation; missing key materials → leave queried records, missing approvals or test results for later follow-up; exceed time or call budget → return findings and incomplete parts. Anthropic's original text also mentions max iterations as program stop condition.

For this example, Agent value lies in following evidence to next step. If it repeats old records or splits one-shot material gathering into multiple rounds, it only adds latency and call cost.

When Is Splitting into Multiple Agents Worthwhile?

This order investigation can first be given to a single Agent. It queries purchasing, warehousing, quality, engineering records as needed until it can explain delay or confirm missing key materials.

Purchasing, warehousing, quality all participate in this order, but no need to create one Agent per department upfront. When checking quality, load inspection specs; when checking engineering changes, read approval descriptions. Single Agent can pick knowledge per task; with many tools, adjust available tools per processing stage.

LangChain's multi-agent docs also note a well-configured single Agent with proper tools and prompts can complete complex tasks. Missing inspection specs → supplement materials; wrong tool chosen → check tool descriptions; these don't necessarily require splitting Agents.

Next, when giving handling solutions, two relatively independent investigations may appear: one researches alternative suppliers, another researches internal capacity adjustment.

Supplier investigation may go from qualification docs to supplyable specs, then verify lead time and MOQ; capacity investigation goes from work orders to equipment, then verify available slots. Both sides have an investigation process that changes with results; assigning two Agents gives concrete division-of-labor basis.

Supplier data and scheduling details stay in each investigation context; both can advance in parallel. These two Agents can use the same underlying model; separated are task context, available tools, and investigation process.

During division, both sides need same delivery deadline, same product spec version. Otherwise, one side thinks substitute material purchasable, other calculates capacity per original material; both results individually reasonable but together unusable. Discovering mismatch after both investigations finish wastes effort. Deadline and spec should be passed from outer layer; each side investigates its own questions.

At aggregation, child Agent returns affect conclusion. A bare "solution feasible" omitting MOQ, equipment limits, or unconfirmed approvals lets main Agent give unexecutable advice. Here, supplier investigation must return candidate solutions, lead-time basis, applicable specs, and pending confirmations so main Agent can compare with capacity solution. If both sides must wait for each other at every step, time saved by parallel execution may be spent on back-and-forth.

Outer layer can mandate: confirm problem first, then launch two investigations, compare results. This is a workflow organizing multiple Agents. If you need to decide which collaborator to engage as investigation progresses, let main Agent dynamically invoke them.

Outer workflow unifies conditions, supplier and capacity Agents investigate independently, main Agent compares results

After division, handoff issues arise: When child Agent finishes, does it return result or continue handling subsequent matters?

If only researching alternative suppliers, finish and hand back conclusion for main Agent to compare—this fits main Agent invoking child Agent (often called Supervisor or Subagents). LangChain's example wraps child Agent as a tool: main Agent passes task, child Agent executes and returns result, main Agent continues.

If user selects alternative procurement, then needs continuous confirmation of spec, quantity, delivery date, consider letting procurement Agent take over subsequent interaction. This is Agent-to-Agent Handoff : changing who handles the task, not just passing a query result back.

Handoff has different implementations. LangChain's current Handoffs doc supports both multi-Agent handoff and single Agent swapping prompts/tools per state. If just entering next processing stage, may not need a new independent Agent.

Can Re-Checking Recover Missing Facts?

Investigation ends, report may still have errors. Some errors hide in wording; some are missing evidence:

Record says "estimated warehouse-out Friday", report writes "deliverable Friday". Existing materials suffice to catch over-promising; can send back for revision. Warehouse-out date ≠ arrival date.

Report claims "quality inspection caused delay" but no corresponding record. Need supplementary investigation or retain as pending verification.

Fixing wording and supplementing evidence require different follow-up actions. If checker can only demand rewrite, generator can neither supplement investigation nor admit insufficient info; after several rounds wording may sound more confident but evidence unchanged. Such report inspires less trust.

Anthropic calls the generate-evaluate alternating structure Evaluator-optimizer , also classifies as workflow. Suits tasks with clear evaluation criteria where feedback drives next-round improvement.

Feedback can also come from outside model. Andrew Ng's The Batch Issue 242 on Reflection mentions using tests, search, etc. to check results. Model checking own output, or two Agents dividing labor, both implement reflection; effect depends on what errors checking finds and whether they can be fixed.

Some fixes don't need iterative loops. Uber's contract review assistant added a single model call to adjust reply tone. Team reported: for already-identified phrasing issues, one targeted revision achieved reliable effect, so they didn't adopt more complex reflection loops.

Uber's choice targets identified tone issues. Order analysis missing quality records needs feedback to become supplementary investigation task; if records unobtainable, report should retain that gap. What repair actions are executable after evaluation determines whether an extra check round helps.

How to Build v1, How to Iterate

This order assistant can keep an outer flow: gather existing facts, investigate unclear causes, form recommendations, hand to business for confirmation. Investigation and solution comparison can be structured per task:

Current Task Difficulty: Materials sufficient, need organized explanation<br/> Adoptable Structure: Fixed queries + calculations, one model analysis<br/> Costs to Watch: Original records easily confused with speculation

Current Task Difficulty: Verification items vary per order<br/> Adoptable Structure: Model generates list, code dispatches & aggregates<br/> Costs to Watch: List may miss items, downstream executes blindly

Current Task Difficulty: Next step depends on new leads<br/> Adoptable Structure: Single Agent continues investigation per tool results<br/> Costs to Watch: Wrong direction, repeated calls, longer waits

Current Task Difficulty: Supply & capacity both need independent investigation<br/> Adoptable Structure: Multi-Agent division, outer layer unifies constraints & comparison<br/> Costs to Watch: Inconsistent conditions, handoff loses basis

These choices can coexist in one system. Selection lands on a specific task segment; only then you know what problem the added structure solves.

v1 can cover routine orders and single Agent investigation. Orders with existing records explaining delay go through workflow; unclear causes go to Agent. When both supply and capacity need separate material chasing, then consider splitting, and agree on shared conditions and required returns.

Whether changes help: compare using same batch of orders. For each delay cause, can corresponding record be found? Any orders missed? Do recommendations meet deadline and spec? How many documents must business people manually re-check? Put these results together with latency and call cost to see if added structure is worth it.

Same failure to give usable solution may stem from different places. One Agent already got key lead but kept picking wrong next query → check tool descriptions and what materials it saw then. Two independent investigations each valid but merged results conflict → verify deadline, spec, and comparison method both sides used.

If failed-analysis orders always miss same record type, next step may just need one fixed query. If record itself doesn't exist, adding another Agent won't conjure facts. Clearly documenting what evidence was found, what materials missing, which approvals stuck, lets next person avoid re-reading everything from scratch.

References

Anthropic: Building effective agents (https://www.anthropic.com/engineering/building-effective-agents)

LangGraph: Workflows and agents (https://docs.langchain.com/oss/python/langgraph/workflows-agents)

LangChain: Multi-agent (https://docs.langchain.com/oss/python/langchain/multi-agent)

LangChain: Subagents (https://docs.langchain.com/oss/python/langchain/multi-agent/subagents)

LangChain: Handoffs (https://docs.langchain.com/oss/python/langchain/multi-agent/handoffs)

Andrew Ng: The Batch, Issue 242, Reflection (https://www.deeplearning.ai/the-batch/issue-242/)

Uber Engineering: Scaling AI in Legal: Building Uber's Redlining Agent (https://www.uber.com/us/en/blog/building-ubers-redlining-agent/)