A rail intermodal yard partnering with Meridian on cross-docked containers wants an assistant that, given a shipment ID, pulls together customs status, current yard location, and any open maintenance flags on the container itself - three different backend systems - into one combined answer. Which capability must the chain include beyond a single retriever and a single LLM call?
Select an answer to reveal the explanation.
Short Explanation
Three separate systems, three separate lookups - the chain needs a tool call for each one, with the results brought back together at the end, not a single search box that magically knows about customs, the yard, and maintenance all at once.
Full Explanation
The chain needs multiple distinct tool calls, one for each backend system (customs status, yard location, maintenance flags), with their results synthesized into a single combined answer, because a single retriever over a single index cannot span three operationally separate systems that are not indexed together and that likely have different access patterns, freshness requirements, and data owners. Claiming a single retriever over one merged index suffices ignores that these are live operational systems, not a static document corpus that can simply be pre-indexed together - customs status and maintenance flags change independently and need to be queried live, not pre-baked into a shared index. A larger context window does not solve the underlying problem, which is that the data lives in three different systems the model has no way to reach without tool calls; more tokens cannot retrieve data the model was never given a path to access. Fine-tuning the model on shipment IDs would not grant it live access to three external systems either - fine-tuning changes the model's learned behavior on static training data, it does not create a runtime connection to operational databases. This item tests recognizing when a multi-source requirement demands multiple defined tools rather than a bigger model or a single retrieval step.