DeterministicToolAgentPartition
title: Deterministic-Tool / Agent-Reasoning Partition radar_quadrant: Techniques radar_ring: Assess radar_position: inner
This technique draws a hard line inside a multi-agent pipeline between work that has one correct answer and work that requires judgment, routing the first into ordinary deterministic code and only the second into an LLM agent.
A common failure mode in agent pipelines is letting an LLM compute things that already have a single correct answer, such as a formula or a lookup, when a plain function would produce the same result more cheaply, more predictably, and in a form that can be unit tested. An AWS Architecture Blog case study on an inventory-forecasting pipeline demonstrates the alternative: build the pipeline from typed @tool functions for anything deterministic, such as calculating replenishment quantities or validating a result against a budget constraint, and reserve LLM agent reasoning for the parts that genuinely need contextual judgment, such as deciding which data covariates are trustworthy enough to include in a forecast.
The case study chains four such specialist agents behind a supervisor: preprocessing, forecasting, and reporting stages, each communicating with the next through typed JSON outputs rather than free text, so the pipeline stays machine-readable and auditable instead of depending on one stage successfully parsing numbers back out of another stage's prose. When a downstream constraint is violated, such as a proposed order exceeding a warehouse or budget limit, the pipeline treats that as workflow state and re-invokes the relevant agent with adjusted parameters rather than failing silently or surfacing a raw error. Evaluation is split the same way the pipeline itself is: an LLM-as-judge evaluator scores whether the agent's behavior was reasonable online, while a separate code-based evaluator scores actual forecast accuracy once ground truth arrives, since neither approach alone can check both the reasoning and the result.
The generalizable takeaway is the partition itself, not the inventory-forecasting use case it happened to be demonstrated in: any pipeline mixing agents and deterministic computation can apply the same three moves -- push anything with one correct answer into a plain tool function, connect pipeline stages with typed contracts instead of parsed text, and treat constraint violations as retryable state rather than terminal failures.
This is evidence from a vendor case study, not first-person production use, so it sits at Assess.
