Parallel by Default: Manufacturing Agents Need Routing, Not One Reasoning Mode

TL;DR for operators

A manufacturing process planner has to preserve relationships across geometry, drawing requirements, material constraints, manufacturing rules, process order, and tooling. If a tolerance or surface-finish requirement is attached to the wrong CAD feature, later reasoning can be internally coherent and still produce the wrong plan.

Design-to-Plan addresses that problem with a hybrid architecture: deterministic components handle precision-sensitive perception and machining calculations, while LLM agents reason through structured tools and retrieved manufacturing knowledge.¹ Across three 100-case downstream benchmarks, parallel configurations reached 100% execution success and more consistently invoked the tools expected for each case. They also cut average token use from 22,481 to 8,896 for process sequencing and from 36,659 to 11,868 for tool selection. Knowledge retrieval was the exception, where parallel coordination slightly increased token use.

Parallel execution did not dominate every quality measure. Sequential process sequencing produced higher reference-sequence overlap, ordering agreement, and completeness, while sequential tool selection retained slightly higher material compatibility.

For operations teams, the result is not a universal winner but a routing policy: use parallel specialists as the routine path for coverage, reliability, and efficiency; reserve deeper sequential reasoning or human review for cases where ambiguity, conflicting evidence, or decision risk justify the extra cost. The paper supports that architecture choice more strongly than it supports claims about factory-scale ROI.

A process plan can fail before planning begins

Manufacturing planning starts with an integration problem. A CAD model contains geometric features. A drawing adds dimensions, tolerances, GD&T, surface-finish requirements, notes, and other specifications. Material databases, manufacturing rules, process dependencies, and tool libraries add further constraints.

Those inputs are useful only if the system preserves their relationships. A tolerance attached to the wrong hole is not merely an extraction error; it changes what downstream planning should do.

Design-to-Plan therefore does not treat an LLM as the universal processing layer. Its three-tier architecture combines an orchestrator, six specialized planning agents, and stateless machine-learning services. CAD feature recognition, drawing parsing, database lookup, rule execution, and machining-parameter calculation remain structured or deterministic where repeatability matters. LLM agents are used where inputs may be incomplete, ambiguous, inconsistently named, or distributed across multiple knowledge sources.

That division of labor is the more consequential architectural choice. The question is not where an LLM can participate. It is which kinds of uncertainty should be handed to it.

The drawing has to reach the correct CAD feature

The bridge between perception and planning is feature-level 2D-3D context fusion.

The system first recognizes manufacturing features from the CAD model and extracts annotations from the engineering drawing. It then attempts to attach each relevant drawing specification to the appropriate 3D feature using semantic type compatibility, dimensional agreement, and spatial consistency. Reasoning-based disambiguation and human correction remain available when the mapping is uncertain.

On 20 real CAD-drawing pairs containing 101 expert-validated mappings, the fusion pipeline reached mean precision of 0.837, recall of 0.905, and F1 of 0.863. Exact-match rate was 0.792. Approximately 40% of the features involved repeated or patterned instances, which makes a superficially plausible geometric match insufficient.

The ablation evidence helps explain the design. Removing domain-specific heuristics reduced precision; removing reasoning-based disambiguation reduced recall. The full hybrid pipeline produced the strongest F1. This is mechanism evidence for combining numerical consistency checks with semantic reasoning, not evidence that either component can independently solve the mapping problem.

Human review also remains part of the architecture. Low-confidence associations can be corrected before they become process-planning inputs.

Parallel execution improves coverage and lowers the cost of long reasoning chains

The paper compares sequential and parallel configurations for Knowledge Retrieval, Process Sequence, and Tool Selection. In both designs, agents alternate between reasoning and calls to external tools or knowledge sources rather than relying only on model memory.

The parallel configuration decomposes work among specialized sub-agents and then coordinates their outputs. The sequential configuration preserves a longer unified reasoning path.

The headline results favor parallel execution on robustness and tool coverage:

Here, Tool F1 measures whether the agent invoked the tools expected for each benchmark case. It is therefore evidence about tool coverage, not a single score for manufacturing-plan correctness.

Efficiency gains were largest where sequential reasoning required many iterations. Process Sequence averaged 5.4 iterations and 22,481 tokens sequentially versus one coordinated parallel pass and 8,896 tokens. Tool Selection fell from 6.6 iterations and 36,659 tokens to 11,868.

Knowledge Retrieval is the useful exception: parallel execution consumed 8,630 tokens versus 7,888 sequentially. Coordination has overhead, and parallelization saves tokens only when avoiding iterative reasoning outweighs that overhead.

Parallel is not the universal quality winner

Process Sequence exposes the main trade-off. Sequential reasoning produced higher Process Jaccard similarity, 0.236 versus 0.208; higher Kendall tau ordering agreement, 0.313 versus 0.147; and higher completeness, 0.598 versus 0.455.

Those figures need careful interpretation because the benchmark uses a single minimal reference sequence. An agent that adds valid operations such as deburring, cleaning, or inspection can score worse on overlap even when the resulting plan remains manufacturable. Still, the direction of the results suggests that the longer sequential path preserves some reference-oriented refinement that parallel decomposition does not.

Tool Selection shows a similar boundary. Parallel execution improved Tool Type Jaccard, coating score, parameter accuracy, special-tooling recall, and must-include coverage. Sequential execution nevertheless achieved slightly higher material compatibility: 0.726 versus 0.702.

Reasoning architecture therefore changes which qualities are preserved. Parallel specialization broadens coverage and shortens long reasoning chains. Sequential execution can devote more iterations to reconciling one evolving context.

Retrieval coverage can matter more than reasoning after retrieval

The conflict benchmark provides another deployment signal. Across ten conflict cases containing 13 known inconsistencies, source detection averaged 0.90, but correct resolution averaged only 0.508. The composite Conflict Detection Score was 0.690.

The reported failure analysis attributes weaker cases mainly to incomplete source access. When the necessary evidence had been retrieved, reasoning over that evidence was generally less problematic than failing to invoke all relevant sources.

That distinction affects system design. Improving the language model alone may not address a conflict-resolution failure caused by an incomplete retrieval policy. Tool registries, source coverage, source-priority rules, and logging of which repositories were actually queried become part of model quality.

The out-of-knowledge-base cases reinforce this point. Sequential Knowledge Retrieval failed to activate fallback and recorded Tool F1 of 0.0 in that category. Parallel retrieval detected insufficient local coverage and reached 0.900 by invoking fallback.

The deployment decision is a routing decision

Cognaptus infers a two-level operating policy from these results.

Routine cases can use parallel specialists when the priorities are throughput, broad tool coverage, and lower inference cost. Cases with ambiguous feature mappings, conflicting sources, incomplete knowledge, sensitive material decisions, or high validation requirements can be escalated to deeper sequential reasoning. Human review should remain available where the upstream feature-to-annotation association itself is uncertain.

That policy also fits the system’s modular structure. CAD recognition, drawing analysis, retrieval, planning, tooling, and reporting can be monitored or replaced separately rather than forcing every improvement through a monolithic model upgrade.

The production boundary is equally clear. These are controlled benchmarks, not a longitudinal factory deployment. Downstream experiments were single runs at temperature zero. Several difficult categories contain only five to seven cases. Conflict scoring came from one expert using heuristic weights. Coating selection and non-standard tooling remain constrained by incomplete libraries.

The evidence therefore supports a credible architecture hypothesis: industrial agent systems can benefit from allocating deterministic computation, parallel specialization, sequential validation, and human intervention to different failure modes. It does not yet establish plant-level savings, autonomous reliability across broad manufacturing portfolios, or a universal threshold for when escalation should occur.

Build the router, not just the agents

Design-to-Plan’s strongest contribution is not that more agents outperform fewer agents. It is that manufacturing automation becomes easier to reason about when computational responsibilities are separated.

Geometry extraction should be precise. Drawing requirements must be attached to the correct feature. Knowledge retrieval should expose its sources. Machining parameters can remain deterministic. Parallel agents can broaden coverage and reduce expensive reasoning loops. Sequential reasoning can be reserved for cases where maintaining and revisiting a unified context has higher value.

For an operational deployment, the next design problem is therefore the router: what evidence should trigger escalation, which decisions require human confirmation, and how those thresholds should be validated against actual manufacturing consequences.

The paper supplies benchmark evidence for that direction. Production systems still have to determine where those boundaries belong.

Cognaptus: Automate the Present, Incubate the Future.